> > Note 1: I see the pragma selector as a message that can be sent to an
> > object to configure it somehow, binary selectors usually have a
> > slightly different meaning.
>
> I don't get that.
> Which object is #primitive: sent to, and how does it configure it?

No problem, you are not the only one :-(

After the compilation the message #primitive: with the given arguments
is performed on the parser. This is then changing the current method
to be a primitive. It works the same for #primitive:module: where
there is just slightly different code executed. Have a look at the
implementors of those two messages in a 3.9 image.

Now, how do I know what pragmas I should perform on the parser and
what pragmas not? It is hardcoded right now, but that could be solved
nicely as I suggested in my original mail that caused all this
discussion. So the parser-class could then declare some of its methods
(namely #primitive: and #primitive:module:, and also #apicall:module:
and #cdecl:module: if the FFI people would accept) as methods to be
called after the compilation. Very extensible. Very modular. Very much
oop. And no patching.

> > Note 2: It would be easy to allow pragmas like this <* 6>, <,
> > 'world'>, basically one line of code that needs to be updated.
>
> I would have thought that <* 6> would also need to be written < * 6> , in order
> to parse correctly? Anyway. What you are saying is that it's easy to allow
> binary selectors?

Yes you are right. #<* would probably be parsed as a binary selector
as well, I am not that much aware what exactly is considered a binary
selector in Squeak. I guess with spaces that would be fine. It is a
similar problem as they have in C++ with their nested template
declarations ;-)

If the community likes to have pragmas with a binary selector I can do
that. Users have to make sure that they put a space upfront.

> > I published it to http://source.squeakfoundation.org/inbox, please
> > have a look. The tests do all run, I only changed one method that does
> > the parsing of the selector. The correction algorithm is the same as
> > the one used to correct selectors of normal message sends in your
> > code.
>
> Thanks.
> I've had a look, and it works great.

Great, then we should maybe include it in the next version. It is only
a small change (to be clear: it adds a feature for the interactive
compiler mode, it doesn't change anything else). How to proceed?
Should I submit to Mantis? How does that work as 3.9 gamma is out now?

Cheers,
Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch