Feature request for Opal

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

Feature request for Opal

Igor Stasenko
I want an API for easy plugging in an arbitrary pragma handler,
which could then either completely intercept parser/compiler output or
modify output.

This is userful for things like clean implementation of FFI pragmas,
without patching the Parser
as well as for scenarios like:

myMethod: myArg
<myLanguage>

foo|<bar**baz


so, once pragma  <myLanguage> parsed, and handled, an input source
stream redirected to completely different parser/compier
pair which, of course, should produce a compiled method as a result,
but may use any syntax.



--
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: Feature request for Opal

Lukas Renggli
What you ask for was present in my original pragma implementation. The
compiler dispatched pragmas that were declared as compiler pragmas
(using pragmas and thus extensible) to the compiler.

That mechanism got lost with the closure changes to the compiler. It
should be relatively easy to re-integrate again.

I never bother to do so, because the mechanism was never adopted by
the only potential client at that time as the author didn't like
pragmas and preferred to patch the compiler :-)

Lukas

--
Lukas Renggli
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: Feature request for Opal

Stéphane Ducasse
In reply to this post by Igor Stasenko
> What you ask for was present in my original pragma implementation. The
> compiler dispatched pragmas that were declared as compiler pragmas
> (using pragmas and thus extensible) to the compiler.

as it should be done.
Nice music to my hears.
>
> That mechanism got lost with the closure changes to the compiler. It
> should be relatively easy to re-integrate again.
>
> I never bother to do so, because the mechanism was never adopted by
> the only potential client at that time as the author didn't like
> pragmas and preferred to patch the compiler :-)

May be jealous not to have invented it?
;-)


Stef



_______________________________________________
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: Feature request for Opal

Alexandre Bergel
In reply to this post by Igor Stasenko
Cool idea

Alexandre

On 28 Sep 2010, at 03:30, Igor Stasenko wrote:

> I want an API for easy plugging in an arbitrary pragma handler,
> which could then either completely intercept parser/compiler output or
> modify output.
>
> This is userful for things like clean implementation of FFI pragmas,
> without patching the Parser
> as well as for scenarios like:
>
> myMethod: myArg
> <myLanguage>
>
> foo|<bar**baz
>
>
> so, once pragma  <myLanguage> parsed, and handled, an input source
> stream redirected to completely different parser/compier
> pair which, of course, should produce a compiled method as a result,
> but may use any syntax.
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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: Feature request for Opal

Eliot Miranda-2
In reply to this post by Lukas Renggli
Hi Lukas,

On Tue, Sep 28, 2010 at 12:46 AM, Lukas Renggli <[hidden email]> wrote:
What you ask for was present in my original pragma implementation. The
compiler dispatched pragmas that were declared as compiler pragmas
(using pragmas and thus extensible) to the compiler.

That mechanism got lost with the closure changes to the compiler. It
should be relatively easy to re-integrate again.

Please do.  This is the way it should be done and I'm sure would be very nice to use.  It would give me pleasure to review the code. 


I never bother to do so, because the mechanism was never adopted by
the only potential client at that time as the author didn't like
pragmas and preferred to patch the compiler :-)

Lukas

best
Eliot
 

--
Lukas Renggli
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: Feature request for Opal

Lukas Renggli
Thanks Eliot, I will look into it. I should have some time this week.

Lukas

2010/9/28 Eliot Miranda <[hidden email]>:

> Hi Lukas,
>
> On Tue, Sep 28, 2010 at 12:46 AM, Lukas Renggli <[hidden email]> wrote:
>>
>> What you ask for was present in my original pragma implementation. The
>> compiler dispatched pragmas that were declared as compiler pragmas
>> (using pragmas and thus extensible) to the compiler.
>>
>> That mechanism got lost with the closure changes to the compiler. It
>> should be relatively easy to re-integrate again.
>
> Please do.  This is the way it should be done and I'm sure would be very
> nice to use.  It would give me pleasure to review the code.
>>
>> I never bother to do so, because the mechanism was never adopted by
>> the only potential client at that time as the author didn't like
>> pragmas and preferred to patch the compiler :-)
>>
>> Lukas
>
> best
> Eliot
>
>>
>> --
>> Lukas Renggli
>> 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
>



