Re: eonhs (Also,)

On Apr 11, 2011, at 23:03, Nathan wrote:
> 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), ...)

I am confused as to how translation would *improve* maintainability  
and debuggability.

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

A much weaker form of this statement is probably the case. ES5-Strict  
is happening, and furthermore the Caja project is working on a  
compatibility layer which implements ES5 on existing ES3 browsers (by  
translation + runtime library).

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

It is desirable to migrate that material to the wiki, updating it  
along the way. Also, MarkM has given blanket permission for  
incorporating into the wiki any doc-comments in Java code by him (i.e.  
beyond the code license).

The non-wiki site's source lives in <svn://svn.synchrona.org/erights/ 
doc>. Patches (of the form of removing suitable material and changing  
links to it into the wiki) welcome!

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

Please repost this separately or otherwise bring it to the attention  
of James Graves <[email protected]>.

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

Kernel-E is a kernel. It sounds like you haven't spent enough time  
studying E code as actually written (any of the code in esrc/ in the E- 
on-Java distribution, or any standalone E program, should do).

The URI syntax expands as:

   <import:foo.bar.baz>
=>
   <import>["foo.bar.baz"]
=>
   import__uriGetter["foo.bar.baz"]

The implementation is in org.erights.e.elang.interp.ImportLoader.

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