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 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. Splitting code by class name and putting extensions into an Extensions.st. any ideas or objections? holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
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 _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |