# Define statements

## Christopher Diggins — 2006-06-22 18:27:53

    The current version of the Cat language borrows the define statement from

    the Joy language (with a slight syntactic variation), but I have observed

    that if I allowed symbols as data-types and provided operations on them, I

    could further reduce the language footprint.

    So for example currently in Cat one would write:

    def inc = 1 +;

    If I enable pushing symbols onto the stack as variables using an operator

    such as "$" you could instead write:

    $inc [1 +] def

    So def no longer is some kind of keyword but just another function. The def

    function takes a list of operations on the top of the stack, and a symbol

    below that and associates the two.

    This may seem trivial difference at first but there are some advantages:

    - Parsing rules are simplified

    - The def function itself can be redefined (thus allowing a form of Aspect

    Oriented Programming)

    - It allows the extension of the language to support overloaded definition

    based on type (e.g. runtime polymorphism)

    I'll probably support the new syntax in Cat v0.3

    [Non-text portions of this message have been removed]

## Joe Bowbeer — 2006-06-22 18:48:42

    On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

     >

    > $inc [1 +] def

    >

     What's the difference between 'def' and '=' then?

    Why not the following?

    [1 +] $inc =

     On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

    > The current version of the Cat language borrows the define statement from

    > the Joy language (with a slight syntactic variation), but I have observed

    > that if I allowed symbols as data-types and provided operations on them, I

    > could further reduce the language footprint.

    >

    > So for example currently in Cat one would write:

    >

    > def inc = 1 +;

    >

    > If I enable pushing symbols onto the stack as variables using an operator

    > such as "$" you could instead write:

    >

    > $inc [1 +] def

    >

    > So def no longer is some kind of keyword but just another function. The def

    > function takes a list of operations on the top of the stack, and a symbol

    > below that and associates the two.

    >

    > This may seem trivial difference at first but there are some advantages:

    > - Parsing rules are simplified

    > - The def function itself can be redefined (thus allowing a form of Aspect

    > Oriented Programming)

    > - It allows the extension of the language to support overloaded definition

    > based on type (e.g. runtime polymorphism)

    >

    > I'll probably support the new syntax in Cat v0.3

    >

## Christopher Diggins — 2006-06-22 19:01:12

    I see no problem with that. It is just a personal preference to avoid

    overloading "=" and to place the symbol argument first.

    So I could easily define def in my library using your syntax as follows:

    $def [swap =] =

    On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>

    wrote:

     >

    > $inc [1 +] def

    >

     What's the difference between 'def' and '=' then?

    Why not the following?

    [1 +] $inc =

    [Non-text portions of this message have been removed]

## John Cowan — 2006-06-22 19:03:35

    Christopher Diggins scripsit:

     > If I enable pushing symbols onto the stack as variables using an operator

    > such as "$" you could instead write:

    >

    > $inc [1 +] def

    >

    > So def no longer is some kind of keyword but just another function. The def

    > function takes a list of operations on the top of the stack, and a symbol

    > below that and associates the two.

     This allows redefinition of functions at runtime, which Joy deliberately

    does not: symbols are defined at load time only.  If they can be

    redefined at runtime, that reintroduces state into the language.

    As written, Joy has no state but the stack (and the file system).

    --

    John Cowan   cowan@...  http://www.ccil.org/~cowan

    Most languages are dramatically underdescribed, and at least one is

    dramatically overdescribed.  Still other languages are simultaneously

    overdescribed and underdescribed.  Welsh pertains to the third category.

            --Alan King

## Christopher Diggins — 2006-06-22 19:24:58

    ".. introduces state ... "

    Good point John. Here is a possible (but not completely thought out)

    solution: allow the definition of symbols as special hash-table values on

    the stack. Global functions are defined at the bottom of the stack. Each

    symbol-hash table acts like a local scope.

    [Non-text portions of this message have been removed]

