[e-lang] A thought experiment: Minimal-E

[Kevin Reid]

On Jul 5, 2006, at 20:29, Mark Miller wrote:

> I like this notion of defining a Minimal-E, as a way of defining  
> much of the semantics of Kernel-E in terms of further expansions.  
> Do you suggest any operational role for Minimal-E (as opposed to  
> Kernel-E)?

Not at the moment.

> Since reflection (e.g., by audting or 'meta.context().getSource()')  
> does reveal the expansion to Kernel-E, these equivalences, and any  
> others, are only "operationally equivalent up to reflection". ...  
> Further, many of these expansions break a single object up into  
> several objects, e.g., by repackaging an internal block as a  
> closure. This changes the semantics of constructs that are  
> sensitive to the placement of object boundaries, ...

I agree. This 'Minimal-E' is not intended to be suitable for  
expansion of Kernel-E; merely demonstrates equal expressiveness.

> One possible operational use I can see is for an auditor to first  
> expand its ObjectExpr to Minimal-E to reduce the number of cases it  
> needs to care about.

Interesting idea. Perhaps a Minimal-E transformer should be written;  
it would somehow include notes about the above reflective shortcomings.

> Neither Kevin's __Mcatch nor the attached __try can itself be  
> implemented in Minimal-E. In order for try-catch to not be a  
> special form in Minimal-E, either __Mcatch or __try would need to  
> be a primitive object. Nevertheless, this is interesting, as  
> primitive objects arguably add less weight to the language than  
> special forms. For example, a maximally absorbing meta-circular  
> interpreter needs to
> mention all special forms, but not primitive objects.

Yes. There are inevitably far more 'primitive' objects anyway, so  
allowing them is less 'weight' than E language constructs. Also,  
'throw' is already such an object, so it could be considered cleaner  
to have all exception operations be objects.

I would like removing catch/finally from Kernel-E to be considered.

> The above expansions are much more disciplined than even hygenic  
> macros. In particular, they enforce E's scoping rules no matter  
> what the logic is of the control abstraction being invoked.

And they cannot suffer from node-specific bugs in a Kernel-E  
implementation.

> On 7/2/06, Kevin Reid <kpreid at mac.com> wrote:
>> CdrPattern
>>
>>    [a] + b
>>    via (__Mcdr(1)) [a, b]
>
> Yes, E-on-Java 0.8.37a already does essentially this during  
> expansion to Kernel-E. As of that version, CdrPattern is no longer  
> part of Kernel-E.
>
>    ? epatt`[a] + b`
>    # value: epatt`via (__splitList.run(1)) [a, b]`

I see no significant problem with this expansion, and will change E- 
on-CL to match it.

Clearly, an effective E optimizer will need to inline objects like  
__splitList and eliminate temporary result lists.

>> LiteralExpr
>> ... __MlitInt."1.0"()
>>     __MlitString.abc()
>>     __MlitChar.a()
>
> While I agree that these work, they are just too weird for my taste. I
> would include the literals in Minimal-E, even though this isn't in
> some sense minimal.

We already have the small-but-not-minimal-E - that's Kernel-E. This  
is Minimal-E.


-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>