--
Lukas Renggli
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: Feature request for Opal

Lukas Renggli
Ok, the change was rather trivial, most of the functionality was still there.

I committed

  Name: Compiler-LukasRenggli.242
  Author: lr
  Time: 29 September 2010, 8:29:05 am
  UUID: 5e237cdd-b72f-44ae-a6c9-402623dfb670
  Ancestors: Compiler-MarcusDenker.241

  - use pragmas to make primitives extensible

to the Pharo inbox and the issue tracker
(http://code.google.com/p/pharo/issues/detail?id=3014). Image
recompiles without problems. Same tests fail as before.

For the other Smalltalk that use the same infrastructure I've attached
a change-set.

Lukas

On 28 September 2010 18:29, Lukas Renggli <[hidden email]> wrote:

> Thanks Eliot, I will look into it. I should have some time this week.
>
> Lukas
>
> 2010/9/28 Eliot Miranda <[hidden email]>:
>> Hi Lukas,
>>
>> On Tue, Sep 28, 2010 at 12:46 AM, Lukas Renggli <[hidden email]> wrote:
>>>
>>> What you ask for was present in my original pragma implementation. The
>>> compiler dispatched pragmas that were declared as compiler pragmas
>>> (using pragmas and thus extensible) to the compiler.
>>>
>>> That mechanism got lost with the closure changes to the compiler. It
>>> should be relatively easy to re-integrate again.
>>
>> Please do.  This is the way it should be done and I'm sure would be very
>> nice to use.  It would give me pleasure to review the code.
>>>
>>> I never bother to do so, because the mechanism was never adopted by
>>> the only potential client at that time as the author didn't like
>>> pragmas and preferred to patch the compiler :-)
>>>
>>> Lukas
>>
>> best
>> Eliot
>>
>>>
>>> --
>>> Lukas Renggli
>>> 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
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>


--
Lukas Renggli
www.lukas-renggli.ch

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

3014-UsePragmasForExtensiblePrimitives.1.cs (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Feature request for Opal

Stéphane Ducasse
In reply to this post by Lukas Renggli
Thanks!
Marcus was fast on this one. Already in the box :)
On Sep 29, 2010, at 8:34 AM, Lukas Renggli wrote:

> Ok, the change was rather trivial, most of the functionality was still there.
>
> I committed
>
>  Name: Compiler-LukasRenggli.242
>  Author: lr
>  Time: 29 September 2010, 8:29:05 am
>  UUID: 5e237cdd-b72f-44ae-a6c9-402623dfb670
>  Ancestors: Compiler-MarcusDenker.241
>
>  - use pragmas to make primitives extensible
>
> to the Pharo inbox and the issue tracker
> (http://code.google.com/p/pharo/issues/detail?id=3014). Image
> recompiles without problems. Same tests fail as before.
>
> For the other Smalltalk that use the same infrastructure I've attached
> a change-set.
>
> Lukas
>
> On 28 September 2010 18:29, Lukas Renggli <[hidden email]> wrote:
>> Thanks Eliot, I will look into it. I should have some time this week.
>>
>> Lukas
>>
>> 2010/9/28 Eliot Miranda <[hidden email]>:
>>> Hi Lukas,
>>>
>>> On Tue, Sep 28, 2010 at 12:46 AM, Lukas Renggli <[hidden email]> wrote:
>>>>
>>>> What you ask for was present in my original pragma implementation. The
>>>> compiler dispatched pragmas that were declared as compiler pragmas
>>>> (using pragmas and thus extensible) to the compiler.
>>>>
>>>> That mechanism got lost with the closure changes to the compiler. It
>>>> should be relatively easy to re-integrate again.
>>>
>>> Please do.  This is the way it should be done and I'm sure would be very
>>> nice to use.  It would give me pleasure to review the code.
>>>>
>>>> I never bother to do so, because the mechanism was never adopted by
>>>> the only potential client at that time as the author didn't like
>>>> pragmas and preferred to patch the compiler :-)
>>>>
>>>> Lukas
>>>
>>> best
>>> Eliot
>>>
>>>>
>>>> --
>>>> Lukas Renggli
>>>> 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
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> <3014-UsePragmasForExtensiblePrimitives.1.cs>_______________________________________________
> 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