## stevan apter — 2006-06-22 21:07:19

    here's how you might adapt what is essentially the k

    solution to the problem of variables.

    introduce dictionaries as a first-class datatype.

    let's use your $ as the symbol-prefix.

    a dictionary is a mapping from symbols to values, which

    themselves can be dictionaries.

    if d is a dictionary, then

        d $s get

    leaves the associated value v on the stack.

        d $s v set

    associates $s with v in d and leaves the amended d on

    the stack.

    dot notation:

    a name with embedded dots

        d.a.b.c

    is short-hand for

        d $a get $b get $c get

    btw, i agree with john's explanation for the two-tier

    design of joy, and i think you have to weigh carefully

    the decision to incorporate assignment into the semantics

    of your language.

    there *is* a middle-way (probably several), which is

    single-assignment; i.e. assignment but not reassignment.

    this is just adequate for the purpose of *definition*

    within the language, but not state-keeping.

     ----- Original Message -----

    From: "Christopher Diggins" <cdiggins@...>

    To: <concatenative@yahoogroups.com>

    Sent: Thursday, June 22, 2006 3:24 PM

    Subject: Re: [stack] Define statements

    > ".. introduces state ... "

    >

    > Good point John. Here is a possible (but not completely thought out)

    > solution: allow the definition of symbols as special hash-table values on

    > the stack. Global functions are defined at the bottom of the stack. Each

    > symbol-hash table acts like a local scope.

    >

    >

    > [Non-text portions of this message have been removed]

    >

    >

    >

    >

    >

    > Yahoo! Groups Links

    >

    >

    >

    >

    >

    >

## Christopher Diggins — 2006-06-22 21:49:38

    > here's how you might adapt what is essentially the k

     solution to the problem of variables.

    That is essentially what I was proposing, just not as elegantly presented.

    Thanks for that explanation.

    - Christopher

    [Non-text portions of this message have been removed]

## Joe Bowbeer — 2006-06-22 22:34:05

    On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

     > I see no problem with that. It is just a personal preference to avoid

    > overloading "=" and to place the symbol argument first.

    >

     A few thoughts:

    If a program is a first-class value in your language then using "="

    for assignment of these values seems natural.  (Assuming a symbol can

    only have one value.)

    If you place the symbol second then it's easy for one program to

    generate another program by leaving it on the stack, where it can be

    assigned or applied -- or whatever.

    This discussion reminds me a Scheme, where functions are first-class

    values.  In Scheme, though, closures (environment + continuation) eat

    their own trail, leading toward stackless execution.  While what you

    are describing, storing assignments on the stack, seems more similar

    to traditional dynamically-bound Lisp.

     On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

    > I see no problem with that. It is just a personal preference to avoid

    > overloading "=" and to place the symbol argument first.

    >

    > So I could easily define def in my library using your syntax as follows:

    >

    > $def [swap =] =

    >

    >

    > On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>

    > wrote:

    > >

    > > $inc [1 +] def

    > >

    >

    > What's the difference between 'def' and '=' then?

    >

    > Why not the following?

    >

    > [1 +] $inc =

    >

## stevan apter — 2006-06-23 02:13:21

    i can't possibly express how wrong-headed i think this is.  = is a

    function from values to truth-values.  assignment has a side-effect.

    besides, if symbols are first-class, then how do you test for equality

    of symbols?

     ----- Original Message -----

    From: "Joe Bowbeer" <joe.bowbeer@...>

    To: <concatenative@yahoogroups.com>

    Sent: Thursday, June 22, 2006 6:34 PM

    Subject: Re: [stack] Define statements

    > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

    > > I see no problem with that. It is just a personal preference to avoid

    > > overloading "=" and to place the symbol argument first.

    > >

    >

    > A few thoughts:

    >

    > If a program is a first-class value in your language then using "="

    > for assignment of these values seems natural.  (Assuming a symbol can

    > only have one value.)

    >

    > If you place the symbol second then it's easy for one program to

    > generate another program by leaving it on the stack, where it can be

    > assigned or applied -- or whatever.

    >

    > This discussion reminds me a Scheme, where functions are first-class

    > values.  In Scheme, though, closures (environment + continuation) eat

    > their own trail, leading toward stackless execution.  While what you

    > are describing, storing assignments on the stack, seems more similar

    > to traditional dynamically-bound Lisp.

    >

    >

    > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

    > > I see no problem with that. It is just a personal preference to avoid

    > > overloading "=" and to place the symbol argument first.

    > >

    > > So I could easily define def in my library using your syntax as follows:

    > >

    > > $def [swap =] =

    > >

    > >

    > > On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>

    > > wrote:

    > > >

    > > > $inc [1 +] def

    > > >

    > >

    > > What's the difference between 'def' and '=' then?

    > >

    > > Why not the following?

    > >

    > > [1 +] $inc =

    > >

    >

    >

    >

    >

    > Yahoo! Groups Links

    >

    >

    >

    >

    >

    >

    >

