Announcing E 0.8.4: The Birthday Release

Thu, 27 May 1999 16:10:57 -0700 (PDT)

[Originally just sent to MarkM, but I should've just sent this to the
list to begin with. -dan]

Wow! Looks like you've done some great stuff lately! A very happy
birthday indeed!

Since you asked for it, here are my off-the-cuff suggestions for reducing
the E parse tree node types. The core of most of these suggestions is that
in each of these cases you can re-cast a special form as a simple procedure
call. If it turns out that you can inline away the call (which will
presumably be most or all of the time), then that's naturally a Good Thing
and should be done.

The prices you pay are: 

* adding a couple required/primitive functions to the base set of
definitions.
* having to recognize something more complicated than merely node-type
during compilation.

I haven't done this particular step with my Scheme compiler, but I've given
it a bit of thought. One thing I'll be doing is noticing at compile time if
a global reference refers to an immutable cell, and, if so, optimizes away
the indirection through the global environment. Then, if it turns out that
an object in functor position (not just the name--i.e. it won't work for a
reference to a mutable cell) is one of the specially recognized primitives
(such as call-with-current-continuation), then that will enable other
possible optimizations (such as flattening away a lambda). I bet similar
tricks will work for E if you decide to go this route.

Apologies if I get the syntax wrong; my life is Java and Scheme these days.
Also, I know that the "object { ... }" syntax isn't primitive; I'm just
using it as a notational convenience.

* 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 (object { to (<hatch>) { <body> }})

* visitHideExpr: The surface syntax

  { <body> }

could expand to:

  (object { to () { <body> } })()

This assumes that the "dispatch" primitive introduces a new scope. If it
doesn't, then this expansion can't work.

* visitLoopExpr: How do you feel about the iteration/recursion
transformation? If you're okay with that, then this surface syntax:

  loop { <body> }

could expand to (approximately):

  (define __loop := object { to () <body>; __loop() })()

* visitMatchBindExpr: I'm not sure exactly how to expand this (since I'm
not totally sure of the semantics and casual inspection of the E website
revealed no example usages for me to go on), but I think you may be able to
introduce a primitive "performMatch" function and expand this:

  <specimen> =~ <patt>

to something like this:

  { 
    define [__result, <specimen-vars>] := 
      performMatch (<specimen-spec>, <patt>)
    __result 
  }

* visitObjectExpr, visitPlumbingExpr: I find the definition of these nodes
to be disturbing in that they combine object definition with variable
binding. You already have a "define" primitive which should cover the
variable binding side of things. Maybe you still need primitives to cover
the object definition part of these (maybe not--again, I apologize for not
being sure enough of the sementics), but at least you could consolidate
the "define" part.

* visitThrowExpr: I suspect "throw" can just be a primitive function.

* visitCatchExpr: With a "tryCatch" primitive function, this:

  try { <attempt> } catch <patt> { <catcher> }

could expand to (approximately):

  tryCatch (object { to { <attempt> } }, 
            object { to(__except) { if (<patt> ? __except) { <catcher> } } })

* visitFinallyExpr: With a "tryFinally" primitive function, this:

  try { <attempt> } finally { <unwinder> }

could expand to (approximately):

  tryFinally (object { to { <attempt> } },
              object { to { <unwinder> } })

* visitPatternSuchThat: I couldn't find a clear definition of this
node. The text on the javadoc page alludes to a pattern, a specimen,
and a test, but the syntax is just:

  <patt> ? <test>

with no specimen to be seen anywhere. My guess is that this could expand in
terms of the same "performMatch" I posited for expanding "=~" but again I'm
not familiar enough with the semantics to be too sure of this analysis.

Sorry I don't have too many cycles to devote to thinking about E, but I
hope this helps.

Take care,

-dan