Re: Self/Scheme

[lpd@aladdin.com (L. Peter Deutsch)]

> for example, self has some of scheme in it but could use a lot more still:
> 
>   - unified blocks and methods (procedures aka closures)
>   - more convenient representation of code as data
>   - a macro facility

I think macros are a really, truly, bad idea.  As the Scheme literature
shows, it's extremely difficult to implement them in a way that doesn't
break the language's scoping rules; and they also absolutely require
climbing one level up the reflective hierarchy of static representations,
i.e., they require a "data-like" representation of the syntactic elements of
the language.

In my opinion, the way to go is Beta's generalization of procedural
abstraction to cover the entire range of syntactic constructs, not just
expressions.  This approach is more limited than general macros, but it can
get rid of nearly all of the scoping rule problems and doesn't require a
data-like representation of unparsed but tokenized source code.

>   - closures that may be used out of their lexical context
>   - continuations
>   
>   - transformation of tail recursion into iteration
>   - lazy allocation (scheme does not have this by default, but should)
> 
> the first three issues are actually visible at the language level.  they
> simplify library design and will probably make the system lighter or more
> effective.  the last two are implementation issues, invisible at the
> language level.  they complicate (do they?) interpreter/compiler
> construction but will make the system more efficient.
> 
> out-of-context closures and continuations are implementation issues that
> are visible at the programming level.  using heap allocation is a simple
> way to implement closures but that's slow.  having lazy alloc would help a lot
> there (first, alloc on the stack, evacuate to the heap when necessary), but
> isn't trivial to implement fast.  still, because it pays off in so many
> ways (including providing elegant and fast ways to implement the other
> three implementation issues), it seems the way to go.

The Self group considered non-LIFO closures at some length and decided
against them.  The Smalltalk systems I helped build went the other way, but
it is extremely awkward to implement in a way that doesn't slow down the 99%
stack-allocatable case at all, and we didn't try to do it.  (In particular,
I don't know a way of doing this without checks on every store and return
that also doesn't involve code modification or duplication.)

						L. Peter Deutsch