# comments - 1

## phimvt@lurac.latrobe.edu.au — 2000-07-06 04:51:59

    Dear friends of Joy

        I have started reading the early May contributions, and I can

    add some comments now.

    1. Continuations

        I added "conts" and "callcc" rather late during the development of

    Joy, and have just about regretted it ever since. I don't think I under-

    stand the concepts well enough to have included them. If I had time to

    do it all again, I would read Peter Henderson's book (title?) on Lispkit

    again, to understand continuations in Lisp properly. Also, I never found

    any really useful example to use for Joy. A nice little topic for some-

    body to take up?

    2. Implementation

        It was commented that the Joy stack is different from the calling

    stack for procedures/functions. In my implementation the Joy stack is

    a linked list like a) quotations and b) bodies of definitions. I resisted

    the temptation to use a big array implementation because I did not quite

    trust myself about the garbage collection for a stack implemented as an

    array. Also, this made the "stack" and "unstack" operator particularly

    easy to do. I do not know whether more efficient implementations of Joy

    should do the same thing.

    3. Inlining

        There was some good discussion on the cost and benefits of inlining.

    In the prototype I was not concerned with efficiency. But a future Joy

    might well have two kinds of definitions:

        square  ==  dup * ;

        cube  =inline=  dup dup * * ;

    or something like that. Any thoughts?

    4. Lambda abstraction

        Consider a definition of a length function (in a fantasy lamguage):

          len(str : string) : integer

               ...

    This _uses_ the existing names "string" and "integer", and introduces

    new names "len" and "str". The "str" name only persists to the end of

    the "..." body of the definitions. The "len" name persists well beyond

    that (to end of block, or end of program). The way the two names are

    introduced is quite different, and only "str" is (essentially) a lambda

    abstraction. An equivalent definition might have been:

           len : integer  =  lambda str : string (...)

    which so to speak has shifted the defining occurrence of "str" from

    the left to the right.

        Joy has definitions like "len" but does away with parameters like "str".

    In Church's lambda calculus one can have lambda abstractions (for e.g.

    "str") without a definition (of e.g. "len"). The lambda abstract is just

    a nameless function then:

        lambda str : string (...)

    is a value which can be passed around as a parameter, and can eventually

    be _applied_ to a value (which will have to be a string).

        Schoenfinkel and Curry have shown that lambda abstraction can be

    eliminated in favour of 2 or 3 _combinators_ (S and K, and perhaps I)

    of combinatory logic, which is still Turing complete.

        Combinatory logic still uses _application_ everywhere, but without

    an explicit symbol. Joy does away with application and uses composition

    instead. Of course one could (re-)introduce lambda abstraction into Joy,

    and that would have to go along with a (re-)introduced application

    operation. Both are "against the spirit" of Joy, but they might be worth

    exploring.

        5. Forth

    I know very little about Forth, and I would be interested to see what

    kinds of facilites Joy ought to borrow from Forth. The languages are

    very different in their execution model, but I suspect Joy might learn

    a bit about definitions and compilations in Forth (which I gather are

    more sophisticated there).

        This will have to do for today

           Best wishes, and congratulations again for the excellent discussions

                Manfred