[E-Lang] get, set, and dot
Mark S. Miller
Mon, 26 Feb 2001 01:01:23 -0800
At 11:27 AM Sunday 2/25/01, Vijay Saraswat wrote:
>I should have done that acronym better -- Keep Its Syntax Simple :)
>Java look and feel is fine. There is a real-world language that (but for
>threading) is clean!
>E does not quite seem to have Java's look and feel..e.g. lack of static
>type-checking, addition of pattern matching, new kind of for loops etc.
If Java looks cleaner to you than E, I am shocked and humbled, and I truly
wish to understand why, and to repair the damage. I realize you didn't say
that it does look cleaner, merely that they look & feel different, but these
two statements together have me worried. Regarding the individual points
* Though there are other arguments for including static type checking in a
language, its inclusion does make a language significantly larger and more
complicated. Java's static type declarations have a further complexity cost
-- Java's type-based static overload resolution means one can no longer
reason about the type declarations as purely a static theory about the
dynamic behavior of the program. Java's declarations must also be
considered part of the meaning of the program.
* 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.
* You could say I have two kinds of for loop,
http://www.erights.org/elang/blocks/forKVExpr.html , but it's more accurate
to think in terms of one kind of for loop in which the "key-pattern =>" part
is optional. That's how I think of it when I'm programming, and how it's
* Please let me know about the "etc.".
>Perhaps I should really start with ELib first and under the core capabilities
>(:-)) it provides before trying to understand the E language...
I think it's much harder to understand E by looking at ELib first, as you
have two object models fighting each other -- Java's and E's. This battle
creates complexity normally hidden from the E language programmer. I
definitely recommend against that route as a way to learn E. For you, I
suggest learning Kernel-E first. To help, at the E command line, you can type:
? interp.expand := true
# value: true
This tells the command line processor to show the expansion to Kernel-E of
the expression typed in, as well as the value it evaluates to.
? 2 + 3
# 2 add(3)
# value: 5
As we see above, "+" is just syntactic sugar for the "add" message.
? interp.expand := false
# interp setExpand(define var ares_3 :final := false)
# value: false
When we turn the expansion mode off, we see that we were really doing
calling "setExpand(false)" on interp. The definition and use of the
generated variable "ares_3" implements the rule that the value of an
assignment is the value of the expression to the right of the ":=".
Of course, this doesn't mean that "." is a good idea, and I'm perfectly
receptive to the idea of taking it out. However, above I'm trying to show
that you don't have to understand all the syntactic sugar before you get
started. For anything you find puzzling, just expand to Kernel-E. I don't
think it's the best strategy for everyone, but I'd recommend it for you.
Please let me how well this works for you.
After learning Kernel-E well, either ELib or the full E language are
plausible next steps.