[E-Lang] Draft Kernel-E DTD & Sketch of translation to debuggable Java

[Dan Moniz]

>>>>> "Dan" == Dan Bornstein <danfuzz@milk.com> writes:

    Dan> After having spent a large fraction of the last few months dealing
    Dan> with a large distributed app that uses RMI for most of the IPC, I'll
    Dan> have to weigh in that I have concerns about JOSS.

Me too, but I confess complete ignorance about JOSS and most Java
communication tools as well. The last time I touched it was under another
company working with EJB, and I refused to have anything to do with it.

Also, the reader is hereby warned of my status as a Lisp zealot.

    Dan> The short story is: If all you ever expect to send over the wire are
    Dan> instances of classes that are already known to both ends (and are
    Dan> serialver equivalent on both sides), then you're okay, but if you
    Dan> *ever* expect to have one end be able to receive instances of a class
    Dan> it didn't already know about, or receive instances of a class that are
    Dan> of a newer version than the one it knew about, then forget about it.
    Dan> JOSS doesn't seem to provide any particular support for that sort of
    Dan> thing. (The RMI layer sortakinda tries, but it ends up falling pretty
    Dan> flat too.)

Long term, I think this is crticial. I envision having Kernel-E talk to all
sorts of things that may be Smart Contract aware, but not necessarily E aware.
What I'd really like to see is an abstract Smart Contract concept turned into
an engine in the form of software or hardware, and have E be the glue, so to
speak. E becomes a tool for Smart Contracts.

So, continuing with this half-baked blue-sky theory, you have a printer that is
SC capable, using it's own trimmed down syntax spec for expressing SCs amongst
like printers. You never want to enfore users to use this, nor programmers. So,
users specifiy the SC they want in some high-level notation (perhaps English
with XML behind the scenes) or the programmers choose something easily done
from within the language or tool they're working in. Assuming we're working
with E, E can send a SC to the printer using XML and the printer can grab that,
transcode it to printer-SC-speak and we're all happy. Perhaps language X also
becomes a player in the SC field, and it's written in INTERCAL, or my personal
obfuscated favorite, unlambda. Same rules apply.

Of course, by the time this (may) happen, I'm sure printers will be walking,
talking, high-level machines writing their own novels with the help of
networked integrated CYC-like knowledge bases and petabytes of storage, so who
am I fooling.

Still, XML is thinking in the big wide open spaces. I don't think anything else
is. It's a sort of future proofing, the way I see it.

Then again, I've also been known to call XML "Lisp, with angle brackets over
parens, and minus all of it's reflective qualities".

    Dan> Simple example: Let's say you had strings, ints, and vectors as types
    Dan> you wanted to be able to directly represent, you might end up with XML
    Dan> like this:

This is a neat case. Supercite mangled the following lines where Dan put
together a sort of hypothetical XML v. JOSS case. I don't know about JOSS, but
the XML is still validly parsed and validated in this format since the tags
mean more than newlines. It's also still eminently readable. Can someone
comment if the same is true for JOSS?

    Dan>     <vector> <el><int>1</int></el> <el><string>foo</string></el>
    Dan> </vector>

    Dan> which would end up getting constructed in Java by the equivalent of
    Dan> this:

    Dan>     v = new Vector (); v.add (new Integer (1)); v.add ("foo"); return
    Dan> v;


-- 
Dan Moniz <dnm@pobox.com> [http://www.pobox.com/~dnm/]