[E-Lang] pending revision of E in a Walnut

[Chris Hibbert]

Since you asked, I'll gather up the notes I've made on my copy.  I'll
post this publicly, since at least one of my comments is as much about
language design as it is about your document.  I have yet to write my
first E code, so I write as a 
real neophyte.  


The default new() method seems suspicious to me.  I haven't done enough E
programming to see whether the implications are parallel to those in Java,
but there's are several reasons why Agorics' coding standards forbid
reliance on the default new() method provided by Java.  First, it's always
public, which may not have a bearing in E, but I'm not sure.  (If you
don't want to let some clients call new(), what do you have to do?)  In
Java, the new() method always nails down the actual type of the object
being created.  It can't be virtualized like other methods, because of the
way it's implemented primitively.  Finally, there are some kinds of
initialization that can't be done in the constructor, and so allowing
clients to call new() can mean that they get uninitialized objects. 
Having to explicitly code all the other methods to ensure the
initialization code is called is vastly inferior to ensuring that the
public factory methods return only initialized objects.  


Second, I wonder whether there aren't security implications of treating 
the arguments to the constructor as instance variables.  Does this make
it 
easy to forget to make copies of them?  Will this lead to subtle
problems 
with wall-banging or other kinds of leakage, since the object the client 
supplied is known to be the one held by the object?


Under "Inheritance", you say "Some experts consider inheritance to be a
dangerous feature of programming languages [...]".  Does this statement
apply only to implementation inheritance?  Because I consider type 
inheritance to be the root of polymorphism, which seems to me to be the 
source of most of the power and benefits of OOP.  

Later in that paragraph you say "none of the full-blown examples in this
book actually use inheritance."  I guess that reminds me that I haven't 
seen much use of polymorphism.  (Other than in the coordinate spaces
code 
MarkM sent as part of a different discussion, but I haven't figured out 
how that works yet.)  I realize that E doesn't have strong typing, but
if 
it also deemphasizes polymorphic types, I'm likely to be disappointed.  
Why is this section here?  Do you have an aversion to type hierarchies
or to
polymorphism?  If not, I'd suggest being clear what aspect of
inheritance 
you're advising people to avoid.  If that is the point, I'd like to hear 
what I've been doing wrong all these years. :-)



Under Arrays and primitive types, it looks like the example is part way 
through a migration between bytes and ints.  You import the type "byte" 
from java, then define "byteArray" to be an array of ints ("int[300]").
I think the rest of the discussion assumes bytes.


In the explanation of the Eventually operator, you have a race car in the
example, and use at least three confusing senses of "move".  The main 
method that appears is moveTo().  In the second paragraph, you say the 
program "immediately moves on the the next sequential statement."  In
the 
fourth paragraph, you tell the reader she does not "need to know where
the 
car is."  You've just been sending moveTo() messages to the car and 
talking about the car's position in 2-space, and now you 
mean to emphasize an agnosticism about where the code is executing.  
Please use a method other than "moveTo()" to explain this point.


Chris