To be honest, I don't think it matters what the format is.  It could
just as well be XML.  I think if we have a really good, Smalltalk
neutral revision system all "file in" work could be done with that
tool exclusively.  At that point all dependency problems, etc. are the
job of the RCS.

On 9/14/07, Damien Pollet <damien.pollet at gmail.com> wrote:
> On 14/09/2007, Peter William Lount <peter at smalltalk.org> wrote:
> > >>    Person addInstanceMethod: [firstName: aString | firstName :=
> > >> aString ].
> > >
> > > Not so easy.
> > Yes, so very easy.
> >
> > > How do you guarantee that "firstName" is in scope when the block is
> > > compiled?
> > Why would you? Smalltalk is a dynamic language.
>
> Maybe but Smalltalk also has lexical scoping, and here firstName seems
> to need some kind of dynamic scope. IMHO that's counter-intuitive. The
> semantics of Smalltalk were made to be simple, better to keep them so.
>
> When we brainstormed on Sapphire's syntax, I proposed to add a new
> literal for parsed-but-not-yet-compiled-syntax. You would then pass
> those objects to reflective methods in charge of installing that code
> in the system (and thus resolving variables and such). IMHO it's
> better to clearly distinguish between program text and actual system
> behavior.
>
> BTW I was also pushing for using an executable form for fileins:
> filing in a file would be the same making a "do it" on the file's
> contents, installing code in the system while the doit runs. Now I'm
> really not sure it's a good idea compared to a declarative syntax that
> allows tools to manipulate the code as an abstract structure without
> installing it.
>
>
> --
> Damien Pollet
> type less, do more [ | ] http://typo.cdlm.fasmz.org
>
>