Home > Archive > Compilers > July 2006 > Re: What is the future of Compiler technology?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: What is the future of Compiler technology?
|
|
| Tommy Thorn 2006-07-05, 7:01 pm |
| Friedrich Dominicus wrote:
> And it shows how Microsoft brainwashing works. Have you checked
> Smalltalk it has full closures from it's beginning,
No. In standard Smalltalk, blocks don't capture free variables. I'm
not sure what happens with those when the block survives the creating
context. Some commercial variants of Smalltalk have extended the block
notion to be true closures.
Scheme, SML, O'Caml, Haskell, etc all had true closures from day one.
I agree, attempts at shoehorning closures into languages originally
designed without them have never been very successful.
Tommy
| |
| Torben Ęgidius Mogensen 2006-07-06, 8:00 am |
| "Tommy Thorn" <tommy.thorn@gmail.com> writes:
> Friedrich Dominicus wrote:
>
> No. In standard Smalltalk, blocks don't capture free variables.
>
> Scheme, SML, O'Caml, Haskell, etc all had true closures from day one.
It is older than that, but the languages above are good examples of
modern languages with full closures.
You can argue that lambda calculus had full closures before there were
even programmable computers, but since early treatments of lambda
calculus used substitution semantics rather than environment
semantics, this is somewhat debatable. Landin's SECD machine from
1963 implemented lambda calculus with closures, though.
LISP (ca. 1960) was originally intended to be an implementation of the
lambda calculus, but since it used dynamic binding, it did not have
true closures. Some LISP variants had options for static binding
(and, hence, true closures). I remember using a LISP system on the
Univac 1100 that would build true closures with statically bound
variables if you used "LAMDA" instead of "LAMBDA".
Algol 60 used "thunks" for call-by-name, but since these were upwards
closures only, they were not true closures. The same is true for
Pascal's function/procedure parameters.
> I agree, attempts at shoehorning closures into languages originally
> designed without them have never been very successful.
If the language already supports nested scopes and a garbage-collected
heap, adding closures is normally not a big deal semantically, but it
may require a complete reworking of the implementation, as you will
have to heap-allocate local variables that would normally reside on
the stack. To avoid this, people have used all sorts of weird and
often incorrect tricks when adding closures to languages that didn't
have them. Unfortunately, these misguided implementation attempts
sometimes become canonized as the defining semantics of the language.
Torben
| |
| Eliot Miranda 2006-07-19, 7:02 pm |
| Tommy Thorn wrote:
> Friedrich Dominicus wrote:
>
>
>
> No. In standard Smalltalk, blocks don't capture free variables. I'm
> not sure what happens with those when the block survives the creating
> context. Some commercial variants of Smalltalk have extended the block
> notion to be true closures.
Actually Standard Smalltalk _does_ have full closures. ANSI x3j20
(circa 1998) specifies full closures. Smalltalk-80, from circa 1982,
provided a rather strange scheme that did close over free variables but
did not allow recursive invocation.
In both systems blocks are "full upward funargs" in that they remain
valid, closing over free variables, after their enclosing execution
context has returned.
> Scheme, SML, O'Caml, Haskell, etc all had true closures from day one.
>
> I agree, attempts at shoehorning closures into languages originally
> designed without them have never been very successful.
--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd
|
|
|
|
|