[E-Lang] down with 'define'

[Ralph Hartley]

Marc Stiegler wrote:

> Ralph, this works correctly in E, too. The passage
> 
> class fooMaker() :any {
>     def foo {
>         to A() {foo B()}
>         to B() {}
>     }
> }
> 
> works just like Java. Is there something about Walnut that misled you on
> this point? Should I put an explicit example in the book showing that this
> works?

I have to admit I only skimmed Walnut.

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?

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?

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

> 
>>> In at least the C like languages of which I'm aware, the rule seems to
>>> approximate "name is in scope from point of introduction until the end
>> 
> of
> 
>>> block (i.e., close curly)".   That's why a Java programmer would not be
>>> surprised at the above result, and would be surprised if the second
>> 
> sequence
> 
>>> was accepted and meant the same thing.
>> 
> 
> Once again, this is the same as E behavior. I would appreciate any help you
> can give me on how Walnut managed to be confusing (or at least no
> clarifying) on this. It could just be that I explicitly talk so little about
> scope, it may just need more explanation.

I don't think my problem is that walnut is misleading at all. I think I 
understand (I was wrong about methods, but they work the way I want), I 
just don't agree that it should be that way.

Scopes should always start at a { unless there is a good reason. I don't 
really think there ARE any good reasons.

Java CLAIMS to have a good reason for the special case of variables. I 
don't really agree in that case either, I just forgive.

For functions, or class definitions, there is no real excuse. If I 
understand correctly now, they are final variables, so there can be only 
one assignment anyway, so the initialization can always be found 
statically. They are so often so interdependent that having to do 
something special to make them so ...

> Have you any thoughts on a lighter-weight alternative to emakers?

Not really, but I can give some constraints:

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.

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.

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.

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.

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).

> My latest experimental versions of the EBrowser make it quite comfortable to
> work on programs several thousand lines long by allowing you to navigate
> through the code easily even though it is all one file.

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.

Ralph Hartley