[E-Lang] get, set, and dot

[Mark S. Miller]

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 
you enumerate:

* 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/forExpr.html and 
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 
implemented.

* 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
    # expansion:
    #   2 add(3)
    
    # value: 5

As we see above, "+" is just syntactic sugar for the "add" message.

    ? interp.expand := false
    # expansion:
    #   interp setExpand(define var ares_3 :final := false)
    #   ares_3
    
    # 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.


        Cheers,
        --MarkM