# Re: [stack] comments - 1

## Louis Madon — 2000-07-06 13:40:36

    Hello Manfred,

    Nice to see you on the list.

    phimvt@... wrote:

     > 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?

     I think that efficiency can be tackled in very many ways; broadly, the

    low-level approach where the programmer has very fine control or

    higher-level approaches where the compiler does significant

    optimisation; I'll not enter that debate here but I'd like to note that

    retaining a "neutral" Joy, uncomplicated by efficiency concerns, seems

    useful for pedagogic purposes.

    Regarding an efficient Joy, I'm very much in the "high level" camp and

    therefore my comments are biased accordingly. I see inlining directives

    as a low level approach and hence dislike them. Specifically, they

    reduce the implementational freedom that would otherwise be available to

    an optimising compiler.

     > 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.

     In some of the recent discussion here, we informally concluded that

    lambdas can be implemented in normal Joy without introducing new

    primitives. There is even an experimental implementation already (the

    code was recently posted by Juho Snellman).  I wonder if a similar thing

    could be done for continuations too?  On the other hand, the usefulness

    of these additions to Joy is unclear, but if the language doesn't need

    to change, then there's probably no harm keeping them around and seeing

    what experience develops.

    --

    Louis.