# Re: [stack] conk manual

## stevan apter — 2000-06-23 16:51:42

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

    From: stevan apter <apter@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 23, 2000 10:40 AM

    Subject: [stack] conk manual

    > each-

    > right.  the latter two may always be replaced by projection-with-each:

    > a f each-left b -> f[a]each b, and a f each-right b -> f[;b]each a.

    of course, i defined these backwards.  should be:

    a f each-right b -> f[a]each b, and a f each-left b -> f[;b]each a.

    > (i exclude

    > dictionary recursion from consideration, since a conservative

    > extension of atomic application to those datatypes is well known).

    so well known, in fact, that i've added it to the latest version

    of conk; e.g.

        k>[[ten 10][twenty 20][thirty 30]]d 1 +

        k>[[ten 11 nil] [twenty 21 nil] [thirty 31 nil]] d

    a further (conservative) extension involves defining the shape of

    a dictionary to be the list of its entries, &c., and, in general,

    extending the list primitives to dictionaries.  for example, the

    transpose of an n-dimensional dictionary is a dictionary with its

    first two levels swapped.  this is particularly useful when we

    represent crosstabulations as two dimensional dictionaries of

    atomic elements.  i haven't implemented the list extensions yet

    (although i probably will).

    you may wonder about the nils in conk's dictionary display.

    the explanation is that k dictionaries are structures of

    triples - name, value, dictionary or nil.  the third element

    is a dictionary of what we call attributes.  for example, the

    variable a.b (the entry `b in the dictionary a) may have a

    value (e.g. 20), and it may also have a set of attributes;

    for example, foreground and background colors a..fg and a..bg.

    fg and bg are variables in the attribute dictionary of a.

    they in turn may have attributes as well as values, &c.

    this seques into an interesting question - i think it may be a

    central one for conk.  namely, the effect of identifying lists

    with intensional quotation (i know this question vexes you billy).

    for example, in k, i can define a list

            (2+2;3-4)

    which is fully evaluated to be

            (4;-1)

    but of course in joy the list

            [[2 2 +][3 4 -]]

    is a list of unevaluated programs.  so while in k i can say

            .((`one;10;.((`fg;99);(`bg;9900)));(`two;20))

    in conk i cannot say

            [[one 10 [[fg 99][bg 9900]]d][two 20]]d

    the attribute dictionary for entry one is not constructed.  instead,

    i have to do by explicitly amending one dictionary at the appropriate

    attribute dictionary position with a second dictionary:

        k>[[one 10][two 20]]d one dot [is] [[fg 99][bg 9900]]d id atofwith

        [[one 10 [[fg 99 nil] [bg 9900 nil]] d] [two 20 nil]] d

    which in turn is a translation into conk of the k expression:

        @[.((`one;10);(`two;20));`one.;:;.((`fg;99);(`bg;9900))]

    .((`one

       10

       .((`fg;99;)

         (`bg;9900;)))

      (`two;20;))

    in focussing on applicative/combinative vs. concatenative, we

    may tend to lose sight of this further difference, which (i think)

    has an equally significant impact on programming.  (i think manfred

    has something to say about this issue in the 'rewriting' paper on

    his website.)

