[e-lang] Announcing Release Candidate 0.8.34p: IOU, trinary-define, JSON, & termE`...`

[Mark Miller]

At <http://www.erights.org/download/0-8-34/index.html>
there is now available the release candidate for the next E release. (Though, 
for now, the latest official E release remains 0.8.33o.)


First the bad news:

* The changes represented by this release have yet to be documented on the 
highlights page (at <http://www.erights.org/download/0-8-34/highlights.html>). 
That page currently just consists of notes to myself of what changes I need to 
document before this candidate could become official.

* As of this release candidate, DonutLab is broken. A better spin is that it 
is in transition, since some parts are much improved. Repairing DonutLab is 
not a prerequisite for making this candidate official.


Now the highlights of the good new, all of which need fuller explanations.


                     IOU with GUI


An improved implementation of Tyler's IOU protocol 
<http://www.waterken.com/dev/IOU/>, together with a crude but fun user 
interface for making new "currencies" and transacting in them.


              Draft VatTP replacement included, but not yet used


The latest draft code from Tyler for a VatTP replacement (with Redirectory!) 
is included in the source tree, but not yet used.


                     trinary-define


Kevin's suggested SomewhatLikeDefineExpr is now implemented along the lines 
explained at <http://www.eros-os.org/pipermail/e-lang/2005-May/010606.html>. I 
did this by adding an optional new field to the DefineExpr: optEjectorExpr. 
This change is experimental -- not yet accepted into the language spec -- and 
so the surface syntax for this is turned off by default. You can enable it by 
saying

     ? pragma.enable("trinary-define")

When the new field is null (the default), the DefineExpr behaves exactly like 
it does now, and everything is fully upwards compatible (except for 
programmers writing ETreeVisitors, since visitDefineExpr now has an extra 
argument). When the above pragma-switch is on, the syntax for explicitly 
providing an ejector is ugly, but no less ugly than anything previously suggested:

     def <pattern> := ( <specimenExpr>, <optEjectorExpr> )

If optEjector is null or the pattern match succeeds
     then this acts like a normal "def <pattern> := <specimenExpr>"
else the match failure is reported to the optEjector:

     ? escape foo { def `` := ("x", foo)}
     # value: problem: Excess unmatched: x

I expect trinary-define to be interesting only to those writing programs which 
write programs, but I could be wrong.


                    Quasi-JSON back from the dead


I've implemented the most of the changes to TermL (our Term-tree language) 
agreed upon in the thread rooted at 
<http://www.eros-os.org/pipermail/e-lang/2005-January/010355.html>. (See 
especially the section at the end of this message.) With these changes, TermL 
is now a strict superset of JSON, and so any existing JSON data is accepted 
directly by the TermParser. All the examples on the JSON example page at 
<http://www.crockford.com/JSON/example.html> parsed successfully, and in the 
process detected that Doug's third example is missing a close curly.

I include Doug's long example in a file in this release. To parse it into a 
Term-tree, do:

   ? def je := <resource:org/quasiliteral/term/servlet-example.json>.getTwine()
   ? def tp := <import:org.quasiliteral.term.TermParser>
   ? def servletDesc := tp(je)

You can then use the full power of quasi-literal expressions and patterns (see 
<http://www.erights.org/elang/quasi/terms/like-ellipses.html>)to manipulate 
this data. For example, you can extract the embedded servlet names from this 
data as follows:

   ? def term`{"web-app": {
   >            "servlet": [
   >              {"servlet-name": @{names :String[]}, @_*}*],
   >            @_*}}` := servletDesc

   ? names
   # value: ["cofaxCDS", "cofaxEmail", "cofaxAdmin", "fileServlet", \
   #         "cofaxTools"]

(Read "@_*" as "Match and ignore all the remaining arguments.")

One of the changes from that thread which I also implemented, even though it 
wasn't needed for JSON compatibility: The expansion of the attribute sugar 
syntax now places the ".attr." tag on top:

   ? term`foo: bar` == term`.attr.(foo(bar))`
   # value: true

The remaining deficiency is that Tags still store their "name" as a string 
rather than a list of strings. Some related problems that won't be fixed until 
this is:
* quoted strings are not yet accepted as segments of tags.
* term`::foo` is currently != to term`foo`


                Manipulating Kernel-E ASTs as Term-trees


I've finally provided something that Dean's been needing for a long time, that 
I think I've been promising him for over a year.

We've had, for a long time, the ability to convert Kernel-E ASTs from their 
ENode representation to a more generically manipulable Term-tree 
representation, via the makeConvertENode2Term.emaker, which I see Kevin uses 
in E-on-CL. But if you want to use quasi-literal expressions and patterns to 
manipulate these, you have to express these in terms of their expansion to 
Term-tree structure, which is verbose. Given the available building blocks, it 
turned out to be trivial to assemble a new quasi-parser to give Dean what he 
needed -- the ability express these quasi-literals using E syntax:

     ? def termE__quasiParser := <elang:syntax.termE__quasiParser>
     # value: <termE__quasiParser>

     ? def x := termE`a + b`
     # value: term`CallExpr(NounExpr("a"),
     #                      "add",
     #                      NounExpr("b"))`

     ? def y := termE`c * $x * d`
     # value: term`CallExpr(CallExpr(NounExpr("c"),
     #                               "multiply",
     #                               CallExpr(NounExpr("a"),
     #                                        "add",
     #                                        NounExpr("b"))),
     #                      "multiply",
     #                      NounExpr("d"))`

     ? def termE`@w * @z` := y
     # value: term`CallExpr(CallExpr(NounExpr("c"),
     #                               "multiply",
     #                               CallExpr(NounExpr("a"),
     #                                        "add",
     #                                        NounExpr("b"))),
     #                      "multiply",
     #                      NounExpr("d"))`

     ? w
     # value: term`CallExpr(NounExpr("c"),
     #                      "multiply",
     #                      CallExpr(NounExpr("a"),
     #                               "add",
     #                               NounExpr("b")))`

     ? z
     # value: term`NounExpr("d")`

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM