Re: Announcing E 0.8.4: The Birthday Release Dan Bornstein (danfuzz@milk.com)
Tue, 1 Jun 1999 16:47:40 -0700 (PDT)

[NB: Tyler, I am the Danfuzz that MarkM mentioned, and I take no offense at your observations about hash tables. Different styles for different time/space tradeoffs. YMMV.]

Pleading lack of time, I'll merely "agree to disagree" about most of your points. That being said, I can't help adding at least a few more comments, the first of which is: Please update the E Syntax and E Kernel cheat sheet on the erights.org website.

My firm belief is that you should have exactly one primitive per primitive concept. As a particular example, if you don't want to force all new scopes to come with a closure (i.e. as part of your lambda equivalent), then my take is that you need a separate scope primitive which does nothing but that, and *not* that you should have multiple primitives which all (in addition to whatever else they do) introduce a new scope. In this case, I'd say that your lambda primitive *shouldn't* introduce a new scope.

>>* visitEscapeExpr: This is call-with-current-continuation, right? So,
>>the surface syntax:
>>
>> escape <hatch> { <body> }
>>
>>should be expandable to a simple method call which passes a thunk
>>constructed from the body:
>>
>> callWithCC (def _(<hatch>) { <body> }})
>
>[-] Fails the above criterion.
>Perfect example of where I think it's easier to teach a primitive special
>form than a primitive function combined with an introduced closure.

[#] I have no problem with your analysis, assuming you intend never to expose the underlying callWithCC to the programmer. However, by doing that, you are making certain control flow constructs more difficult to express. Admittedly, I haven't had a *lot* of need to use callWithCC where the function wasn't statically defined in-place, but I personally don't want to deny anyone that possibility.

If you instead intend to allow programmers direct access to callWithCC then you ought to make "escape" expand to a callWithCC usage. (That "one concept, one primitive" thing again.)

>>* visitHideExpr: The surface syntax
>>
>> { <body> }
>>
>>could expand to:
>>
>> (def _() { <body> })()
>
>[-] Likewise.

[+] Agreed, given your stated bias against anonymous closures. This is, in fact, the "scope" primitive I mentioned above.

-dan