Re: eonhs (Also,)

Your mail software or practices seem to be disregarding the Reply-To  
header. Please fix that.

On Apr 10, 2011, at 21:19, Nathan wrote:

> On Sun, Apr 10, 2011 at 5:17 PM, Kevin Reid <kpreid-M/[email protected]>  
> wrote:
>> 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?

I am not sure whether this has always been the case, but:

   (a) they are largely separate in the E-on-Java package structure and
       dependencies;

   (b) the plan is to push all the crypto and distributed capabilities
       components into user-space, thus making them Clearly Not ELib.
       (The implementation of this so far exists in E-on-CL.)

You may also wish to know the distributed-capabilities component is  
called “Pluribus” (though this has sometimes been considered an  
obsolete name), and the actual protocol layers are “CapTP” (given  
secure channels, build distributed capabilities) and “VatTP” (given  
the Internet, build secore channels).

> This is helpful context.  Speaking of which, has anyone investigated
> an E-to-JavaScript translator?

I have. A link was in the text you quoted.
   http://wiki.erights.org/wiki/E-on-JavaScript

> I suppose the general consensus may be
> that simply relying on strict-mode ES5 is the way to go?

Is the way to go for what purpose?

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

No. This reference should exist, and it should be the same as the E  
specification. We do not have the manpower to maintain two separate  
documents. I consider the Common Lisp HyperSpec to be an exemplar of  
this type of documentation which we should strive to equal.

(Also note that the javadoc on erights.org is long outdated, as the  
hacked-Javadoc which produced it was not releasable as open source for  
some reason. Large portions of it are still sufficiently accurate, but  
the only authoritative source for that content is the E-on-Java source  
code.)

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

Please direct your efforts towards improving the content of wiki/ 
Category:E specification.

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

In my opinion, E does not have "a module system" yet. Thomas Leonard  
has some ideas on what it should contain, as do I; unfortunately  
neither of us has yet gotten to reconciling said ideas. You have  
prompted me to get around to writing up some of my Requirements For A  
Module System, which I will post separately.

If you can succeed in producing an E implementation in which <import>  
only exists as a backwards compatibility layer, and user libraries can  
be loaded fully dynamically (as opposed to the current classpath-style  
approach) and via the same kind of interface as E builtin libraries, I  
would be very pleased.

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