Re: eonhs: Announcing E on Haskell

On Sun, Apr 10, 2011 at 5:17 PM, Kevin Reid <kpreid-M/[email protected]> wrote:
> On Apr 10, 2011, at 19:30, Nathan wrote:
>
>> Greetings,
>>
>> I've begun implementing E on Haskell: https://bitbucket.org/nejucomo/eonhs
>
> That's funny, so did I:
>  http://switchb.org/svn/e/e-on-haskell/trunk
>  http://wiki.erights.org/wiki/E-on-Haskell
>

Ah, yes.  I've slacked on my existing work research.  I'll look into
E-on-Haskell, thanks!

Where they overlap, I may be tempted to reinvent the wheel, because I
enjoy learning with first-hand experience.  OTOH, if there were user
demand, I would prioritize not reinventing the wheel.


> (That was some time ago, and it is not especially complete. I also find to
> my dismay that I have uncommitted major changes from 2006 on my disk.)
>
> Since you're allegedly focusing on Kernel-E and my project only touches
> ELib, perhaps they can be usefully combined.
>

I'll look into that.

>> Currently there is a parser and interpreter for literal values,
>> references (but not binding patterns), and expression sequences.
>> There is no commandline other than a non-interactive unit test runner.
>>
>> There is much I do not understand about E language specifics, but I'll
>> certainly be learning about these soon!
>
> I see in your project info “The roadmap is first to implement a Kernel-E
> interpreter with internal-only eventual sends, wait-clauses, and
> pipelining.”
>
> Please note that all three of the features you name are *NOT* part of modern
> Kernel-E; they are ELib features with syntactic sugar (not-kernel-E)
> support.

Ah, interesting.  As you can see, I am using a lazy-research-strategy:
I've started implementation with a lot of pending research and once my
implementation approaches the limits of my knowledge, I investigate at
that point.  This may lead to heading down design dead-ends, which
would be... educational.


> ELib (so named because it was originally envisioned as a separable Java
> library) provides the core E semantics (the Haskell analogue would be
> defining the E monad, as my EoH does) as well as basic objects (data
> structures, etc).

I see.  Does ELib encompass cryptographic networking protocols, or is
that yet another component?


>
>> My strategy is for test-driven equivalence between implementations as
>> a means to improve the specification.  I have not yet hunted for a
>> language implementation test corpus, but I intend to see if/how
>> E-on-CL and and E-on-Java verify their compliance.  Is there such a
>> test framework?
>
> The most complete existant set of tests for E at all is the E-on-CL test
> suite. It is, of course, written for E-on-CL, but large portions of it
> should be portable.
>
> The Plan is that the E specification and corresponding tests should exist on
> <http://wiki.erights.org/wiki/Category:E_specification>. However, very
> little of this yet exists. The first problem is that E-on-Java (the main
> target for running the tests from E-on-CL against) has no useful support for
> running Updoc source without privileges; therefore it is not safe to run
> code directly downloaded from (a) a wiki (b) over HTTP.
>
> However, at the small scale that can be avoided by downloading the tests and
> inspecting them before running; also, E-on-CL has the options --updoc
> --confine and your E-on-Haskell is surely in a good position to implement
> similar features.

I'll look into the E-on-CL test suite and keep --updoc --confine in
mind.  Thanks for the suggestion.


> (Also, testing all-of-E from unprivileged code implies a number of other
> features such as filesystem sandboxing, but that's rather beside the point
> for this.)
>
>> What I imagine is a tarball filled with scripts or makers that meet some
>> compliance interface (such as computing some values and asserting
>> post-conditions).
>
> No, we use Updoc and only Updoc.
>
> There is no “tarball”, but if you simply (ha) download all wiki pages which
> are in categories which are or are subcategories of Category:E
> specification, then you will have all the test material which exists.
>
> There should, but does not yet, exist a standalone program which downloads a
> copy of the relevant portion of the wiki. There is a specialized and
> half-baked version of such a downloader used by the E-on-JavaScript test
> suite.
>  http://wiki.erights.org/wiki/E-on-JavaScript
>

bitbucket.org has a nice feature (if you are comfortable with
mercurial) which is that the the wiki source for each project is a
mercurial repository.  Maybe the implementation at wiki.erights.org
has something similar or there is an extension?


>>  It is important this corpus
>> also contains negative tests, which can be useful for finding and
>> avoiding dark corners in parsers, grammars, and semantics.
>
> Yes. Contributions of such tests, especially if they are well organized
> beside existing tests, would be highly appreciated.

I'll keep this in mind also.  When I suspect the first tests I'll look
for (or will write) will be for understanding scoping semantics.


>>  Along with
>> this tarball a driver program would execute the test cases for each
>> available implementation and display a diff of their results.
>
> This is what Updoc does (diffing at a test-case granularity, which is
> generally sufficient).

Ah, I hadn't yet discovered Updoc.  Neat.


>> I have noticed some syntax variation in code examples and the language
>> versioning pragmas.  I'd like to only target the "latest stable language
>> definition".  Is there documentation on the differences between language
>> versions?
>
> Not very much except in this list's archives.
>
> Please, please, please: Whenever you learn something, make sure it exists on
> the wiki, and ask questions here: I will make an effort to get the
> information out of my head (or MarkM's if necessary) and onto the wiki.
>

Will do.

> (Context: MarkM is extremely busy pushing capabilities-in-JavaScript, and
> I'm busy working on a bachelor's degree. Neither of us have much
> time+brain-space+enthusiasm to work on E, but if I have a seed of a question
> or an incomplete/wrong statement I can manage to write some wikitext on a
> topic. Or stuff like this email. It is also *possible* that I will have more
> suitable conditions this summer.)

This is helpful context.  Speaking of which, has anyone investigated
an E-to-JavaScript translator?  I suppose the general consensus may be
that simply relying on strict-mode ES5 is the way to go?


>> Finally, E-on-Java absorbs much of the standard library.  Is there a
>> well-defined subset of standard interfaces which both E-on-Java and E-on-CL
>> support?
>
> There should be, and it should be documented on the wiki.
>
> More precisely: All core E objects (numbers, strings, lists, maps,
> TypeDescs, auditors, etc.) should have identical interfaces across all
> implementations; insofar as they don't that's a bug or one implementation
> not keeping up with another.

What I would prefer as a programming language user is to see API
documentation written explicitly for E for all of these APIs.  Is
there such a reference that is not the JavaDocs?

Perhaps if I implement these features, or if I incorporate the haskell
elib analog, I'll start writing such a reference.  This would help
draw the boundary between "common E" APIs and E-on-Java absorption or
implementation details.


> However, variation in such things as the names <import>able is more
> acceptable. (That said, I think the <import> system needs to die because it
> is poorly extensible (uses a global namespace) and does not fit the E model
> well. (In Java, it is natural to import a class and then use the values of
> static fields from it; in E, not so much. Also, the emaker style of E module
> definition means that anything with shared implementation components needs
> to be defined in a single file, which is clunky.)

I haven't grokked the module system of E yet.  Although I'd like to
produce a compliant implementation, I also prefer to drop features if
they are widely accepted as unnecessary or warty.

>
> --
> Kevin Reid                                  <http://switchb.org/kpreid/>
>
>

Nathan