eonhs (Also,)

On Tue, Apr 12, 2011 at 3:19 AM, Kevin Reid <kpreid-M/[email protected]> wrote:
> On Apr 11, 2011, at 23:03, Nathan wrote:
>>

[...]

>> 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 providing guards, interfaces, sane equality semantics, and
immutability at the language level I would expect fewer bugs.

Debuggability is indeed tricky and would be worse without some work.
In this video interview, markm mentions debugging hassles on the Caja
project:

http://www.infoq.com/interviews/ecmascript-5-caja-retrofitting-security

It sounds as if they augmented a debugger to do reverse
translations (which does indeed sound like a nightmare; potentially
impossible or misleading to the programmer).

Instead, I would like to promote a different approach in which the
debugger is agnostic about the source language and has access to the
original source and a translation map.

An automated translator could take an input file in the
source language, L, and generate the target language, JS, and a
translation map, M.  The map would define which character offsets in
JS map to which in L.  JS should uniquely refer to (L, M) (such as by
cryptographic hash) as well as enable their retrieval (such as by
URL).  This would be in a comment in the target file, JS, to be
backwards compatible with non-aware debuggers.

The debugger would require a parser which reveals the offsets of each
parse tree node.  If it notices a comment naming a map and
source and it can fetch them, it could display both the target
JS and the source L in a side-by-side source view.  UI features like
code highlighting could update both views.

As a benefit, this would teach the programmer to reason about what
the specific translation rules are.

The mapping standard should be unambiguous about how offsets are
defined, and the debugger parser would have to follow that standard.

Because there are a growing number of translated languages, perhaps
their inventors could collaborate on such a debugger standard.


[...]

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

Great!  I'm satisfied with how convenient it will be to generate patches.


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

Done.


[snip...]

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

I'll change my approach to spam this list with fewer such questions.
Instead I'll
track those questions on the eonhs wiki and answer them by my own research.
If something seems surprising, or the answer is not readily on the
wiki, I'll update
the wiki.

Thanks for the feedback!


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

Thanks!  On my todo list is to hunt down a reference for all the
syntactic sugar translations between E to Kernel-E such as this.

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


Regards,
Nathan Wilcox