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