Re: eonhs (Also,)

On Sun, Apr 10, 2011 at 6:54 PM, Kevin Reid <kpreid-M/[email protected]> wrote:
> Your mail software or practices seem to be disregarding the Reply-To header.
> Please fix that.
>

Sorry about that.  It wasn't my mail software, it was my behavioral
software, but I found the bug and patched it.


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

Ah, let me resolve my vague question into a specific story:

Suppose I want to reach as many users with as little develop cost as
possible for a new application, but I also require the application to
be as consistent as possible in following object-capabilities
discipline.  Finally, assume that relying on web servers and web
browsers maximizes that users-per-dev-time ratio.

Now, given those goals and restrictions, would it be more worth my
time to work on translating E to JavaScript, or to rely on Caja or
ES5-strict mode for the browser-side of my application?

I had initially assumed because ES5-Strict is headed towards
platform-standard, that the general consensus would be to develop
applications for it.  But now that you asked and I thought about it
more, I still wonder if translated languages might be worthwhile for
minimizing development costs (maintainability, debug-ability, ease of
writing robust patterns (such as guards and auditors), ...)

By asking about the consensus I meant to discover if this kind of
issue had previously been discussed.  If for example someone replied
with: "Yes, everyone here unanimously believes that nobody should use
E anymore for web-based applications because there are these new
capabilities-secure technologies with wide platform support and large
developer mind share.  We discuss E here mainly as a research
prototype for capabilities-secure language features." -then I'd
probably consider spending my time looking into those other
technologies.


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

These two paragraphs are quite useful to know, and I hadn't realized
the JavaDocs were out of date.  (I jumped straight into them from a
google query, btw, so if that's mentioned on the wiki I missed it.)

After a quick click-around from the erights.org home, I find this page
links to them, but does not mention they are out-of-date:

http://www.erights.org/elib/index.html

I understand that there's precious little time for maintenance of the
online references.  I'll focus my efforts on the wiki when possible.
Speaking of which, I just when through the create account flow on
submitting my username/password/other-credentials, I get a blank page.
 I received no email, and when I try to log in it says there is no
such username.


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

Will do.  The account creation widget seems broken.


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

I'm interested in the module system.  I responded with some thoughts
and preferences.

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

I don't see <uri:...> syntax in the Kernel-E grammar.  So far I have
only been studying the Kernel-E grammar and not the standard APIs (and
reading markm's thesis).  The grammar seems to have no import
specialization, so my current mental model is that there is some
standard API for loading code.

Could you point me to a reference or example of an E builtin library
being imported?  If it is syntactic sugar for an API call, I'll hunt
down the loader implementation.

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


Nathan Wilcox