Re: [Help-smalltalk] Improving the Convert.st and RB*

[Paolo Bonzini]

Il 29/09/2012 07:29, Holger Hans Peter Freyther ha scritto:
> Hi Paolo,
> 
> I have the first parallel development of some code in Pharo and Gst
> and would like to use the converter on a regular basis. I have some
> issues though and I would like to have your comments.
> 
> RB Rewrite rules. I tried to write a "@object ==> @object" rule but
> this fails as the RBScanner (used to parse the rewrite expression)
> does not know these long binary selectors. I patched the Squeak
> scanner a while back. So somehow I need to be able to set a scanner
> when parsing the rule

The obvious solution here is to parse up to the -> with the source
scanner, and up to the end with the destination scanner.  This gets a
bit ugly because right now Convert.st exploits the fact that -> is a
binary message, and parses a single expression.  But as a first step,
parsing with the Squeak scanner if either side is Squeak is a good idea,
and an easy patch.  You can create a SqueakParser class that inherits
from RBParser and overrides #scannerClass.

> Resolving classes and loading rules. E.g. when I ported the PetitParser
> I made the decision to change ==> to =>.  It would be nice if I
> could have <ConversionRules>FixSelectors.rules</ConversionRules> in
> my package and have this loaded by the converter, e.g. by saying
> --package PetitParser.

That's an interesting idea.  However, there is a bootstrapping problem
because you cannot create a package until you have the first conversion
complete.  You could achieve the same by a --rule-file option, which
would be easier.

> Splitting code by class name and putting extensions into an
> Extensions.st.

The difficulty here is embedded Evals, which may rely on the extensions.
 This means extensions would be loaded first.  But extensions may
actually be overrides and rely on other classes, so they have to go
last.  You could put them into an Init.st file and do them all last.
This should be a separate mode of Convert.st, perhaps even a separate
gst-split program?

Paolo