[e-lang] eonhs (Also,)
Mark S. Miller
erights at google.com
Mon Apr 11 08:18:32 PDT 2011
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
> (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
> I have. A link was in the text you quoted.
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the e-lang