Re: eonhs: Announcing E on Haskell

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

(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.

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

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).

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

(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

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

>  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).

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

(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.)

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

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.)

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