## Louis Madon — 2000-06-24 05:46:35

    stevan apter wrote:

     > for example, in k, i can define a list

    >

    >         (2+2;3-4)

    >

    > which is fully evaluated to be

    >

    >         (4;-1)

    >

    > but of course in joy the list

    >

    >         [[2 2 +][3 4 -]]

    >

    > is a list of unevaluated programs.  so while in k i can say

    >

    >         .((`one;10;.((`fg;99);(`bg;9900)));(`two;20))

    >

    > in conk i cannot say

    >

    >         [[one 10 [[fg 99][bg 9900]]d][two 20]]d

    >

    > the attribute dictionary for entry one is not constructed.

     I agree that the way Joy blends aggregation and quotation with the []

    syntax is not always convenient. Perhaps there should be a separate

    syntax for specifying just aggregation.  For example, if the curly

    brackets denoted this, then your example would be:

    	{{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d

    Notice that 'one' and 'two' are still quoted since we only want their

    symbols. Everything else will be fully evaluated. In effect, the above

    exression could be syntactic sugar for:

    [[fg 99][bg 9900]]d unitlist 10 cons [one] cons 20 unitlist [two] cons

    pair d

    So, {} need not represent any fundamental changes to the language.

     >

    > in focussing on applicative/combinative vs. concatenative, we

    > may tend to lose sight of this further difference, which (i think)

    > has an equally significant impact on programming.

     I don't see how its equally significant. Its just a matter of not

    applying quotation needlessly. Any system that supports quotation will

    have this issue. (Can you meta-program in K?).

    --

    Louis.

## stevan apter — 2000-06-24 12:29:29

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, June 24, 2000 1:46 AM

    Subject: Re: [stack] conk manual

    > Perhaps there should be a separate

    > syntax for specifying just aggregation.  For example, if the curly

    > brackets denoted this, then your example would be:

    >

    > {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d

    >

    > Notice that 'one' and 'two' are still quoted since we only want their

    > symbols. Everything else will be fully evaluated. In effect, the above

    > exression could be syntactic sugar for:

    >

    > [[fg 99][bg 9900]]d unitlist 10 cons [one] cons 20 unitlist [two] cons

    > pair d

    >

    > So, {} need not represent any fundamental changes to the language.

    this is a very nice idea.  thanks!

    >

    > >

    > > in focussing on applicative/combinative vs. concatenative, we

    > > may tend to lose sight of this further difference, which (i think)

    > > has an equally significant impact on programming.

    >

    > I don't see how its equally significant. Its just a matter of not

    > applying quotation needlessly. Any system that supports quotation will

    > have this issue. (Can you meta-program in K?).

    i think so (i never understand what people have in mind when they

    use this term).

    thanks again.

    >

    >

    > --

    > Louis.

    >

    > ------------------------------------------------------------------------

    > Special eGroups Offer: Save On Long Distance Today!

    > http://click.egroups.com/1/5073/7/_/_/_/961825285/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-06-24 13:08:45

    the simplest implementation would seem to be to modify the parser

    to invoke the evaluater on braced expressions:

        k>{2 2 +}

        k>5

    this approach is easy to code, requiring the single line

        i.e:{n:(=/+\'x=/:"{}")?1;((n+1)_ x;y,().k.E/I 1_ n#x)}

    that is, if the first character is a '{', find the mated '}',

    parse what's between them, evaluate that, and return it and

    what's left to parse.

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, June 24, 2000 1:46 AM

    Subject: Re: [stack] conk manual

    > stevan apter wrote:

    >

    > > for example, in k, i can define a list

    > >

    > >         (2+2;3-4)

    > >

    > > which is fully evaluated to be

    > >

    > >         (4;-1)

    > >

    > > but of course in joy the list

    > >

    > >         [[2 2 +][3 4 -]]

    > >

    > > is a list of unevaluated programs.  so while in k i can say

    > >

    > >         .((`one;10;.((`fg;99);(`bg;9900)));(`two;20))

    > >

    > > in conk i cannot say

    > >

    > >         [[one 10 [[fg 99][bg 9900]]d][two 20]]d

    > >

    > > the attribute dictionary for entry one is not constructed.

    >

    > I agree that the way Joy blends aggregation and quotation with the []

    > syntax is not always convenient. Perhaps there should be a separate

    > syntax for specifying just aggregation.  For example, if the curly

    > brackets denoted this, then your example would be:

    >

    > {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d

    >

    > Notice that 'one' and 'two' are still quoted since we only want their

    > symbols. Everything else will be fully evaluated. In effect, the above

    > exression could be syntactic sugar for:

    >

    > [[fg 99][bg 9900]]d unitlist 10 cons [one] cons 20 unitlist [two] cons

    > pair d

    >

    > So, {} need not represent any fundamental changes to the language.

    >

    > >

    > > in focussing on applicative/combinative vs. concatenative, we

    > > may tend to lose sight of this further difference, which (i think)

    > > has an equally significant impact on programming.

    >

    > I don't see how its equally significant. Its just a matter of not

    > applying quotation needlessly. Any system that supports quotation will

    > have this issue. (Can you meta-program in K?).

    >

    >

    > --

    > Louis.

    >

    > ------------------------------------------------------------------------

    > Special eGroups Offer: Save On Long Distance Today!

    > http://click.egroups.com/1/5073/7/_/_/_/961825285/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## wtanksley@bigfoot.com — 2000-06-24 17:59:41

    From: Louis Madon [mailto:madonl@...]

     >I agree that the way Joy blends aggregation and quotation with the []

    >syntax is not always convenient. Perhaps there should be a separate

    >syntax for specifying just aggregation.  For example, if the curly

    >brackets denoted this, then your example would be:

     I agree.  However, because I also believe that we need a 'function' datatype

    and a way to enter 'function' literals, I would prefer using ` to indicate

    quotation.  Thus,

    [this is aggregation]

    `[this is quoted aggregation]

    [`this `is `quoted `aggregation]

    `this `is `quotation `without `aggregation

    See what I mean?

     >Louis.

     -Billy

## Louis Madon — 2000-06-25 08:29:51

    wtanksley@... wrote:

     >

    > From: Louis Madon [mailto:madonl@...]

    >

    > >I agree that the way Joy blends aggregation and quotation with the []

    > >syntax is not always convenient. Perhaps there should be a separate

    > >syntax for specifying just aggregation.  For example, if the curly

    > >brackets denoted this, then your example would be:

    >

    > I agree.  However, because I also believe that we need a 'function'

    > datatype

    > and a way to enter 'function' literals, I would prefer using ` to

    > indicate

    > quotation.  Thus,

    >

    > [this is aggregation]

    > `[this is quoted aggregation]

    > [`this `is `quoted `aggregation]

    > `this `is `quotation `without `aggregation

    >

    > See what I mean?

     Yes, I like this. It makes aggregation and quotation orthogonal. I

    wonder about quotation+aggregation which seems to be a very common case.

    I would prefer not to have to type two characters ('[) every time

    (though I certainly recognize the mnemonic benefit of doing it that

    way).

    Also, a possible alternative to backquote is backslash. Backslash is

    consistent with escaping inside strings (why introduce a different

    character for something that is conceptually similar?) and it is not

    easy to confuse with forward quote.

    For example:

    [this is quoted aggregation]

    {this is aggregation}

    \this \is \quotation \without \aggregation

    I think its hard to decide without gaining some experience with a few

    styles. Whatever syntax is chosen, I'm quite certain its worth doing.

    --

    Louis.

## Louis Madon — 2000-06-25 10:37:20

    stevan apter wrote:

     >

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

    > From: Louis Madon <madonl@...>

    > > I don't see how its equally significant. Its just a matter of not

    > > applying quotation needlessly. Any system that supports quotation

    > will

    > > have this issue. (Can you meta-program in K?).

    >

    > i think so (i never understand what people have in mind when they

    > use this term).

     Yes, it is a rather loose term.  What I meant was: does K allow you to

    treat code as data? To do that it must provide some means to distinguish

    between code to be executed and code to be treated as data, ie.

    quotation. If so, then K programmers need to deal with the exact same

    issue.

    --

    Louis.

## stevan apter — 2000-06-25 12:59:07

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Sunday, June 25, 2000 4:29 AM

    Subject: Re: [stack] conk manual

    > wtanksley@... wrote:

    > >

    > > From: Louis Madon [mailto:madonl@...]

    >

    > For example:

    >

    > [this is quoted aggregation]

    > {this is aggregation}

    > \this \is \quotation \without \aggregation

    >

    >

    > I think its hard to decide without gaining some experience with a few

    > styles. Whatever syntax is chosen, I'm quite certain its worth doing.

    in conk, extracting a function from its quotation leaves it on the stack:

        k>1 2 [+] first

        1 2 +

    at which point it can be applied with i:

        k>i

        3

    so

        q == [id] step

    gives:

        k>[+ - *]q

        + - *

    >

    >

    > --

    > Louis.

    >

    > ------------------------------------------------------------------------

    > STEALS AND DEALS! Cheapest prices on airfare, new cars, insurance, maids,

    > contractors, collectibles, more. Get exactly what you want at the lowest

    > price. New FREE service!

    > http://click.egroups.com/1/5746/7/_/_/_/961921482/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-06-25 13:13:24

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Sunday, June 25, 2000 6:37 AM

    Subject: Re: [stack] conk manual

    > stevan apter wrote:

    > >

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

    > > From: Louis Madon <madonl@...>

    > > > I don't see how its equally significant. Its just a matter of not

    > > > applying quotation needlessly. Any system that supports quotation

    > > will

    > > > have this issue. (Can you meta-program in K?).

    > >

    > > i think so (i never understand what people have in mind when they

    > > use this term).

    >

    > Yes, it is a rather loose term.  What I meant was: does K allow you to

    > treat code as data? To do that it must provide some means to distinguish

    > between code to be executed and code to be treated as data, ie.

    > quotation. If so, then K programmers need to deal with the exact same

    > issue.

    yes, we can represent code as data, in the form of a string; and there is

    an execute operation.  but strings have no structure, and consequently

    execute executes the whole string:

        s:"((2+3);(4*5-6))"

        . s

      5 -4

    by contrast, joy quotations have structure, and, like the one we were

    discussing, we often want some parts evaluated and others not.  that's

    why your proposal for adding {} solves the problem - it gives us the

    structuring power of lists without the quotational property.

    >

    >

    > --

    > Louis.

    >

    > ------------------------------------------------------------------------

    > Get a NextCard Visa, in 30 seconds!

    > 1. Fill in the brief application

    > 2. Receive approval decision within 30 seconds

    > 3. Get rates as low as 2.9% Intro or 9.9% Fixed APR

    > http://click.egroups.com/1/5197/7/_/_/_/961929130/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## Louis Madon — 2000-06-26 01:16:57

    [I also posted an earlier response yesterday via the egroups' website

    but it hasn't appeared. Does anyone know if posting that way ever

    works?]

    stevan apter wrote:

     > > wtanksley@... wrote:

    > > >

    > > > From: Louis Madon [mailto:madonl@...]

    > >

    > > For example:

    > >

    > > [this is quoted aggregation]

    > > {this is aggregation}

    > > \this \is \quotation \without \aggregation

    > >

    > >

    > > I think its hard to decide without gaining some experience with a

    > few

    > > styles. Whatever syntax is chosen, I'm quite certain its worth

    > doing.

    >

    > in conk, extracting a function from its quotation leaves it on the

    > stack:

    >

    >     k>1 2 [+] first

    >     1 2 +

     Same as in Joy, but I would prefer that the response was:

         k>1 2 [+] first

         1 2 \+

    since I feel that any particular state of the stack should be rendered

    in a way that replaying that sequence onto an emtpy stack will reproduce

    the original state.

    Pushing,

        1 2 +   gives  3         (this is not the original 1 2 + )

    whereas, if we have a quotation syntax, then

        1 2 \+  gives  1 2 \+    (original state reproduced)

     >

    > at which point it can be applied with i:

    >     k>i

    >     3

     So in conk, i is able to accept individually quoted functions in

    addition to normal (aggregate) quotations. I fully agree with this

    because essentially the meaning of i is execution. Quoted functions and

    aggregate quotations are both executable (allowing i for one and not the

    other - as in Joy - seems to be an anomaly; what justification could

    there be?).

     >

    > so

    >

    >     q == [id] step

    >

    > gives:

    >

    >     k>[+ - *]q

    >     + - *

     Are you intending q to be an alternative for backquote/backslash? If so,

    then:

         k>1 2 [+] first

         1 2 [+]q

    --

    Louis.

## stevan apter — 2000-06-26 03:40:03

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Sunday, June 25, 2000 9:16 PM

    Subject: Re: [stack] conk manual

    > [I also posted an earlier response yesterday via the egroups' website

    > but it hasn't appeared. Does anyone know if posting that way ever

    > works?]

    >

    > stevan apter wrote:

    > > > wtanksley@... wrote:

    > > > >

    > > > > From: Louis Madon [mailto:madonl@...]

    > > >

    > > > For example:

    > > >

    > > > [this is quoted aggregation]

    > > > {this is aggregation}

    > > > \this \is \quotation \without \aggregation

    > > >

    > > >

    > > > I think its hard to decide without gaining some experience with a

    > > few

    > > > styles. Whatever syntax is chosen, I'm quite certain its worth

    > > doing.

    > >

    > > in conk, extracting a function from its quotation leaves it on the

    > > stack:

    > >

    > >     k>1 2 [+] first

    > >     1 2 +

    >

    > Same as in Joy, but I would prefer that the response was:

    >

    >      k>1 2 [+] first

    >      1 2 \+

    >

    > since I feel that any particular state of the stack should be rendered

    > in a way that replaying that sequence onto an emtpy stack will reproduce

    > the original state.

    a nice property to have, i agree, although i can think of two

    ways to achieve it without introducing a new type of quotation

    or a new datatype:  signal an error when an operation threatens

    to leave a naked function on the stack, or proceed immediately

    to execute it.  in the second case,

        k>1 2 [+] first

        3

    is there any other reason to have individual quotation?

## Louis Madon — 2000-06-27 04:14:00

    stevan apter wrote:

     > From: Louis Madon <madonl@...>

    > > stevan apter wrote:

    > > > in conk, extracting a function from its quotation leaves it on the

    > > > stack:

    > > >

    > > >     k>1 2 [+] first

    > > >     1 2 +

    > >

    > > Same as in Joy, but I would prefer that the response was:

    > >

    > >      k>1 2 [+] first

    > >      1 2 \+

    > >

    > > since I feel that any particular state of the stack should be

    > rendered

    > > in a way that replaying that sequence onto an emtpy stack will

    > reproduce

    > > the original state.

    >

    > a nice property to have, i agree, although i can think of two

    > ways to achieve it without introducing a new type of quotation

    > or a new datatype:  signal an error when an operation threatens

    > to leave a naked function on the stack, or proceed immediately

    > to execute it.  in the second case,

    >

    >     k>1 2 [+] first

    >     3

     But the second case is not a solution at all: if I interrupt a program

    at point A, render and then reproduce the state of the stack at that

    point, and finally try to resume running from point A - it may fail. The

    sought after property is that the stack be rendered _accurately_ so that

    any subsequent reproduction is indistinguishable from the original.

    The first suggestion (the stack is never permitted to contain bare

    functions) is a solution but not, IMHO, a desirable one. For one, the

    symmetry between stack and list is broken; lists can contain bare

    functions, yet stacks cannot. Is it really worth introducing such

    restrictions just to avoid adding one new character to the syntax?

     >

    > is there any other reason to have individual quotation?

     I'm not sure.  I think its useful that quotation need not involve

    aggregation.  Its more orthogonal and can make for a simpler core

    language - aggregate types can be defined in the standard library (or at

    higher levels) rather than being primitive.

    --

    Louis.

## sa@dfa.com — 2000-06-26 18:09:19

    the latest version, implmenting voracious evaluation, has

    been posted to www.kx.com/technical/contribs/stevan/joy/

## sa@dfa.com — 2000-06-27 19:31:13

    stevan apter wrote:

     > From: Louis Madon <madonl@...>

    > > stevan apter wrote:

    > > > in conk, extracting a function from its quotation leaves it on the

    > > > stack:

    > > >

    > > >     k>1 2 [+] first

    > > >     1 2 +

    > >

    > > Same as in Joy, but I would prefer that the response was:

    > >

    > >      k>1 2 [+] first

    > >      1 2 \+

    > >

    > > since I feel that any particular state of the stack should be

    > rendered

    > > in a way that replaying that sequence onto an emtpy stack will

    > reproduce

    > > the original state.

    >

    > a nice property to have, i agree, although i can think of two

    > ways to achieve it without introducing a new type of quotation

    > or a new datatype:  signal an error when an operation threatens

    > to leave a naked function on the stack, or proceed immediately

    > to execute it.  in the second case,

    >

    >     k>1 2 [+] first

    >     3

     But the second case is not a solution at all: if I interrupt a program

    at point A, render and then reproduce the state of the stack at that

    point, and finally try to resume running from point A - it may fail. The

    sought after property is that the stack be rendered _accurately_ so that

    any subsequent reproduction is indistinguishable from the original.

         you may be right, but i can't think of a case where

         run-stop-resume does not equal run.

    The first suggestion (the stack is never permitted to contain bare

    functions) is a solution but not, IMHO, a desirable one. For one, the

    symmetry between stack and list is broken; lists can contain bare

    functions, yet stacks cannot. Is it really worth introducing such

    restrictions just to avoid adding one new character to the syntax?

         i don't like the error solution either, which is why

         i didn't choose to implement it in conk.

     >

    > is there any other reason to have individual quotation?

     I'm not sure.  I think its useful that quotation need not involve

    aggregation.  Its more orthogonal and can make for a simpler core

    language - aggregate types can be defined in the standard library (or at

    higher levels) rather than being primitive.

         is the first of a list a member of that list?  if so,

         then [+] first is a member of [+], so `+ is identical

         to +, and [+] is identical to [`+].

    --

    Louis.

    ------------------------------------------------------------------------

    I'm sure this will offend some people, but I think it's funny!

    http://click.egroups.com/1/6001/7/_/_/_/962118651/

    ------------------------------------------------------------------------

    To unsubscribe from this group, send an email to:

    concatenative-unsubscribe@egroups.com

## wtanksley@bigfoot.com — 2000-06-28 22:50:20

    From: sa@... [mailto:sa@...]

     >     is the first of a list a member of that list?  if so,

    >     then [+] first is a member of [+], so `+ is identical

    >     to +, and [+] is identical to [`+].

     Yes, I would expect [x] to be identical to [`x], because quotation implies

    escaping as well as aggregation.

    However, `x is clearly not in general equivalent to x, because x will do

    something, and `x will merely push `x on the stack.

    It's imaginable that we seperate lists from quotations, so that it would be

    impossible to dequote a list, and impossible to uncons a quotation.  This

    would certainly make [x] different from [`x].  I don't see a real reason to

    do this, though.

    Another way to seperate [x] and [`x] is to make aggregation not imply

    quotation -- thus, [x] would actually be a list containing the results of x,

    and [`x] would be a list containing x itself.

    -Billy

## Louis Madon — 2000-06-28 23:30:44

    sa@... wrote:

     >

    > > From: Louis Madon <madonl@...>

    > But the second case is not a solution at all: if I interrupt a program

    > at point A, render and then reproduce the state of the stack at that

    > point, and finally try to resume running from point A - it may fail.

    > The

    > sought after property is that the stack be rendered _accurately_ so

    > that

    > any subsequent reproduction is indistinguishable from the original.

    >

    >      you may be right, but i can't think of a case where

    >      run-stop-resume does not equal run.

     Ok, here's an example:

    1 2 [+] first   pop pop

                  ^---- stop here

    If you run this straight through, the answer is 1

    If you stop at the point indicated, use voracious evaluation to reduce

    the state of the stack to 3 and then resume you'll get a stack

    underflow.

    --

    Louis.

## stevan apter — 2000-06-29 01:14:17

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Wednesday, June 28, 2000 7:30 PM

    Subject: Re: [stack] conk manual

    > sa@... wrote:

    > >

    > > > From: Louis Madon <madonl@...>

    > > But the second case is not a solution at all: if I interrupt a program

    > > at point A, render and then reproduce the state of the stack at that

    > > point, and finally try to resume running from point A - it may fail.

    > > The

    > > sought after property is that the stack be rendered _accurately_ so

    > > that

    > > any subsequent reproduction is indistinguishable from the original.

    > >

    > >      you may be right, but i can't think of a case where

    > >      run-stop-resume does not equal run.

    >

    > Ok, here's an example:

    >

    > 1 2 [+] first   pop pop

    >               ^---- stop here

    >

    > If you run this straight through, the answer is 1

    no, it's not.  at the stop-point, the stack contains one

    item, namely 3.  here's the session transcript:

      1 2 [+] first stop pop pop

    stop

    {x;{'`stop}[];x}

       ^

    >  x        <-- stack

    ,3

    >  :        <-- resume

    (note empty stack after resuming from the stop with :)

    > If you stop at the point indicated, use voracious evaluation to reduce

    > the state of the stack to 3 and then resume you'll get a stack

    > underflow.

    actually, in conk, pop of an empty stack is the empty stack,

    so we never get an underflow.  but that's beside the point.

    my understanding (and implementation) of v.e. is that you

    you never leave the evaluation of a primitive (in this case,

    first) without compressing the stack fully.

    >

    >

    > --

    > Louis.

    >

    > ------------------------------------------------------------------------

    > Get a NextCard Visa, in 30 seconds!

    > 1. Fill in the brief application

    > 2. Receive approval decision within 30 seconds

    > 3. Get rates as low as 2.9% Intro or 9.9% Fixed APR

    > http://click.egroups.com/1/5197/7/_/_/_/962234728/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-06-29 01:21:49

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

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Wednesday, June 28, 2000 6:50 PM

    Subject: RE: [stack] conk manual

    > From: sa@... [mailto:sa@...]

    >

    > >     is the first of a list a member of that list?  if so,

    > >     then [+] first is a member of [+], so `+ is identical

    > >     to +, and [+] is identical to [`+].

    >

    > Yes, I would expect [x] to be identical to [`x], because quotation implies

    > escaping as well as aggregation.

    >

    > However, `x is clearly not in general equivalent to x, because x will do

    > something, and `x will merely push `x on the stack.

    exactly.  which is why i dislike this approach.  v.e. avoids

    introducing a new (and mysterious) datatype, avoids violating

    substitutivity of identicals, and keeps the symmetry of stack

    and list.  moreover, (i think) there is no computation which

    leaves the stack in a state which it couldn't have gotten into

    by simply entering the items which it contains.

    >

    > It's imaginable that we seperate lists from quotations, so that it would be

    > impossible to dequote a list, and impossible to uncons a quotation.  This

    > would certainly make [x] different from [`x].  I don't see a real reason to

    > do this, though.

    >

    > Another way to seperate [x] and [`x] is to make aggregation not imply

    > quotation -- thus, [x] would actually be a list containing the results of x,

    > and [`x] would be a list containing x itself.

    as per louis's suggestion, this is what {} does in conk - grouped evaluation.

    but i think you're moving away from the purity and simplicity of joy.

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Join beMANY! CLICK HERE!

    > http://click.egroups.com/1/5062/7/_/_/_/962232599/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## Louis Madon — 2000-06-29 01:40:26

    stevan apter wrote:

     > From: Louis Madon <madonl@...>

    > > >

    > > >      you may be right, but i can't think of a case where

    > > >      run-stop-resume does not equal run.

    > >

    > > Ok, here's an example:

    > >

    > > 1 2 [+] first   pop pop

    > >               ^---- stop here

    > >

    > > If you run this straight through, the answer is 1

    >

    > no, it's not.  at the stop-point, the stack contains one

    > item, namely 3.  here's the session transcript:

     Ah, I misunderstood your proposal! I thought you had meant that v.e.

    only happens at render time but you mean it happens after every

    operation. This is interesting, I'll have to think about this ...

    --

    Louis.

## Louis Madon — 2000-06-29 10:23:40

    Louis Madon wrote:

     > stevan apter wrote:

    > > From: Louis Madon <madonl@...>

    > > > >

    > > > >      you may be right, but i can't think of a case where

    > > > >      run-stop-resume does not equal run.

    > > >

    > > > Ok, here's an example:

    > > >

    > > > 1 2 [+] first   pop pop

    > > >               ^---- stop here

    > > >

    > > > If you run this straight through, the answer is 1

    > >

    > > no, it's not.  at the stop-point, the stack contains one

    > > item, namely 3.  here's the session transcript:

    >

    > Ah, I misunderstood your proposal! I thought you had meant that v.e.

    > only happens at render time but you mean it happens after every

    > operation. This is interesting, I'll have to think about this ...

    >

     I've thought about it some more but there seem to be at least two

    problems

    Problem 1

    ---------

    [+] first

    Even with v-e you'll still have a bare plus left on the stack, correct?

    Problem 2

    ---------

    unpair pair == id

    this identity does not always hold in the presence of v-e.

     (eg. consider 1 [2 +] unpair pair != 1 [2 +] id).

     In other words we can no longer use local reasoning - the context has

    to be considered too.  I believe other identities may be broken in this

    way too.

    There could be other problems, I'd have to think about it some more, but

    already it seems to me that v-e is not a solution.

    Note that the notion of an individually quoted function _type_ is

    already mentioned in Manfreds' Rewriting paper (see the section

    'Rewriting for Joy Types'). He refers to it as a 'type cancellation' and

    says [type cancellation] "... is new and has no counterpart program

    constructor". But I see no justification for not having such a

    constructor (and AFAICT, the paper does not try to justify why we

    _should not_ have one).  The ` or \ syntax would provide it.

    --

    Louis.

## stevan apter — 2000-06-29 11:03:35

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Thursday, June 29, 2000 6:23 AM

    Subject: Re: [stack] conk manual

    > Louis Madon wrote:

    > > stevan apter wrote:

    > > > From: Louis Madon <madonl@...>

    > > > > >

    > > > > >      you may be right, but i can't think of a case where

    > > > > >      run-stop-resume does not equal run.

    > > > >

    > > > > Ok, here's an example:

    > > > >

    > > > > 1 2 [+] first   pop pop

    > > > >               ^---- stop here

    > > > >

    > > > > If you run this straight through, the answer is 1

    > > >

    > > > no, it's not.  at the stop-point, the stack contains one

    > > > item, namely 3.  here's the session transcript:

    > >

    > > Ah, I misunderstood your proposal! I thought you had meant that v.e.

    > > only happens at render time but you mean it happens after every

    > > operation. This is interesting, I'll have to think about this ...

    > >

    >

    > I've thought about it some more but there seem to be at least two

    > problems

    >

    >

    > Problem 1

    > ---------

    >

    > [+] first

    >

    > Even with v-e you'll still have a bare plus left on the stack, correct?

    no, here you have an underflow, since [+] first == +.

    >

    >

    >

    > Problem 2

    > ---------

    >

    > unpair pair == id

    >

    > this identity does not always hold in the presence of v-e.

    >  (eg. consider 1 [2 +] unpair pair != 1 [2 +] id).

    yes, i agree.

    >  In other words we can no longer use local reasoning - the context has

    > to be considered too.  I believe other identities may be broken in this

    > way too.

    i don't find that troubling.  if '[x] first' means 'push x on the stack',

    and pushing x on the stack means 'evaluate x', then '[+] first' means

    'evaluate +'.  i.e.,

        [x] first == [x] i

    for non-function x, this agrees with joy's current behavior.

    >

    >

    > There could be other problems, I'd have to think about it some more, but

    > already it seems to me that v-e is not a solution.

    >

    >

    > Note that the notion of an individually quoted function _type_ is

    > already mentioned in Manfreds' Rewriting paper (see the section

    > 'Rewriting for Joy Types'). He refers to it as a 'type cancellation' and

    > says [type cancellation] "... is new and has no counterpart program

    > constructor". But I see no justification for not having such a

    > constructor (and AFAICT, the paper does not try to justify why we

    > _should not_ have one).  The ` or \ syntax would provide it.

    but then other identities would seem to be threatened:

        [x] first unitlist <-> [x]

    what exactly is [+] first unitlist?  is it [\+] or [+]?

    >

    >

    > --

    > Louis.

    >

    > ------------------------------------------------------------------------

    > Win A Digital Camera Today!

    > Girlgeeks!

    > http://click.egroups.com/1/6083/7/_/_/_/962273904/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## Louis Madon — 2000-06-29 15:38:24

    stevan apter wrote:

     > From: Louis Madon <madonl@...>

    > >

    > > Problem 1

    > > ---------

    > >

    > > [+] first

    > >

    > > Even with v-e you'll still have a bare plus left on the stack,

    > correct?

    >

    > no, here you have an underflow, since [+] first == +.

     Ok, thats a reasonable outcome.

     > >

    > > Problem 2

    > > ---------

    > >

    > > unpair pair == id

    > >

    > > this identity does not always hold in the presence of v-e.

    > >  (eg. consider 1 [2 +] unpair pair != 1 [2 +] id).

    >

    > yes, i agree.

    >

    > >  In other words we can no longer use local reasoning - the context

    > has

    > > to be considered too.  I believe other identities may be broken in

    > this

    > > way too.

    >

    > i don't find that troubling.

     Before I accept this, I'll have to think some more about the full extent

    to which local reasoning is being compromised.

     > if '[x] first' means 'push x on the

    > stack',

    > and pushing x on the stack means 'evaluate x', then '[+] first' means

    > 'evaluate +'.  i.e.,

    >

    >     [x] first == [x] i

    >

    > for non-function x, this agrees with joy's current behavior.

     This is another example of local reasoning being lost: we can no longer

    say that 'first' satisfies the rule

      [a L] first => a

    unconditionally.

    Your identity holds when x is a niladic function returning one value

    (ie. literals) because such functions can be identified by their result

    and therefore such values can be treated as their own quotation (so 3 i

    == 3 since there is no ambiguity regarding what function the number 3

    identifies - it is the function that pushes 3). In this special case,

    the above identity holds without violating any laws of either first or

    i.

     >

    > >

    > >

    > > There could be other problems, I'd have to think about it some more,

    > but

    > > already it seems to me that v-e is not a solution.

    > >

    > >

    > > Note that the notion of an individually quoted function _type_ is

    > > already mentioned in Manfreds' Rewriting paper (see the section

    > > 'Rewriting for Joy Types'). He refers to it as a 'type cancellation'

    > and

    > > says [type cancellation] "... is new and has no counterpart program

    > > constructor". But I see no justification for not having such a

    > > constructor (and AFAICT, the paper does not try to justify why we

    > > _should not_ have one).  The ` or \ syntax would provide it.

    >

    > but then other identities would seem to be threatened:

    >

    >     [x] first unitlist <-> [x]

    >

    > what exactly is [+] first unitlist?  is it [\+] or [+]?

     There is no such distinction as '+' vs '\+'.  They are the same value.

    Specifying the \ inside the square brackets is redundant. [+] is

    shorthand for putting \+ in a list. Consider - in something like [1 2 +]

    what exactly is that third element supposed to be? It can't be the +

    function itself or else the list would instantly collapse into [3].

    Introducing individual quotation is simply acknowledging that it is ok

    to have these values outside of an aggregate too.

    --

    Louis.

## wtanksley@bigfoot.com — 2000-06-29 16:41:21

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >> From: sa@... [mailto:sa@...]

    >> >     is the first of a list a member of that list?  if so,

    >> >     then [+] first is a member of [+], so `+ is identical

    >> >     to +, and [+] is identical to [`+].

    >> Yes, I would expect [x] to be identical to [`x], because

    >> quotation implies

    >> escaping as well as aggregation.

    >> However, `x is clearly not in general equivalent to x,

    >> because x will do

    >> something, and `x will merely push `x on the stack.

    >exactly.  which is why i dislike this approach.  v.e. avoids

    >introducing a new (and mysterious) datatype, avoids violating

    >substitutivity of identicals, and keeps the symmetry of stack

    >and list.

     v.e. doesn't avoid the new datatype; it merely hides it, and makes it

    impossible to manipulate.  I have no idea why you should call the 'function'

    datatype "mysterious".  I can't even guess what the rest of your accusations

    mean -- adding a function datatype fully preserves substitution, and also

    allows list manipulation, which would be practically impossible with v.e.

    except in precisely controlled situations.

     >moreover, (i think) there is no computation which

    >leaves the stack in a state which it couldn't have gotten into

    >by simply entering the items which it contains.

     True; that doesn't mean that this is a good idea.

     >> Another way to seperate [x] and [`x] is to make aggregation not imply

    >> quotation -- thus, [x] would actually be a list containing

    >> the results of x, and [`x] would be a list containing x itself.

    >as per louis's suggestion, this is what {} does in conk -

    >grouped evaluation.

    >but i think you're moving away from the purity and simplicity of joy.

     I don't like {} at _all_.  I think it's a terrible idea.  It makes FAR more

    sense to use the ` or \ operator to quote both functions and aggregations.

    I also disagree that either one would be moving away from purity; on the

    contrary, it would make all of the datatype which Joy _currently_ supports

    completely defined and easily available.  How can we be moving away by

    supporting simply what we already support fully?

    -Billy

## sa@dfa.com — 2000-06-29 17:24:08

    >

    > what exactly is [+] first unitlist?  is it [\+] or [+]?

     There is no such distinction as '+' vs '\+'.  They are the same value.

    Specifying the \ inside the square brackets is redundant. [+] is

    shorthand for putting \+ in a list. Consider - in something like [1 2 +]

    what exactly is that third element supposed to be? It can't be the +

    function itself or else the list would instantly collapse into [3].

    Introducing individual quotation is simply acknowledging that it is ok

    to have these values outside of an aggregate too.

         the third element in [1 2 +] *is* the + function itself.

         the list isn't evaluated because lists are quotations.

         i agree that \ as you explain it rationalizes joy's current

         behavior (leaving bare functions on the stack).  i disagree

         that joy should behave this way.  i think it's simpler to

         say that disquotation always implies evaluation.

         but let's think about this some more.

    --

    Louis.

    ------------------------------------------------------------------------

    Get Red Herring perspective on the flood of venture capital here and

    abroad with FREE e-newsletters: Dealflow, Dealflow Europe and VCPS.

    http://click.egroups.com/1/5015/7/_/_/_/962292819/

    ------------------------------------------------------------------------

    To unsubscribe from this group, send an email to:

    concatenative-unsubscribe@egroups.com

## sa@dfa.com — 2000-06-29 17:36:53

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >> From: sa@... [mailto:sa@...]

    >> >     is the first of a list a member of that list?  if so,

    >> >     then [+] first is a member of [+], so `+ is identical

    >> >     to +, and [+] is identical to [`+].

    >> Yes, I would expect [x] to be identical to [`x], because

    >> quotation implies

    >> escaping as well as aggregation.

    >> However, `x is clearly not in general equivalent to x,

    >> because x will do

    >> something, and `x will merely push `x on the stack.

    >exactly.  which is why i dislike this approach.  v.e. avoids

    >introducing a new (and mysterious) datatype, avoids violating

    >substitutivity of identicals, and keeps the symmetry of stack

    >and list.

     v.e. doesn't avoid the new datatype; it merely hides it, and makes it

    impossible to manipulate.  I have no idea why you should call the

    'function'

    datatype "mysterious".  I can't even guess what the rest of your

    accusations

    mean -- adding a function datatype fully preserves substitution, and also

    allows list manipulation, which would be practically impossible with v.e.

    except in precisely controlled situations.

         relax.  this is just programming.  ;-)

         we have no examples of any interesting joy program

         producing an intermediate result of the stack which

         contains a bare function.  none of manfred's examples

         do, as far as i can tell.  so this is really just

         an argument about what to do in certain (possibly)

         pathological circumstances, such as [+] first.

         now, there are two further questions:  what use is

         this new style of quotation (` or \)?; what use is

         v.e?

     >moreover, (i think) there is no computation which

    >leaves the stack in a state which it couldn't have gotten into

    >by simply entering the items which it contains.

     True; that doesn't mean that this is a good idea.

         i was replying to the louis's original complaint

         that [+]first produced a stack that couldn't be

         constructed directly.

     >> Another way to seperate [x] and [`x] is to make aggregation not imply

    >> quotation -- thus, [x] would actually be a list containing

    >> the results of x, and [`x] would be a list containing x itself.

    >as per louis's suggestion, this is what {} does in conk -

    >grouped evaluation.

    >but i think you're moving away from the purity and simplicity of joy.

     I don't like {} at _all_.  I think it's a terrible idea.  It makes FAR more

    sense to use the ` or \ operator to quote both functions and aggregations.

         huh?  {} was introduced to allow grouped evaluation-at-depth,

         which is more convenient than constructing lists explicitly

         by means of cons and unitlist.  {}'s really are pure syntax,

         and can be eliminated at parse time (i don't do this).

    I also disagree that either one would be moving away from purity; on the

    contrary, it would make all of the datatype which Joy _currently_ supports

    completely defined and easily available.  How can we be moving away by

    supporting simply what we already support fully?

         well, that's a good point.

    -Billy

    ------------------------------------------------------------------------

    Lonely? Get Firetalk!

    Free, unlimited calls anywhere in the world.

    Free voice chat on hundreds of topics.

    http://click.egroups.com/1/5477/7/_/_/_/962296863/

    ------------------------------------------------------------------------

    To unsubscribe from this group, send an email to:

    concatenative-unsubscribe@egroups.com

## William Tanksley — 2000-06-29 21:29:01

    --- In concatenative@egroups.com, sa@d... wrote:

     > From: stevan apter [mailto:apter@p...]

    > >From: <wtanksley@b...>

    > >> From: sa@d... [mailto:sa@d...]

    > >exactly.  which is why i dislike this approach.  v.e. avoids

    > >introducing a new (and mysterious) datatype, avoids violating

    > >substitutivity of identicals, and keeps the symmetry of stack

    > >and list.

    > v.e. doesn't avoid the new datatype; it merely hides it, and

    > makes it

    > impossible to manipulate.  I have no idea why you should call the

    > 'function'

    > datatype "mysterious".  I can't even guess what the rest of your

    > accusations

    > mean -- adding a function datatype fully preserves substitution,

    > and also

    > allows list manipulation, which would be practically impossible

    > with v.e. except in precisely controlled situations.

    >      relax.  this is just programming.  ;-)

     Grin.  Thanks for taking that lightly -- I forget that this isn't

    speaking.  I should have put quotes around "accusations".

     >      we have no examples of any interesting joy program

    >      producing an intermediate result of the stack which

    >      contains a bare function.  none of manfred's examples

    >      do, as far as i can tell.  so this is really just

    >      an argument about what to do in certain (possibly)

    >      pathological circumstances, such as [+] first.

     I'm not sure that the absence of interesting Joy problems is a useful

    measure -- the fact is that there are no interesting Joy programs for

    any purpose :-).  Joy's purpose is didactic (so to speak).

     >      now, there are two further questions:  what use is

    >      this new style of quotation (` or \)?; what use is

    >      v.e?

     Good question.  The place I'd use the new \ is wherever I wanted to

    get a function in the same way I'd want to get a quotation.  I was

    working a proof earlier (in this NG) and ran into a problem where I

    had to do something like [+] first, when I could have done \+.

    This is especially vital when you're attempting to build a quotation;

    suppose, for example, you were trying to write "concat".  Concat

    _requires_ the ability to dequote things without executing them.

     > >> Another way to seperate [x] and [`x] is to make aggregation not

    > >> imply

    > >> quotation -- thus, [x] would actually be a list containing

    > >> the results of x, and [`x] would be a list containing x itself.

    > >as per louis's suggestion, this is what {} does in conk -

    > >grouped evaluation.

    > >but i think you're moving away from the purity and simplicity of

    > >joy.

    > I don't like {} at _all_.  I think it's a terrible idea.  It makes

    > FAR more

    > sense to use the ` or \ operator to quote both functions and

    > aggregations.

    >      huh?  {} was introduced to allow grouped evaluation-at-depth,

    >      which is more convenient than constructing lists explicitly

    >      by means of cons and unitlist.  {}'s really are pure syntax,

    >      and can be eliminated at parse time (i don't do this).

     I like what {} does, but I don't like having both {} and [] in the

    same language.  I prefer having only one, and having \ be able to

    escape an entire aggregation.

    That's completely my own preference, though; I shouldn't have said

    that {} was a terrible idea.

    -Billy

## Louis Madon — 2000-06-30 01:12:25

    sa@... wrote:

     >

    >      now, there are two further questions:

    >what use is this new style of quotation (` or \)?;

     As Billy mentioned, you can do single quotation without having to

    involve aggregation. Plus it fixes the stack representation issue.

    Overall, the language is providing better support for the function

    datatype.

     > what use is v.e?

     I thought the possibility of eliminating function types was very

    interesting - if it were possible without compromising the language in

    other ways (I'm quite pessimistic about that now).

    While we're on this topic, I thought I'd point out that Joys' function

    type is actually more complex than what is normally considered a

    function type: its a mixture of symbol, function and program and

    supports intensional equality.  For example, assume we have defined

    'square' somewhere:

    square == dup *

    then:

    [square] first name           => "square"    // the symbol

    [square] first body           => [dup *]     // the program

    4 square                      => 16          // the function applied to

    4

    [square] first dup =          => true        // equality

    predefined functions don't support body:

    [+] first body                => error: requires user defined function

    undefined functions support name and equality only:

    [undefined_foo] first name    => "undefined foo"

    [undefined_foo] first dup =   => true

    the equality operation is intensional rather than extensional, for

    example if we also have defined the following function:

    selfmul == dup *

    then:

    [square] first [selfmul] first =    => false

    So even though square and selfmul perform the same function (and even

    have the same implementation) they are still considered distinct under

    the equality operation.

    There may be other properties of these data types that I've missed, but

    clearly this is an area of the language that needs to be properly

    defined (especially considering that in most languages, a "function

    type" really only means a function as a first-class value and the only

    thing you can do with it is apply it.)

    --

    Louis.

## stevan apter — 2000-06-30 01:51:46

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

    From: Louis Madon <madonl@...>

    >

    > While we're on this topic, I thought I'd point out that Joys' function

    > type is actually more complex than what is normally considered a

    > function type: its a mixture of symbol, function and program and

    > supports intensional equality.  For example, assume we have defined

    > 'square' somewhere:

    >

    > square == dup *

    >

    > then:

    >

    > [square] first name           => "square"    // the symbol

    > [square] first body           => [dup *]     // the program

    > 4 square                      => 16          // the function applied to

    > 4

    > [square] first dup =          => true        // equality

    >

    >

    > predefined functions don't support body:

    >

    > [+] first body                => error: requires user defined function

    >

    >

    > undefined functions support name and equality only:

    >

    > [undefined_foo] first name    => "undefined foo"

    > [undefined_foo] first dup =   => true

    >

    >

    > the equality operation is intensional rather than extensional, for

    > example if we also have defined the following function:

    >

    > selfmul == dup *

    >

    > then:

    >

    > [square] first [selfmul] first =    => false

    >

    >

    > So even though square and selfmul perform the same function (and even

    > have the same implementation) they are still considered distinct under

    > the equality operation.

    these properties fall out of the conk implementation (with v.e. turned

    off).  this is because a primitive is represented as a symbol which points

    to a k lambda, and a joy list as a k list.  so `square = *,`square (first

    of the list containing `square).

    to implement function quotation, i have to push everything down one level.

    a primitive is represented as a lambda, and a function quotation as

    the symbol which points to that primitive.  this requires changes in

    eval, input parsing, and output representation.  not hard, but more

    code than what is required now.  i may try implementing over the weekend.

## stevan apter — 2000-06-30 11:17:11

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

    From: stevan apter <apter@...>

    To: <concatenative@egroups.com>

    Sent: Thursday, June 29, 2000 9:51 PM

    Subject: Re: [stack] conk manual

    > to implement function quotation, i have to push everything down one level.

    > a primitive is represented as a lambda, and a function quotation as

    > the symbol which points to that primitive.  this requires changes in

    > eval, input parsing, and output representation.  not hard, but more

    > code than what is required now.  i may try implementing over the weekend.

    >

    >

    i was wrong, and you and billy were right:  ` is (almost) mere syntax,

    and is surprisingly easy to add to the language, requiring no changes

    to evaluation or internal representation.

    on input, if the scanner detects `xyz, it represents it as [xyz] first.

    on output, if the scanner detects a symbol, then if it is inside a list,

    it prints it (as before), else it prefixes it with `.

## stevan apter — 2000-06-30 13:20:17

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Thursday, June 29, 2000 9:12 PM

    Subject: Re: [stack] conk manual

    > While we're on this topic, I thought I'd point out that Joys' function

    > type is actually more complex than what is normally considered a

    > function type: its a mixture of symbol, function and program and

    > supports intensional equality.

    equality is extensional under v.e.  (quotation is still opaque).

## wtanksley@bigfoot.com — 2000-06-30 17:06:25

    From: stevan apter [mailto:apter@...]

     >i was wrong, and you and billy were right:  ` is (almost) mere syntax,

    >and is surprisingly easy to add to the language, requiring no changes

    >to evaluation or internal representation.

     I'm suspicious.

     >on input, if the scanner detects `xyz, it represents it as [xyz] first.

    >on output, if the scanner detects a symbol, then if it is

    >inside a list, it prints it (as before), else it prefixes it

    >with `.

     This won't work; [item] is different from `item, since `item isn't a list.

    In addition, {`item} is a quotation which when executed (using 'i') will

    execute item.  Under your implementation, executing {`item} would actually

    place `item onto the stack.

    (I'm using your definition of {}, even though I don't like to have that many

    braces.)

    Hmm, that may be a good question.  How do you make a quotation place the

    address of a function on the stack?

    If I write [item], I have a quotation which when executed will execute item.

    Theoretically, when I run {`item} I should also execute item.  But what

    about [`item]?  I would expect that to return `item when executed.

    This is implementationally interesting.  :-)

    -Billy

## stevan apter — 2000-06-30 18:28:49

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

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 30, 2000 1:06 PM

    Subject: RE: [stack] conk manual

    > From: stevan apter [mailto:apter@...]

    >

    > >i was wrong, and you and billy were right:  ` is (almost) mere syntax,

    > >and is surprisingly easy to add to the language, requiring no changes

    > >to evaluation or internal representation.

    >

    > I'm suspicious.

    well then, i'm sure the fbi has a dossier.

    >

    > >on input, if the scanner detects `xyz, it represents it as [xyz] first.

    >

    > >on output, if the scanner detects a symbol, then if it is

    > >inside a list, it prints it (as before), else it prefixes it

    > >with `.

    >

    > This won't work; [item] is different from `item, since `item isn't a list.

    > In addition, {`item} is a quotation which when executed (using 'i') will

    > execute item.  Under your implementation, executing {`item} would actually

    > place `item onto the stack.

    i had to make both input and output processing aware of the "level" of

    the expression.  thus

        input        on the stack

        `foo        `foo

        [`foo]      [foo]

        {`foo}      `foo

        {[`foo]}    [foo]

    etc.

    >

    > (I'm using your definition of {}, even though I don't like to have that many

    > braces.)

    i like {} - it's very convenient.

    >

    > Hmm, that may be a good question.  How do you make a quotation place the

    > address of a function on the stack?

    what's "the address of a function"?  not another new type!!  ;-)

    >

    > If I write [item], I have a quotation which when executed will execute item.

    > Theoretically, when I run {`item} I should also execute item.  But what

    > about [`item]?  I would expect that to return `item when executed.

    [`item] == [item]

    >

    > This is implementationally interesting.  :-)

    my input and output routines are recursive.  to support `item, i pass

    along a further argument, which is either 0 if we are parsing or formatting

    at the top level, or 1, if we are recursing.  primitives are symbols,

    e.g. `plus.  if level = 0, and `xyz is encountered, then return the parse

    of [xyz]first; if level = 1, and `xyz is encountered, then return xyz.  on

    evaluation, the first expression will leave xyz on the stack, where the

    output routine (see below) will print it as `xyz; evaluating the second

    expression - a symbol -- will execute it.

    on output, if level = 0, and `xyz is encountered, output `xyz;

    if level = 1, and `xyz is encountered, output xyz (no initial quote).

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Special Offer-Earn 300 Points from MyPoints.com for trying @Backup

    > Get automatic protection and access to your important computer files.

    > Install today:

    > http://click.egroups.com/1/5667/7/_/_/_/962384762/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-06-30 19:53:23

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

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 30, 2000 1:06 PM

    Subject: RE: [stack] conk manual

    >

    > If I write [item], I have a quotation which when executed will execute item.

    > Theoretically, when I run {`item} I should also execute item.  But what

    > about [`item]?  I would expect that to return `item when executed.

    >

    i only caught this while re-reading your message.  {x} is evaluated *at parse

    time* on the empty stack.  so e.g.

        1 2 {2 1+} 4 5 6

    is pre-processed into

        1 2 3 4 5 6

    during parsing, when i encounter {, i find its mate, parse & evaluate what's

    betweeen them, append the result to what's so far parsed, and continue

    parsing.

## wtanksley@bigfoot.com — 2000-06-30 20:17:09

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >> From: stevan apter [mailto:apter@...]

    >> I'm suspicious.

    >well then, i'm sure the fbi has a dossier.

     We've been keeping an eye on you for quite some time, Mr. Baggins.

    (Interesting fact: the actor who will play Elrond in the upcoming "Lord of

    The Rings" movie is the same actor who played Agent Smith in "Matrix".

    Well, I found it an interesting thought -- about as interesting as

    discovering that Samuel Jackson was going to be chief of the jedi in Episode

    I way back when. :-)

     >> >on input, if the scanner detects `xyz, it represents it as

    >> >[xyz] first.

    >> >on output, if the scanner detects a symbol, then if it is

    >> >inside a list, it prints it (as before), else it prefixes it

    >> >with `.

    >> This won't work; [item] is different from `item, since `item

    >> isn't a list.

    >> In addition, {`item} is a quotation which when executed

    >> (using 'i') will

    >> execute item.  Under your implementation, executing {`item}

    >> would actually

    >> place `item onto the stack.

    >i had to make both input and output processing aware of the "level" of

    >the expression.  thus

    >    input        on the stack

    >    `foo        `foo

    >    [`foo]      [foo]

    >    {`foo}      `foo

    >    {[`foo]}    [foo]

    >etc.

    >> (I'm using your definition of {}, even though I don't like

    >> to have that many braces.)

    >i like {} - it's very convenient.

     Wait.  You discussed {} earlier, but there was a miscommunication -- I had

    thought that you said that {} did grouping without quotation; in other

    words, {3 4 +} == [7].  That seemed to me to be a waste of time, since under

    my scheme you'd use [3 4 +] == [7] and `[3 4 +] == [3 4 `+].

    From now on I'm going to switch to my terminology: [3 4 +] == [7], and `[3 4

    +] == [3 4 `+] (sort of, there are problems.

    I won't use your {}, but I agree with you that they're very useful.  I

    wouldn't be suprised if I wound up using them in my implementation; Forth

    has a similar concept in IMMEDIATE words, but Chuck Moore has since gotten

    rid of IMMEDIATE in his own work, and how he uses something faintly like

    what you're using.

     >> Hmm, that may be a good question.  How do you make a

    >> quotation place the

    >> address of a function on the stack?

    >what's "the address of a function"?  not another new type!!  ;-)

     No, the same type we've been discussing all along.

    But what happens if I type

      `[3 4 + `foo] dup . cr i . .

    I would expect to see (cr prints a carrige return, BTW):

      `[3 4 + `foo]

    `foo 7

    Do you see what's happening?  The problem is that all along I've been

    thinking of quotations as the same thing as lists, but here we see that they

    aren't.  If `[3 4] == [3 4], then when I print `[3 4 + `foo] I would expect

    to see [3 4 `+ ``foo] (notice the odd double-backtick on the foo).  I don't

    like that double-backtick; it looks very strange indeed.

     >> If I write [item], I have a quotation which when executed

    >> will execute item.

    >> Theoretically, when I run {`item} I should also execute

    >> item.  But what

    >> about [`item]?  I would expect that to return `item when executed.

    >[`item] == [item]

     This makes sense in both of our notations.  However, in my notation, what

    does

       `[`item]

    mean?  It seems to me that this proves that the quotation, "`[]", is a

    primitive concept.  That does NOT bode well for my ideas.  Ick.

    -Billy

## stevan apter — 2000-06-30 21:15:32

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

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 30, 2000 4:17 PM

    Subject: RE: [stack] conk manual

    > From: stevan apter [mailto:apter@...]

    > >From: <wtanksley@...>

    > >> From: stevan apter [mailto:apter@...]

    >

    > >> I'm suspicious.

    >

    > >well then, i'm sure the fbi has a dossier.

    >

    > We've been keeping an eye on you for quite some time, Mr. Baggins.

    >

    > (Interesting fact: the actor who will play Elrond in the upcoming "Lord of

    > The Rings" movie is the same actor who played Agent Smith in "Matrix".

    > Well, I found it an interesting thought -- about as interesting as

    > discovering that Samuel Jackson was going to be chief of the jedi in Episode

    > I way back when. :-)

    i've seen the trailer for LotR - spectacular.

    >

    > >> >on input, if the scanner detects `xyz, it represents it as

    > >> >[xyz] first.

    >

    > >> >on output, if the scanner detects a symbol, then if it is

    > >> >inside a list, it prints it (as before), else it prefixes it

    > >> >with `.

    >

    > >> This won't work; [item] is different from `item, since `item

    > >> isn't a list.

    > >> In addition, {`item} is a quotation which when executed

    > >> (using 'i') will

    > >> execute item.  Under your implementation, executing {`item}

    > >> would actually

    > >> place `item onto the stack.

    >

    > >i had to make both input and output processing aware of the "level" of

    > >the expression.  thus

    >

    > >    input        on the stack

    > >    `foo        `foo

    > >    [`foo]      [foo]

    > >    {`foo}      `foo

    > >    {[`foo]}    [foo]

    >

    > >etc.

    >

    > >> (I'm using your definition of {}, even though I don't like

    > >> to have that many braces.)

    >

    > >i like {} - it's very convenient.

    >

    > Wait.  You discussed {} earlier, but there was a miscommunication -- I had

    > thought that you said that {} did grouping without quotation; in other

    > words, {3 4 +} == [7].  That seemed to me to be a waste of time, since under

    > my scheme you'd use [3 4 +] == [7] and `[3 4 +] == [3 4 `+].

    i prefer to describe it as structured evaluation.  recall louis's way

    to construct dictionaries and their attributes:

        {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d

    if the result of {x} was [eval x] instead of eval x, this code would fail.

    >

    > >From now on I'm going to switch to my terminology: [3 4 +] == [7], and `[3 4

    > +] == [3 4 `+] (sort of, there are problems.

    >

    > I won't use your {}, but I agree with you that they're very useful.  I

    > wouldn't be suprised if I wound up using them in my implementation; Forth

    > has a similar concept in IMMEDIATE words, but Chuck Moore has since gotten

    > rid of IMMEDIATE in his own work, and how he uses something faintly like

    > what you're using.

    aha

    >

    > >> Hmm, that may be a good question.  How do you make a

    > >> quotation place the

    > >> address of a function on the stack?

    >

    > >what's "the address of a function"?  not another new type!!  ;-)

    >

    > No, the same type we've been discussing all along.

    >

    > But what happens if I type

    >

    >   `[3 4 + `foo] dup . cr i . .

    >

    > I would expect to see (cr prints a carrige return, BTW):

    >

    >   `[3 4 + `foo]

    > `foo 7

    >

    > Do you see what's happening?  The problem is that all along I've been

    > thinking of quotations as the same thing as lists, but here we see that they

    > aren't.  If `[3 4] == [3 4], then when I print `[3 4 + `foo] I would expect

    > to see [3 4 `+ ``foo] (notice the odd double-backtick on the foo).  I don't

    > like that double-backtick; it looks very strange indeed.

    indeed.  again, i thought we had agreed that (i) in joy, you can compute

    a result for which there was no constructor (namely, bare functions), and

    that (ii) since the language already contained these types, all we need

    is a piece of syntax which allows us to enter them directly (the constructor).

    although i am still a bit dim about the use of `foo, i agree that having

    it is good for completeness.  regarding `[foo] and [`goo], well, there

    i am utterly at sea regarding the intended meaning.

    >

    > >> If I write [item], I have a quotation which when executed

    > >> will execute item.

    > >> Theoretically, when I run {`item} I should also execute

    > >> item.  But what

    > >> about [`item]?  I would expect that to return `item when executed.

    >

    > >[`item] == [item]

    >

    > This makes sense in both of our notations.  However, in my notation, what

    > does

    >

    >    `[`item]

    >

    > mean?  It seems to me that this proves that the quotation, "`[]", is a

    > primitive concept.  That does NOT bode well for my ideas.  Ick.

    i know the feeling.

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Get a NextCard Visa, in 30 seconds!

    > 1. Fill in the brief application

    > 2. Receive approval decision within 30 seconds

    > 3. Get rates as low as 2.9% Intro or 9.9% Fixed APR

    > http://click.egroups.com/1/5197/7/_/_/_/962396206/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## wtanksley@bigfoot.com — 2000-06-30 21:20:24

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >    {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d

    >if the result of {x} was [eval x] instead of eval x, this code

    >would fail.

     Yes, but I can't read that code either way.  I'm afraid it means little or

    nothing to me.

     >> I won't use your {}, but I agree with you that they're very

    >> useful.  I

    >> wouldn't be suprised if I wound up using them in my

    >> implementation; Forth

    >> has a similar concept in IMMEDIATE words, but Chuck Moore

    >> has since gotten

    >> rid of IMMEDIATE in his own work, and how he uses something

    >> faintly like

    >> what you're using.

    >aha

     His current work is called "Color Forth".  In Color Forth, instead of having

    immediate words, you use mode changing tokens to tell the compiler how to

    treat the next group of words.  His editor displays the words in color, so

    that a definition shows up as a red word, and a word which is being executed

    shows up blue, and a word being compiled, green.

     >indeed.  again, i thought we had agreed that (i) in joy, you

    >can compute

    >a result for which there was no constructor (namely, bare

    >functions), and

    >that (ii) since the language already contained these types, all we need

    >is a piece of syntax which allows us to enter them directly

    >(the constructor).

     Yes.

     >although i am still a bit dim about the use of `foo, i agree

    >that having

    >it is good for completeness.  regarding `[foo] and [`goo], well, there

    >i am utterly at sea regarding the intended meaning.

     I think the solution is to remove `[foo].  We'll keep the meaning of [foo]

    the same as it currently is, and we'll add the ability to immediately

    execute words even in the middle of a quotation.  As I understand, this is

    what your {} does.

    -Billy

## stevan apter — 2000-06-30 21:41:58

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

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 30, 2000 5:20 PM

    Subject: RE: [stack] conk manual

    > >aha

    >

    > His current work is called "Color Forth".  In Color Forth, instead of having

    > immediate words, you use mode changing tokens to tell the compiler how to

    > treat the next group of words.  His editor displays the words in color, so

    > that a definition shows up as a red word, and a word which is being executed

    > shows up blue, and a word being compiled, green.

    the best programmer i know is red-green color-blind.  but it's a

    nice idea.

    >

    > >indeed.  again, i thought we had agreed that (i) in joy, you

    > >can compute

    > >a result for which there was no constructor (namely, bare

    > >functions), and

    > >that (ii) since the language already contained these types, all we need

    > >is a piece of syntax which allows us to enter them directly

    > >(the constructor).

    >

    > Yes.

    >

    > >although i am still a bit dim about the use of `foo, i agree

    > >that having

    > >it is good for completeness.  regarding `[foo] and [`goo], well, there

    > >i am utterly at sea regarding the intended meaning.

    >

    > I think the solution is to remove `[foo].  We'll keep the meaning of [foo]

    > the same as it currently is, and we'll add the ability to immediately

    > execute words even in the middle of a quotation.  As I understand, this is

    > what your {} does.

    {2 +} is a stack underflow error in conk.  what is [2 +] for you?

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > BeMANY, where eGroups members SAVE on long distance.

    > http://click.egroups.com/1/4121/7/_/_/_/962400000/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## wtanksley@bigfoot.com — 2000-06-30 21:41:41

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >> His current work is called "Color Forth".  In Color Forth,

    >> instead of having

    >> immediate words, you use mode changing tokens to tell the

    >> compiler how to

    >> treat the next group of words.  His editor displays the

    >> words in color, so

    >> that a definition shows up as a red word, and a word which

    >> is being executed

    >> shows up blue, and a word being compiled, green.

    >the best programmer i know is red-green color-blind.  but it's a

    >nice idea.

     Then perhaps that programmer should use his own editor instead of Chuck's,

    where his editor didn't colorise the marks in the same way.  It's not really

    a problem.  Another possibility is that Chuck would do some research and

    choose color tones which were deliberately different, so that even a fully

    color-blind programmer could distinguish them.  (I doubt that he did this.)

     >> I think the solution is to remove `[foo].  We'll keep the

    >> meaning of [foo]

    >> the same as it currently is, and we'll add the ability to immediately

    >> execute words even in the middle of a quotation.  As I

    >> understand, this is

    >> what your {} does.

    >{2 +} is a stack underflow error in conk.

     So may I suppose that {2 2 +} is [4]?

    In Color Forth, the closest equivalent to {2 +} would be simply immediate

    execution of 2 +, and the exact result would depend on whether there was

    something on the stack at the time.

     >what is [2 +] for you?

     Same as it is for Joy -- [2 +] uncons == 2 [+].

    -Billy

## stevan apter — 2000-06-30 21:54:13

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

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 30, 2000 5:41 PM

    Subject: RE: [stack] conk manual

    >

    > >{2 +} is a stack underflow error in conk.

    >

    > So may I suppose that {2 2 +} is [4]?

    no - it's just 4

    >

    > In Color Forth, the closest equivalent to {2 +} would be simply immediate

    > execution of 2 +, and the exact result would depend on whether there was

    > something on the stack at the time.

    >

    > >what is [2 +] for you?

    >

    > Same as it is for Joy -- [2 +] uncons == 2 [+].

    ok, i thought you were proposing that [] would not have quotational

    properties.  i'm confused - there are too many alternative proposals

    flying around.  time for a movie.

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Explore the popular High-End Room -

    > Go To Where The Smart People Shop-uBid.com

    > http://click.egroups.com/1/6141/7/_/_/_/962401284/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## wtanksley@bigfoot.com — 2000-06-30 22:07:18

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >> >{2 +} is a stack underflow error in conk.

    >> So may I suppose that {2 2 +} is [4]?

    >no - it's just 4

     Good.  That's what I would want it to be.

     >> >what is [2 +] for you?

    >> Same as it is for Joy -- [2 +] uncons == 2 [+].

    >ok, i thought you were proposing that [] would not have quotational

    >properties.  i'm confused - there are too many alternative proposals

    >flying around.  time for a movie.

     I did propose that, and quite a while ago decided not to bother.

    -Billy

## Louis Madon — 2000-06-30 23:58:15

    stevan apter wrote:

     > From: Louis Madon <madonl@...>

    > > While we're on this topic, I thought I'd point out that Joys'

    > function

    > > type is actually more complex than what is normally considered a

    > > function type: its a mixture of symbol, function and program and

    > > supports intensional equality.

    >

    > equality is extensional under v.e.  (quotation is still opaque).

     Is that extensional equality with respect to function or implementation?

    For example, if I have these two functions:

    foo == dup +

    bar == 2 *

    is foo and bar considered equal? (In terms of _function_ they are equal

    since they define the same map, yet they have different

    implementations).

    I'd be suprised if you can do that.

    --

    Louis.

## Louis Madon — 2000-07-01 00:13:13

    stevan apter wrote:

     > > Wait.  You discussed {} earlier, but there was a miscommunication --

    > I had

    > > thought that you said that {} did grouping without quotation; in

    > other

    > > words, {3 4 +} == [7].  That seemed to me to be a waste of time,

    > since under

    > > my scheme you'd use [3 4 +] == [7] and `[3 4 +] == [3 4 `+].

    >

    > i prefer to describe it as structured evaluation.  recall louis's way

    > to construct dictionaries and their attributes:

    >

    >     {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d

    >

    > if the result of {x} was [eval x] instead of eval x, this code would

    > fail.

     Why? My impression was that {} is aggregation without quotation - that

    does mean that the result of {x} is [eval x]. This is the form required

    by d to build a dictionary right?  (I'm not saying that your notion of

    structured evaluation is neccesarily bad - it may even be a better way

    to go - but its not what I was thinking of).

    --

    Louis.

## stevan apter — 2000-07-01 11:48:16

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 30, 2000 7:58 PM

    Subject: Re: [stack] conk manual

    > stevan apter wrote:

    > > From: Louis Madon <madonl@...>

    > > > While we're on this topic, I thought I'd point out that Joys'

    > > function

    > > > type is actually more complex than what is normally considered a

    > > > function type: its a mixture of symbol, function and program and

    > > > supports intensional equality.

    > >

    > > equality is extensional under v.e.  (quotation is still opaque).

    >

    > Is that extensional equality with respect to function or implementation?

    implementation, hence not equality.

    > For example, if I have these two functions:

    >

    > foo == dup +

    > bar == 2 *

    >

    > is foo and bar considered equal? (In terms of _function_ they are equal

    > since they define the same map, yet they have different

    > implementations).

    >

    > I'd be suprised if you can do that.

    me too. ;)

    >

    >

    > --

    > Louis.

    >

    > ------------------------------------------------------------------------

    > You have to check this out and pass it along!

    > http://click.egroups.com/1/6016/7/_/_/_/962409175/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-07-01 12:41:25

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

    From: Louis Madon <madonl@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 30, 2000 8:13 PM

    Subject: Re: [stack] conk manual

    > stevan apter wrote:

    >

    > > > Wait.  You discussed {} earlier, but there was a miscommunication --

    > > I had

    > > > thought that you said that {} did grouping without quotation; in

    > > other

    > > > words, {3 4 +} == [7].  That seemed to me to be a waste of time,

    > > since under

    > > > my scheme you'd use [3 4 +] == [7] and `[3 4 +] == [3 4 `+].

    > >

    > > i prefer to describe it as structured evaluation.  recall louis's way

    > > to construct dictionaries and their attributes:

    > >

    > >     {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d

    > >

    > > if the result of {x} was [eval x] instead of eval x, this code would

    > > fail.

    >

    > Why? My impression was that {} is aggregation without quotation - that

    > does mean that the result of {x} is [eval x]. This is the form required

    > by d to build a dictionary right?  (I'm not saying that your notion of

    > structured evaluation is neccesarily bad - it may even be a better way

    > to go - but its not what I was thinking of).

    i don't know quite what i was thinking, but i do know that it was wrong.

    as was my implementation.

    {} DOES aggregate.  in fact, if it didn't, then i couldn't build dictionaries

    or other complex structures this way.

        {10}

     [10]

        {10 20 +}

     [30]

        {a 10 {[bg 99][fg 100]}d}[[b 20]]d

    [a 10 [[bg 99 nil] [fg 100 nil]] d] [[b 20 nil]] `d

    a dictionary is a *list* of pairs (or triples).

    given this definition of {}, it is easy to get what i was calling

    structured evaluation:

        {2 3 +}

      [5]

        disperse

      5

    >

    >

    > --

    > Louis.

    >

    > ------------------------------------------------------------------------

    > Whassuuup?!

    > http://click.egroups.com/1/6014/7/_/_/_/962410075/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-07-01 13:00:42

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

    From: stevan apter <apter@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, July 01, 2000 8:41 AM

    Subject: Re: [stack] conk manual

    >     {a 10 {[bg 99][fg 100]}d}[[b 20]]d

    > [a 10 [[bg 99 nil] [fg 100 nil]] d] [[b 20 nil]] `d

      {{a 10 [[bg 99][fg 100]]d}[b 20]}d

    [[a 10 [[bg 99 nil] [fg 100 nil]] d] [b 20 nil]] `d

    i wish i could say that i am not normally this careless, and blame

    it on caffeine-deprivation, but honesty compels me ...

    anyway, the expression is a list of two items - a triple, consisting

    of a name a, a value 10, and a dictionary [[bg 99][fg 100]d, and a

    pair [b 20].  the outer braces make it a list, which is acceptable

    to the d operator, and the inner braces allow the inner d to apply

    immediately.

    now, for that fourth cup of cofee ..