[E-Lang] get, set, and dot
Mark S. Miller
Tue, 27 Feb 2001 14:03:03 -0800
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
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
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
>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
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
>* 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
Thank you very much. I'm curious -- which are the ideas that strike you as