Announcing E 0.8.4: The Birthday Release

Dan Bornstein
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 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.