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