[E-Lang] down with 'define'

Marc Stiegler marcs@skyhunter.com
Tue, 6 Mar 2001 09:54:57 -0700


> Alas, Java is inconsistent on this point. In Java order matters for
> variables, but not for methods. Variables, as you say, have scope
> starting at the declaration. But
>
> class foo {
>   void A() {
>    B();
>   }
>   void B() {}
> }
>
> is legal.

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?

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


> >> Also, the only mechanism for using definitions in **different** files,
that
> >> I found in Walnut (emakers), is rather heavyweight. Is that the only
way?
> >
> > I'm glad you raised this.  Currently it is the only way, and it's too
> > painful and urgently needs improvement.  There seems to be a whole
subfield
> > of language design on the design of "module" systems, but I am currently
a
> > lightweight in this literature.  The issues to be taken into account are
at
> > least the usual ones: separate compilation, principled scoping, ease of
use.
>
> Without it no one will even consider E for any but the smallest
> projects. This is far more of a "Check box" item than inheritance, and
> with good reason.

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

Having no good ideas of my own, my vision has been to make the emakers
lighter-weight by the development of good tools so that it is not so much
burden to the programmer. This was the approach taken by Smalltalk, for me
it worked quite well, I do not believe this is the reason Smalltalk failed
to catch on.

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. The next major step
toward lighter weight is to make the environment automatically
construct/maintain collections of emakers in zip/jar files. My sense of the
result at the end of that evolution is that it will be no clumsier than Java
(though it is hard to really project the result, and our mileage may differ
:-).



--marcs