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.