[E-Lang] get, set, and dot

[Mark S. Miller]

At 03:33 AM Monday 2/26/01, Vijay Saraswat wrote:
>Cant figure out how I feel about E vs Java until I truly grok E, still stumbling
>along the path there...the syntax is definitely an issue. It is very easy to
>understand Java syntactically OTOH (until you get to nested/inner classes,, and
>once you jump across the thread divide).
>
>(But of course in part that was because a lot of documentation and examples were
>available when I first started to look at Java seriously in Jan 97..)

Another issue to keep in mind is that E is also a scripting and command line 
language.  Indeed, if ENative comes along in time, current plans are for it 
to be the default shell language for EROS.  The world has never before had 
an openly available capability-oriented shell for a capability OS.  This 
puts different pressures on the syntax than the pressures on Java.  I am 
(perhaps foolishly) trying to satisfy both sets of pressures.


>Yes, but the key is that it really does work well in practice.. lots and lots of
>programmers are able to "internalize" what the language does, and use it without
>the *language* becoming the issue. In some sense, people's "internal" model about
>C-like languages is not really violated by Java in any significant way.
>(Again, Java is a very conservative design, and that is what makes it so good. It
>had very few new features in it, things that really need to be worked out. One
>scheme that the designers appear to have followed which seems to have worked well
>is to keep the syntax spare -- even when introducing new "language" ideas such as
>Threads or Class Loaders. There is no new syntax for them!! I admit I found this
>frustrating at first...)

These are all good points.  Java's semantics is way too huge, but it's 
syntax is indeed spare.  While I've never taken seriously the corresponding 
criticism wrt Scheme and Smalltalk, because they haven't caught on, I 
clearly need to take the comparison with Java seriously.  Likewise with 
Python, which Zooko brings up later.

So, while keeping in mind the extra pressure on E's syntax mentioned above, 
I do take this tread quite seriously, and I will be making some additional 
reductions to E's syntax.  A syntax is in many ways a work as a whole, so I 
will be mulling these issues over together before making concrete proposals, but 
please everyone, let's keep the argument going.  And thanks.


>> * While I do have several kinds of patterns, this includes the one pattern
>> which defines a variable.  This replaces the many kinds of Java variables:
>> instance, static, parameter, and local.  Besides, the pattern matching is
>> clearly inspired by the logic programming experience we have in common --
>> it's approximately the subset of unification in which variables appear only
>> in the head, not the data.
>
>I much appreciate where this comes from. Is it necessary to have it in E? (It may
>well be .. it may well be that there is a smooth flow from the introduction of
>eventuality etc into this style of programming, havent thought that through.)

Well, "necessary" depends on what you're trying to do.  The built in pattern 
matching allows many idioms to be expressed naturally, like returning 
multiple values:

    define [sealer, unsealer] := BrandMaker pair(name)

and many other patterns familiar from our logic programming days.  This 
notion is so natural simple and powerful that I feel the case for it is 
compelling.

It has no strong relationship to E's EVENTUAL references or eventually sent 
messages, and neither of these by themselves would motivate the inclusion of 
patterns.


>Also, if you are starting with Java, instance/static/parameter/local variables are
>already internalized. Why muck around with them syntactically? Is it *necessary*
>to do this to get capabilities into mass use?

We're not starting with Java specifically.  We're starting with the cloud of 
familiar concepts we call "The C Syntactic Tradition", a prime 
representative of which is Java.  I do believe it's necessary to shift away 
from classes with multiple variable types, especially the horrible "static", 
and towards simple lexical scoping.  Why?  I quote the text at the end of 
the Ode's MintMaker 
http://www.erights.org/elib/capability/ode/ode-capabilities.html in it's 
entirety:

In the Ode, MarkM, Chip, and Bill wrote:
>Notice how the scoping rules together with the capability rules allow us to 
>"prove" many security properties through a simple visual inspection:
>
>* By scanning for all occurrences of sealer and unsealer, we can quickly 
>determine that they never escape from the mint and purses of their creating 
>currency. 
>
>* Since the sealer is only used to seal the decr function, a successful 
>unseal can only result in a decr function of the same currency. 
>
>* By scanning for all occurrences of decr, we see that it can only escape 
>sealed in an envelope. Since the unsealer cannot escape, the sealed decr can 
>only appear as the result of visible unseal operations. Since this 
>unseal-result is only invoked and never sent in a message, decr cannot escape. 

Earlier you said you like anonymous inner classes.  Well, if you just leave 
these in, and remove everything they make unnecessary, you and up at 
essentially the same lambda-like place that E does.

Back to Vijay wrote:

>If the goal is to get capabilities right and out to the masses, anything else that
>might possibly come in the way should be scrupulously examined.

Agreed.  We should continue to do so.


>Working on it. I will take up your suggestion below about starting with Kernel E,
>with interp expansion set to true. Will let you know how it works...
>
>(Does put me in the position that I have to get a working version of E on my
>laptop to understand the language..maybe that was your grand design all along :-))

How fiendish and clever of me!  Ha ha ha!  (said as Vincent Price would 
have)  In any case, now that you mention it, it is hereby retroactively my 
plan all along.


>All said, I am excited about how far ideas have progressed! There is a lot going
>on here!!

Thank you very much.  I'm curious -- which are the ideas that strike you as 
exciting progress?


        Cheers,
        --MarkM