I would love to have one compilerContext object so that we do not have
to
pass all these parameters plague
It would be nice to have
compile: 'text' context: (aCompilerContext)
aCompilerContext
in: aClass ;
silently: true ;
inCategory: 'zork'
But this is something we should do after :)
On Mar 4, 2009, at 10:59 AM, Lukas Renggli wrote:
> Hi Jorge,
>
> great to hear. I have two things that I wish you add to your list:
>
> 1. My first wish also affects the old compiler, but that should be
> easy to fix in Pharo. Currently there are dozens of selectors in
> Behavior that hardcode the currently used compiler #parseClass,
> #compilerClass, #evaluatorClass, #decompilerClass,
> #subclassDefinerClass, ... I would prefer to have exactly one entry
> point, for example under the name #compiler. This object could act
> like a compiler MOP on the receiving class and set through a
> preference for all classes of the system that do not override this
> method themselves. This would make it much cleaner to have different
> compilers in the image, swap them on the fly, get rid of various hacks
> and overrides and even allow to unload the old compiler.
>
> 2. My second wish is only about the new compiler. One thing stroke me
> when working on transactional memory and domain specific languages, is
> that the new compiler isn't as extensible as it advertises. The
> problem is there is no central place where the different phases
> (parsing, annotation, bytecode generation) of the compilation is
> triggered. Currently this happens at various places throughout the
> system. This has not only the problem that extending the compiler is
> difficult without patching it, but also makes it nearly impossible to
> get certain information at a particular place of the process. For
> example, during parsing it is not know in what class the method is
> supposed to be compiled, or during bytecode generation I don't know
> the source code anymore, etc. I suggest to introduce a compilation
> context, that is accessible anywhere and that can pass necessary
> information through the compilation phases. Furthermore I suggest to
> implement the delegation to the different parts of the compiler in a
> deticated object that can be subclassed and used for example if
> somebody wants to cleanly replace, customize or extend certain parts
> of the compiler.
>
> Cheers,
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
