[E-Lang] down with 'define'

[Marc Stiegler]

> Does this mean that E is inconsistent in the same way java is? I think
> we were talking about functions before. So in this respect, methods in E
> are different from functions?

E functions are really objects under the covers. So in the end, they behave
like objects, not methods. You are correct that E classes need forward
referencing--but only if they do mutual construction. If E classes only need
to manipulate already-constructed objects of each other's types, forward
referencing is not required (no static typing needing to be checked).
Consequently, forward referencing between classes is much more rare than one
would expect simply trying to think about how java (or even C structs) would
require forward references. In fact, I don't remember having needed a
forward reference between between classes at any time in my past year of E
programming (which is not to say it doesn't happen, it is merely a statistic
to indicate it is rare).

> I can't talk about what java does with functions, because java doesn't
> have functions at all. If it did I would expect them to act like
> methods. In fact, when you really need functions in java you use static
> methods. Does E (looked at as a class language, which I know it isn't
> really) have an equivalent of static methods? If so, do they behave like
> functions or like methods?

E does have the moral equivalent of static methods in that the Maker/classes
can have methods which are not "new" constructors (though they are not as
public as Java static methods because the classes themselves are not as
public). They are methods and behave like methods, i.e., the constructor can
make calls to the class methods independent of ordering inside the class
definition.

> What about classes? They need mutual references to each other all the
time.

Answered above. I believe the news is better than you feared, though still
worse than you require.


> Putting files in any place outside of the current directory is not
> permitted. Sub directories are OK, I guess. "System" places, like the
> normal java class directories (even just my personal ones), are NOT ok.
> If I am working with an experimental version of a program I also use,
> the versions must not be allowed to mix.

Good point.

> It would be nice to be able to compile a file before other files it
> depends on are written. Java doesn't satisfy this, and I don't even know
> if it is possible. Separate .h and .c files do allow this, but that cure
> is worse than the disease.

Yes, a ghastly cure. There are patterns of usage in E that would allow
"compilation" (really syntax checking in E as it stands today) without
creating the other files (actually, the other Makers) first, though none of
the patterns that come to mind at a moment's notice are satisfactory for a
single general-purpose solution.


> There should be an automated mechanism for determining what files need
> to be re-compiled when one file has changed. Java is pretty broken in
> this respect too. This is more a tool issue than a language issue, but
> there needs to be an easy way to get and use the dependency graph.

Understand that "compilation" in E is not exactly the same as compilation in
Java or C. In fact, E is currently just an interpreter. So this only gets
interesting for E when there is "real compilation" to byte codes or machine
language. In those cases, it follows the rules of the underlying system.
Though markm probably needs to correct what I have just said (next week,
since his email allotment for this week is already gone :-) Trying to
project what markm might say, I suspect the answer may be more akin to the
answer given by people who have big Python systems, in which I hypothesize
the answer is "this is not a correctly phrased issue". Python people are
welcome to jump in here :-)


> Re partitioning code between files should be as painless as possible.
> This is one of those places where "forward definitions" are going to get
> you.

I believe you are correct that file repartitioning may be important in E,
though I've noticed that in Java I have never repartitioned based on files.
As markm demonstrated in earlier email, this is not a place where E needs
forward definitions anyway. I would also expect E to be identical in
goodness/badness to Java when it comes to repartitioning based on package
(which maps to a directory in both E and Java).

> It must not be necessary to explicitly name all the files a given file
> depends on, or all the symbols imported from them. Java automatically
> imports some (the classpath), and uses "import" with wild cards for
> others. Importation really should be INSIDE a scope (unlike java, but
> java's "one file one class" rule mitigates this).

What really mitigates this in Java is the ocean of ambient authority hanging
around that makes scope largely irrelevant. For a secure system, it cannot
be exactly this way: importing inside an importer's scope can only be
allowed if the imported object is fully trusted by the importer, and should
only be appropriate if the imported object actually needs that much
authority based on POLA. It is interesting, however, to think explicitly
about "scope construction" as a part of the import to make simple. I suspect
that an easy way to say "use the importer's scope" will be required for
language  adoption, though we will one day curse it for the security risks
it entails (since it will generally not follow POLA). Hmmmm.....

> Of course this is not a real option. A project with more than one
> programer (and I'm so scatter brained, I count as more than one) needs
> more structure

We agree that bigger projects need more structure, but I have experience
demonstrating that "structure" does not have to map to "files". In my
earlier email, I should have said, I have also run projects with teams of
people using smalltalk, and using tools rather than files worked pretty well
there too. Supporting your point I would have to say, I think the sharing of
material across programmers was a bigger, clumsier part of the development
effort in Smalltalk than in other languages...but contradicting your point,
I would have to say that that has a lot to do with the fact that actual
software development was smoother, faster and easier in Smalltalk than in
other languages, so other parts of the effort stood out more in contrast :-)

You have provided a very thought-provoking list of requirements for the
future of emakers. Thank you.


--marcs