## Joe Bowbeer — 2006-06-23 03:56:15

    On 6/22/06, stevan apter <sa@...> wrote:

     >

    > i can't possibly express how wrong-headed i think this is.

     There's not enough context for me to figure what you mean by "this".

    (It's something I wrote, right?)

     > = is a function from values to truth-values.  assignment has

    > a side-effect. besides, if symbols are first-class, then how

    > do you test for equality of symbols?

    >

     In what I wrote, I was assuming '=' was a function that associated

    symbols with their values.  It assigns.  Whereas you are describing

    something that tests for equality.

    Assignment *can* be implemented purely on the stack -- to avoid

    side-effects in a world where stack effects are not considered to be

    side-effects.

    Though I personally find it more interesting to explore what

    programming would be like without assignment.

     > ----- Original Message -----

    > From: "Joe Bowbeer" <joe.bowbeer@...>

    > To: <concatenative@yahoogroups.com>

    > Sent: Thursday, June 22, 2006 6:34 PM

    > Subject: Re: [stack] Define statements

    >

    >

    > > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

    > > > I see no problem with that. It is just a personal preference to avoid

    > > > overloading "=" and to place the symbol argument first.

    > > >

    > >

    > > A few thoughts:

    > >

    > > If a program is a first-class value in your language then using "="

    > > for assignment of these values seems natural.  (Assuming a symbol can

    > > only have one value.)

    > >

    > > If you place the symbol second then it's easy for one program to

    > > generate another program by leaving it on the stack, where it can be

    > > assigned or applied -- or whatever.

    > >

    > > This discussion reminds me a Scheme, where functions are first-class

    > > values.  In Scheme, though, closures (environment + continuation) eat

    > > their own trail, leading toward stackless execution.  While what you

    > > are describing, storing assignments on the stack, seems more similar

    > > to traditional dynamically-bound Lisp.

    > >

    > >

    > > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

    > > > I see no problem with that. It is just a personal preference to avoid

    > > > overloading "=" and to place the symbol argument first.

    > > >

    > > > So I could easily define def in my library using your syntax as follows:

    > > >

    > > > $def [swap =] =

    > > >

    > > >

    > > > On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>

    > > > wrote:

    > > > >

    > > > > $inc [1 +] def

    > > > >

    > > >

    > > > What's the difference between 'def' and '=' then?

    > > >

    > > > Why not the following?

    > > >

    > > > [1 +] $inc =

    > > >

    >

## stevan apter — 2006-06-23 09:54:32

    ----- Original Message -----

    From: "Joe Bowbeer" <joe.bowbeer@...>

    To: <concatenative@yahoogroups.com>

    Sent: Thursday, June 22, 2006 11:56 PM

    Subject: Re: [stack] Define statements

    > On 6/22/06, stevan apter <sa@...> wrote:

    > >

    > > i can't possibly express how wrong-headed i think this is.

    >

    > There's not enough context for me to figure what you mean by "this".

    > (It's something I wrote, right?)

    yes - i assume that cat already uses "=" for equality, so to

    overload it to mean assignment is a terrible idea.

    >

    > > = is a function from values to truth-values.  assignment has

    > > a side-effect. besides, if symbols are first-class, then how

    > > do you test for equality of symbols?

    > >

    >

    > In what I wrote, I was assuming '=' was a function that associated

    > symbols with their values.  It assigns.  Whereas you are describing

    > something that tests for equality.

    yes

    >

    > Assignment *can* be implemented purely on the stack -- to avoid

    > side-effects in a world where stack effects are not considered to be

    > side-effects.

    yes - i described one such design.

    >

    > Though I personally find it more interesting to explore what

    > programming would be like without assignment.

    i don't disagree.

    >

    >

    > > ----- Original Message -----

    > > From: "Joe Bowbeer" <joe.bowbeer@...>

    > > To: <concatenative@yahoogroups.com>

    > > Sent: Thursday, June 22, 2006 6:34 PM

    > > Subject: Re: [stack] Define statements

    > >

    > >

    > > > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

    > > > > I see no problem with that. It is just a personal preference to avoid

    > > > > overloading "=" and to place the symbol argument first.

    > > > >

    > > >

    > > > A few thoughts:

    > > >

    > > > If a program is a first-class value in your language then using "="

    > > > for assignment of these values seems natural.  (Assuming a symbol can

    > > > only have one value.)

    > > >

    > > > If you place the symbol second then it's easy for one program to

    > > > generate another program by leaving it on the stack, where it can be

    > > > assigned or applied -- or whatever.

    > > >

    > > > This discussion reminds me a Scheme, where functions are first-class

    > > > values.  In Scheme, though, closures (environment + continuation) eat

    > > > their own trail, leading toward stackless execution.  While what you

    > > > are describing, storing assignments on the stack, seems more similar

    > > > to traditional dynamically-bound Lisp.

    > > >

    > > >

    > > > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:

    > > > > I see no problem with that. It is just a personal preference to avoid

    > > > > overloading "=" and to place the symbol argument first.

    > > > >

    > > > > So I could easily define def in my library using your syntax as follows:

    > > > >

    > > > > $def [swap =] =

    > > > >

    > > > >

    > > > > On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>

    > > > > wrote:

    > > > > >

    > > > > > $inc [1 +] def

    > > > > >

    > > > >

    > > > > What's the difference between 'def' and '=' then?

    > > > >

    > > > > Why not the following?

    > > > >

    > > > > [1 +] $inc =

    > > > >

    > >

    >

    >

    >

    >

    > Yahoo! Groups Links

    >

    >

    >

    >

    >

    >

    >

## stevan apter — 2006-07-05 22:05:28

    the solution i've settled on for F says that everything is a

    function from (environment;stack;queue) to (environment;stack;queue).

    The environment is an association of names and values.  Assignment

    updates the input environment and returns a new environment.

    functions are free to do what they want with any component of an

    input triple.

    i suppose this is implementation-dependent, but keeping the

    environment distinct from the stack, at least conceptually, seems

    like a good thing.  the stack is where results go; the environment

    is where bindings go.

     ----- Original Message -----

    From: "Christopher Diggins" <cdiggins@...>

    To: <concatenative@yahoogroups.com>

    Sent: Thursday, June 22, 2006 3:24 PM

    Subject: Re: [stack] Define statements

    > ".. introduces state ... "

    >

    > Good point John. Here is a possible (but not completely thought out)

    > solution: allow the definition of symbols as special hash-table values on

    > the stack. Global functions are defined at the bottom of the stack. Each

    > symbol-hash table acts like a local scope.

    >

    >

    > [Non-text portions of this message have been removed]

    >

    >

    >

    >

    >

    > Yahoo! Groups Links

    >

    >

    >

    >

    >

    >

## Christopher Diggins — 2006-07-06 15:48:32

    Hi Stevan, What you propose is definitely a reasonable solution.

    In Cat however I want to be able to incorporate the idea of nested scope and

    nested namespaces. In other words, I want to create environments within

    environments. This makes it easier for people developing very complex

    software, and it makes mappings from other languages more smooth.

    A natural way to do this is to say that each function can have its own

    bindings (or environment if you prefer) which requires all definitions to be

    unambiguous and resolvable at compile-time. So no reassignments.

    In pseudo-code:

    define f = a [define g = c; g d] e;

    - Christopher

     On 7/5/06, stevan apter <sa@...> wrote:

    >

    >    the solution i've settled on for F says that everything is a

    > function from (environment;stack;queue) to (environment;stack;queue).

    >

    > The environment is an association of names and values. Assignment

    > updates the input environment and returns a new environment.

    >

    > functions are free to do what they want with any component of an

    > input triple.

    >

    > i suppose this is implementation-dependent, but keeping the

    > environment distinct from the stack, at least conceptually, seems

    > like a good thing. the stack is where results go; the environment

    > is where bindings go.

    >

    >

    > ----- Original Message -----

    > From: "Christopher Diggins" <cdiggins@... <cdiggins%40gmail.com>>

    > To: <concatenative@yahoogroups.com <concatenative%40yahoogroups.com>>

    > Sent: Thursday, June 22, 2006 3:24 PM

    > Subject: Re: [stack] Define statements

    >

    > > ".. introduces state ... "

    > >

    > > Good point John. Here is a possible (but not completely thought out)

    > > solution: allow the definition of symbols as special hash-table values

    > on

    > > the stack. Global functions are defined at the bottom of the stack. Each

    > > symbol-hash table acts like a local scope.

    > >

    > >

    > > [Non-text portions of this message have been removed]

    > >

    > >

    > >

    > >

    > >

    > > Yahoo! Groups Links

    > >

    > >

    > >

    > >

    > >

    > >

    >

    >

    >

    [Non-text portions of this message have been removed]

## stevan apter — 2006-07-06 21:22:04

    hi christopher

    so you want to be able to say things like

        f is g h

         where g is i j

                where i is ..

                where j is ..

         where h is ..

    where g and h are local to f and i and j are local to g.

    a couple of questions:

    can g and h see each other?

    can i see g?  f?

    what kind of scoping rules do you envision?

    i realize that this is a well-worn topic in language theory,

    although i'm not myself well-acquainted with all the options

    or terminology.  i had to work my way (painfully) through

    the alternatives before i had something which was flexible

    enough to scale to my satisfaction.  here's my description

    of the scoping rules for SLACK:

    http://nsl.com/k/slack/slack.htm#2.4%20Definitions

    and here's a ray-tracer which demonstrates nested scope:

    http://nsl.com/k/slack/slack.htm#Ray%20tracer

    would you want to supplement the expression language with non-

    functional keywords like 'def' and 'where'?

    this could be avoided with dot-notation.  e.g. the above example

    could be written:

        g h : f

        i j : f.g

        ..  : f.g.i

        ..  : f.g.j

        ..  : h

    : is assignment.  a name is explicitly scoped by its structure.

    (leading dots climb the tree.)

    (you don't even need the : since you don't support reassignment:

    in interpretation, if a name is undefined, assign it; if it is

    defined, use it.)

     ----- Original Message -----

    From: "Christopher Diggins" <cdiggins@...>

    To: <concatenative@yahoogroups.com>

    Sent: Thursday, July 06, 2006 11:48 AM

    Subject: Re: [stack] Define statements

    > Hi Stevan, What you propose is definitely a reasonable solution.

    >

    > In Cat however I want to be able to incorporate the idea of nested scope and

    > nested namespaces. In other words, I want to create environments within

    > environments. This makes it easier for people developing very complex

    > software, and it makes mappings from other languages more smooth.

    >

    > A natural way to do this is to say that each function can have its own

    > bindings (or environment if you prefer) which requires all definitions to be

    > unambiguous and resolvable at compile-time. So no reassignments.

    >

    > In pseudo-code:

    >

    > define f = a [define g = c; g d] e;

    >

    > - Christopher

    >

    > On 7/5/06, stevan apter <sa@...> wrote:

    > >

    > >    the solution i've settled on for F says that everything is a

    > > function from (environment;stack;queue) to (environment;stack;queue).

    > >

    > > The environment is an association of names and values. Assignment

    > > updates the input environment and returns a new environment.

    > >

    > > functions are free to do what they want with any component of an

    > > input triple.

    > >

    > > i suppose this is implementation-dependent, but keeping the

    > > environment distinct from the stack, at least conceptually, seems

    > > like a good thing. the stack is where results go; the environment

    > > is where bindings go.

    > >

    > >

    > > ----- Original Message -----

    > > From: "Christopher Diggins" <cdiggins@... <cdiggins%40gmail.com>>

    > > To: <concatenative@yahoogroups.com <concatenative%40yahoogroups.com>>

    > > Sent: Thursday, June 22, 2006 3:24 PM

    > > Subject: Re: [stack] Define statements

    > >

    > > > ".. introduces state ... "

    > > >

    > > > Good point John. Here is a possible (but not completely thought out)

    > > > solution: allow the definition of symbols as special hash-table values

    > > on

    > > > the stack. Global functions are defined at the bottom of the stack. Each

    > > > symbol-hash table acts like a local scope.

    > > >

    > > >

    > > > [Non-text portions of this message have been removed]

    > > >

    > > >

    > > >

    > > >

    > > >

    > > > Yahoo! Groups Links

    > > >

    > > >

    > > >

    > > >

    > > >

    > > >

    > >

    > >

    > >

    >

    >

    > [Non-text portions of this message have been removed]

    >

    >

    >

    >

    >

    > Yahoo! Groups Links

    >

    >

    >

    >

    >

    >

    >

## Christopher Diggins — 2006-07-08 17:24:36

    Hi Stevan,

    I want to make Cat as close to a simple imperative language as

    possible (like C). So the scoping will be resembly any other Algol

    derived language.

    def j { ... }

    def h { ... }

    def i { ... }

    def g { i j }

    def f { g h }

    This is the reverse of what you propose. Definitions like this would

    persist until the end of the closing block " { } ".

    In this syntax I am using { } as grouping operators.

     On 7/6/06, stevan apter <sa@...> wrote:

    >

    >

    >

    >

    >

    >

    >

    > hi christopher

    >

    > so you want to be able to say things like

    >

    > f is g h

    > where g is i j

    > where i is ..

    > where j is ..

    > where h is ..

    >

    > where g and h are local to f and i and j are local to g.

    >

    > a couple of questions:

    >

    > can g and h see each other?

    >

    > can i see g? f?

    >

    > what kind of scoping rules do you envision?

## Manfred Von Thun — 2006-07-26 07:50:06

    On 23/6/06 5:24 AM, "Christopher Diggins" <cdiggins@...> wrote:

     >

    >

    >

    >

    > ".. introduces state ... "

    >

    > Good point John. Here is a possible (but not completely thought out)

    > solution: allow the definition of symbols as special hash-table values on

    > the stack. Global functions are defined at the bottom of the stack. Each

    > symbol-hash table acts like a local scope.

    >

    > [Non-text portions of this message have been removed]

    >

     I am very much behind in my reading of the mail  selling a house and

    clearing

    out 34 years of accumulated junk takes a lot of time.

    On the question whether a hashtable of symbolvalue associations sitting

    somewhere on the stack would change Joy from being stateless (no assignment,

    purely functional) to being ³statefull²: I think the answer is NO. Here is

    my tentative argument  for your consideration.

    The argument takes the form

        if p then q, if q then r, if r then s, if s then t, but not-t, therefore

    not-p

    If such a hashtable adds state, then so does a simpler less efficient

    implementation that uses a linear list of symbol-value pairs. (Lookup and

    update are quite easy.)

    If such a linear list of associations adds state, then so does a more

    primitive implementation of just a linear list of values. (Lookup is now by

    operators such as first, second, third .. or by indexed access. Update also

    straightforward.)

    If such a list of values adds state, then so does a single list of just one

    value. (Now lookup and update are quite trivial)

    If a single list of just one value adds state, then so does a bare single

    value.

    (Now lookup is a noop, the value is just sitting there, and update is just

    the use of some operator.)

    But a bare single value does not add state.

    Therefore a hashtable sitting somewhere on the stack does not add state.

    Thoughts much appreciated.

      - Manfred

    [Non-text portions of this message have been removed]

## Manfred Von Thun — 2006-07-26 08:22:05

    On 7/7/06 1:48 AM, "Christopher Diggins" <cdiggins@...> wrote:

     >

    >

    >

    >

    > Hi Stevan, What you propose is definitely a reasonable solution.

    >

    > In Cat however I want to be able to incorporate the idea of nested scope and

    > nested namespaces. In other words, I want to create environments within

    > environments. This makes it easier for people developing very complex

    > software, and it makes mappings from other languages more smooth.

    >

    > A natural way to do this is to say that each function can have its own

    > bindings (or environment if you prefer) which requires all definitions to be

    > unambiguous and resolvable at compile-time. So no reassignments.

    >

    > In pseudo-code:

    >

    > define f = a [define g = c; g d] e;

    >

    > - Christopher

    >

     In Joy you would write this as

        DEFINE

           HIDE  g  ==  c

           IN      f   ==  a g d e.

    You can even have several definitions in the HIDE-part and in the IN-part:

        DEFINE

            HIDE  g1  ==  c1;  g2  ==  c2

            IN      f1   ==  a g1 d e;   f2  ==  h g1 g2 i.

    Now f1 and f2 are globally defined, and both have access to g1 and g2. But

    g1 and g2 are invisible outside the IN-part. Such a treatment of locality is

    not possible in Algolic block structure. But to some extent the effect can

    be achieved in the C language in which some declarations are local to a file

    (the HIDE-part), and some declarations in that file become global (the

    IN-part). But I don¹t think any construction in C would allow you to have

    HIDE-parts and IN-parts inside other HIDE-parts and IN-parts, as you can in

    Joy. Nevertheless, the inspiration came from C.

    I was rather pleased with HIDE..IN.., but from memory the group did not

    like it.

      - Manfred

    [Non-text portions of this message have been removed]

## William Tanksley, Jr — 2006-07-26 15:39:03

    Manfred Von Thun <m.vonthun@...> wrote:

     > If such a hashtable adds state, then so does a simpler less efficient

    > implementation that uses a linear list of symbol-value pairs. (Lookup and

    > update are quite easy.)

     We have to appreciate having a professor of logic in our discussion group :-).

    [...]

     > If a single list of just one value adds state, then so does a bare single

    > value.

    > (Now lookup is a noop, the value is just sitting there, and update is just

    > the use of some operator.)

    > But a bare single value does not add state.

     This is false. A bare single variable that can be updated and examined

    does add state, because the actual value in the variable can affect

    the execution of the program. In such a case, the value of the lone

    variable, plus the value of the stack, plus the value of the 'queue'

    (or whatever we use) would be called the state of the program. If you

    did not know the value of the variable, you could never predict the

    result of certain program operations.

     >   - Manfred

     -Billy

## Manfred Von Thun — 2006-08-04 08:25:14

    On 27/7/06 1:39 AM, "William Tanksley, Jr" <wtanksleyjr@...> wrote:

     >

    > Manfred Von Thun <m.vonthun@... <mailto:m.vonthun%40latrobe.edu.au>

    > > wrote:

    >

    >> > If a single list of just one value adds state, then so does a bare single

    >> > value.

    >> > (Now lookup is a noop, the value is just sitting there, and update is just

    >> > the use of some operator.)

    >

    >> > But a bare single value does not add state.

    >

    > This is false. A bare single variable that can be updated and examined

    > does add state, because the actual value in the variable can affect

    > the execution of the program. In such a case, the value of the lone

    > variable, plus the value of the stack, plus the value of the 'queue'

    > (or whatever we use) would be called the state of the program. If you

    > did not know the value of the variable, you could never predict the

    > result of certain program operations.

    >

    > -Billy

     The argument starts with a hashtable somewhere on the stack, and ends with a

    bare single value somewhere on the stack. That bare single value  might be

    just a number, say 5, on top of the stack. We can change it with an operator

    (by doing taking its square, say) , thus updating what is on top of the

    stack. That¹s just purely functional concatenative programming without a

    separate state. So a bare single value does not add state. If there is a

    flaw in my argument, it must be in one of the earlier (conditional)

    premises.

    But I cannot see which one it might be.

      - Manfred

    [Non-text portions of this message have been removed]

## William Tanksley, Jr — 2006-08-04 14:01:13

    Manfred Von Thun <m.vonthun@...> wrote:

     > On 27/7/06 1:39 AM, "William Tanksley, Jr" <wtanksleyjr@...> wrote:

    > >> > (Now lookup is a noop, the value is just sitting there, and update is just

    > >> > the use of some operator.)

    > >> > But a bare single value does not add state.

    > > This is false. A bare single variable that can be updated and examined

    > > does add state, because the actual value in the variable can affect

    > > the execution of the program. In such a case, the value of the lone

    > > variable, plus the value of the stack, plus the value of the 'queue'

    > > (or whatever we use) would be called the state of the program. If you

    > > did not know the value of the variable, you could never predict the

    > > result of certain program operations.

    > The argument starts with a hashtable somewhere on the stack, and ends with a

    > bare single value somewhere on the stack.

     There's the missing link: I didn't know that you were talking about a

    hashtable "somewhere on the stack". We were discussing redefinitions,

    not mutable data.

     > That bare single value  might be

    > just a number, say 5, on top of the stack. We can change it with an operator

    > (by doing taking its square, say) , thus updating what is on top of the

    > stack. That¹s just purely functional concatenative programming without a

    > separate state. So a bare single value does not add state.

    > If there is a

    > flaw in my argument, it must be in one of the earlier (conditional)

    > premises.

    > But I cannot see which one it might be.

     Let's go back to the list containing one item. Now suppose that you're

    allowed to mutate it, and also at any point in the program get, store,

    and manipulate a reference to it. NOW its value is considered state,

    because you can't staticly track what its value might be. It's become

    a variable, not merely a data item.

    This is the issue with allowing redefinitions.

     >   - Manfred

     -Billy

## John Cowan — 2006-08-21 19:19:54

    Manfred Von Thun scripsit:

     > The argument starts with a hashtable somewhere on the stack, and ends with a

    > bare single value somewhere on the stack. That bare single value  might be

    > just a number, say 5, on top of the stack. We can change it with an operator

    > (by doing taking its square, say) , thus updating what is on top of the

    > stack. That's just purely functional concatenative programming without a

    > separate state. So a bare single value does not add state. If there is a

    > flaw in my argument, it must be in one of the earlier (conditional)

    > premises.

     The flaw is that a hashtable cannot be reduced to a single unboxed value on

    the stack; at best it can be reduced to a pointer to a boxed and mutable

    value.  Currently all the things that can be pushed on the stack are

    immutable, being either atomic values or immutable lists (no set-car! or

    set-cdr! operations in Joy).

    --

    With techies, I've generally found              John Cowan

    If your arguments lose the first round          http://www.ccil.org/~cowan

        Make it rhyme, make it scan                 cowan@...

        Then you generally can

    Make the same stupid point seem profound!           --Jonathan Robie

## Manfred Von Thun — 2006-08-29 06:45:44

    On 22/8/06 5:19 AM, "John Cowan" <cowan@...> wrote:

     >

    >

    >

    >

    > Manfred Von Thun scripsit:

    >

    >> > The argument starts with a hashtable somewhere on the stack, and ends with

     a

     >> > bare single value somewhere on the stack. That bare single value  might be

    >> > just a number, say 5, on top of the stack. We can change it with an

    >> operator

    >> > (by doing taking its square, say) , thus updating what is on top of the

    >> > stack. That's just purely functional concatenative programming without a

    >> > separate state. So a bare single value does not add state. If there is a

    >> > flaw in my argument, it must be in one of the earlier (conditional)

    >> > premises.

    >

    > 0The flaw is that a hashtable cannot be reduced to a single unboxed value on

    > the stack; at best it can be reduced to a pointer to a boxed and mutable

    > value.  Currently all the things that can be pushed on the stack are

    > immutable, being either atomic values or immutable lists (no set-car! or

    > set-cdr! operations in Joy).

     First, let me make it clear that I was not arguing against implementing

    hashtables

    somewhere on the stack. Such facility would make a lot of programming in Joy

    much

    easier and clearer.

    Ignoring get and put and other file manipulations, Joy programs compute

    functions

    from stacks to stacks. The programs can change the stack in its entirety.

    But the

    changes are not like assignment  or set-car! or set-cdr!, as you rightly

    observe,

    so Joy is purely functional., and not procedural.

    My argument had the conclusion: adding hashtable(s) somewhere on the stack

    does not destroy the purely functional nature of Joy. The first step was

    this:

    hashtables are an efficient way to implement name/value associations, but

    the efficiency is just a welcome bonus. Another way to implement such

    associations is by a  crude list of pairs, such as

        [ [year 2006] [pi 3.16] [greeting ³hello my friend²] ...]

    Anything hashtables can do can be done by such lists of association pairs,

    initialisation, lookup, redefinition (!),  undefine ...

    Of some interest might be redefinition:

    assuming the list  has been taken to the top of the stack, here is how you

    change the value of pi:

        uncons unswons uncons pop [3.14] cons swons uncons

    alternatively, you might use a search to find the pair that starts with pi

    and then change to 3.14.

    Since  hashtables and lists of pairs differ only in their efficiency, not in

    their

    semantics, I maintain:

    The first conditional:

        if adding hashtables somewhere on the stack makes Joy procedural,

        then adding lists of association pairs on the stack makes Joy

    procedural.

    Are we at least agreed on this conditional?

    I am a little puzzled by what you meant by ³reduced² here  I was only

    concerned with the question whether hashtables change the nature of Joy.

    But thanks for the comment, John. I have finally been thrown off

    the old mainframe (they had to kill it to get me off, screaming loud

    protests). Now somebody here is going to implant gcc into this

    dreadful eMac that I have been condemned to use, for sins that

    I must have committed. I still dread the entire transplant, and fear

    the worst. But one day I shall be ready to try out your Scheme

    implementation of Joy. In the meantime I wish you luck with it.

    As I mentioned some time ago, I have sold my house and emptied

    it of more than 3 decades of accumulated junk, and that has kept

    me rather busy. I hope to be around uni a bit more.

    Best wishes to all

      - Manfred

    [Non-text portions of this message have been removed]