On Sat, Feb 13, 2010 at 11:29 PM, Lukas Renggli
<renggli@gmail.com> wrote:
>>> It is interesting to note that of course, after this was added to 3.9, there was
>>> someone *very hard* arguing that adding Pragmas was a very dumb idea...
>>>
>>> Who that person was is left as an exercise to the reader of course ;-)
>>
>> Hint: FFI has its own proprietary hardcoded pragma format. It
>> unnecessary complicates the compiler even when not loaded. Not to
>> mention that it breaks all tools that have their own parser, such as
>> RB for example.
>>
>
> I'd like to discuss, what changes to compiler we may introduce to allow FFI
> to handle pragmas in non-intrusive manner.
> I suppose something, like registration mechanism for compiler, where
> any external package can
> register and provide own handler(s) for pragmas.
> Then, of course, an Encoder should have a public API, which would
> allow such handlers to add/change literals
> and method header.
>
> We already having at least another use of pragmas - preferences. It's
> also could use same mechanism which can
> be used to notify a preferences system about appearance of new or
> removal existing preferences as a result of method compilation.
In fact we had that in Squeak 3.9 and early Pharo versions. I even
wrote code that adapted this mechanism for FFI, but the FFI maintainer
insisted on sticking with his compiler hacks.
The idea was that you could add methods with a specific pragma to one
of the compiler classes (I don't remember which one). There was also
one such method for each of the Smalltalk primitives currently
supported (#primitive:, 3primitive:module:, ...). When encountering a
pragma in the source code the compiler would check if this was a
compiler-pragma with the same name defined and perform that method. In
the case of the primitive the compiler would change the compile method
to use the configured primitive. A very strait forward use of pragmas.
However the functionality that made compiler pragmas and primitives
extensible is gone today even in Pharo. For reasons unknown to me
Eliot removed all the code when he added the closure support. Back to
hacking and patching the compiler.
Sorry, Lucas! �This was because I started the closure work in a Qwaq^H^H^H^HTeleplace image that lacked the pragma extensibility. �So when it came to port the Closure compiler to other dialects I a) didn't notice the extensibility stuff and b) overwrite it.
I am *very much* in favour of pragma extensibility. �Look at what we did in VisualWorks (of which you're probably aware), where the pragmas that are compilable in a class are defined by pragma methods on the class side. �We use pragma methods to introduce pragmas so that pragmas added in different packages don't collide in a single class-side pragma method.
So what to do? �Please point me to/email me a change set of the pragma extensibility code and I will try to integrate it back into the closure compiler as soon as time allows.
Apologies.
Eliot