[e-lang] eonhs (Also,)

[Mark S. Miller]

On Sun, Apr 10, 2011 at 9:54 PM, Kevin Reid <kpreid at switchb.org> wrote:

> 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 at switchb.org>
> > 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),


I don't consider it obsolete. I just rarely have reason to name the whole
stack rather than referring to VatTP and CapTP separately.




> 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/>
>
>
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20110411/56ccc448/attachment.html