[E-Lang] down with 'define'

[Karp, Alan]

MarcS wrote:

> emakers in zip/jar files

Since E isn't Java, shouldn't we be talking about "ear" files?

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

> -----Original Message-----
> From: Marc Stiegler [mailto:marcs@skyhunter.com]
> Sent: Tuesday, March 06, 2001 8:55 AM
> To: Ralph Hartley; Mark S. Miller
> Cc: e-lang
> Subject: Re: [E-Lang] down with 'define'
> 
> 
> > 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
> 
> 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>