New Compiler

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

New Compiler

Jorge Ressia
Hi,

Marcus Denker and myself will be working on the New Compiler for
Pharo. We have a plan draft of the steps that need to be followed in
order to get it up and running in Pharo:

1.- Write good tests for each module  parse, check, codeGen, execute
and check if works. First simple example, and then complex ones. Test
recompilation too.
2.- Performance, how long does it take compared to the old compiler.
3.- Error messages: at least like in the old compiler.
4.- Introduce Eliot's Closures.

Soon we will have a more detailed and formal list of thing to be done.

Cheers,

Jorge Ressia

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: New Compiler

Lukas Renggli
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: New Compiler

Stéphane Ducasse
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: New Compiler

keith1y
In reply to this post by Jorge Ressia
Jorge Ressia wrote:
> Hi,
>
> Marcus Denker and myself will be working on the New Compiler for
> Pharo.
And once again I ask. Why can this not be a New Compiler for everyone?
Why can it not be a "New Compiler, full stop" as a black box, that will
work for anyone who interfaces to it in a certain way?

1) I am not asking you to be backward compatible.

2) Thinking about it in this way will help you to design to be more
modular and to not make too many assumptions about the rest of the system.

3) Having a wider audience encourages documentation.

3) Additional benefits come from a wider potential deployment and testing.

4) It will benefit you to get used to the compiler being a loadable,
pluggable (unpluggable?) module. It will encourage others to code the
rest of pharo in such a way as to not tie it in to closely. You may also
architect for the Compiler being a loadable/switchable chunk that can be
swapped atomically, and reverted if things go wrong.

5) If you get the interfaces right,  others may contribute alternative
compilers within the framework.

I don't think that others understand my expectation for 3.11+ is not for
squeak to remain compatible at all costs, but to envisage a platform
that can handle big changes. Not in an evolutionary way as pharo is
doing, but in a revolutionary way such as Rio is doing.

Your announcement that you are "doing a new compiler" is exactly the
kind of revolutionary enhancement that we are eager to be able to adopt.
If you think about it, you will probably run the Pharo-old and pharo-new
alongside for a while until Pharo-new becomes ready enough to be a step
change. I believe that progress for squeak will be best made in
carefully crafted step changes, and I have fully expected new compiler
be one such change.

Marcus seems upset by the way he feels he has been treated by the squeak
community in the past. But I am not part of that past, I arrived (from
ST/X) in the 3.8/3.9 era. We are in a new phase now, that of finding
ways to embrace the progress that others make, and seeking to make use
of it.

thanks in advance

Keith



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: New Compiler

Alexandre Bergel
>> Marcus Denker and myself will be working on the New Compiler for
>> Pharo.
> And once again I ask. Why can this not be a New Compiler for everyone?
> Why can it not be a "New Compiler, full stop" as a black box, that  
> will
> work for anyone who interfaces to it in a certain way?

I am sure nobody is against getting the new compiler for Squeak or  
other dialects. However, it seems to me to be easier to achieve in  
Pharo. Again, if someone is willing to port it to other platform,  
that's great

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: New Compiler

Igor Stasenko
In reply to this post by Stéphane Ducasse
2009/3/4 Stéphane Ducasse <[hidden email]>:

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

This is something i'm already done in own implementation of parser.
I have a context object which role is to respond to such things like
silently/interactive, class etc..

> - Show quoted text -
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: New Compiler

johnmci
In reply to this post by Jorge Ressia
Please don't loose the fact that the Alien support mucks about in the  
compiler too.

On 4-Mar-09, at 12:51 AM, Jorge Ressia wrote:

> Hi,
>
> Marcus Denker and myself will be working on the New Compiler for
> Pharo. We have a plan draft of the steps that need to be followed in
> order to get it up and running in Pharo:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: New Compiler

Michael van der Gulik-2
In reply to this post by Jorge Ressia


On Wed, Mar 4, 2009 at 9:51 PM, Jorge Ressia <[hidden email]> wrote:
 

3.- Error messages: at least like in the old compiler.


I would like to see a different way of editing code: any modifications in a code pane are assumed to be unsaved changes to the source code. This means that things like "Print it" and error messages should go to a separate text pane on the UI somewhere - maybe a pop-up at the location of the error, or in a status bar, or maybe a separate list of errors/warnings like other IDEs do???

I haven't looked at the code for reporting error messages, but I'm assuming (and hoping) that the compiler just reports an error message and a character index, and the "presentation layer" does the notification?

Gulik.

--
http://gulik.pbwiki.com/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: New Compiler

Igor Stasenko
2009/3/5 Michael van der Gulik <[hidden email]>:

>
>
> On Wed, Mar 4, 2009 at 9:51 PM, Jorge Ressia <[hidden email]> wrote:
>
>>
>> 3.- Error messages: at least like in the old compiler.
>
>
> I would like to see a different way of editing code: any modifications in a
> code pane are assumed to be unsaved changes to the source code. This means
> that things like "Print it" and error messages should go to a separate text
> pane on the UI somewhere - maybe a pop-up at the location of the error, or
> in a status bar, or maybe a separate list of errors/warnings like other IDEs
> do???
>
> I haven't looked at the code for reporting error messages, but I'm assuming
> (and hoping) that the compiler just reports an error message and a character
> index, and the "presentation layer" does the notification?
>

I prefer a status line (or more complex morph) which appears at the
bottom of text area - there can be shown an error message ,  as well
as 'accept/cancel' buttons. We also could make it appear only if
source has changed.

> Gulik.
>
> --
> http://gulik.pbwiki.com/
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project