Hi Clement, I have done exactly this a long time ago. I went even further, allowing different methods being written in different languages (so one could have a class with one method in Smalltalk, other in Java, third in JavaScript, fourth in Ruby or even LISP)
Now, fiddling with parser/compiler was actually the easiest part. The hard (though not "difficult") part was to make it working so one can commit and load back the package smoothly, senders / implementors work as expected, debugger is not confused, inspector still works and uses the right compiler for the object, changes are written properly and could be actually loaded back. Myriads of little details... And yes, as soon as "the other language" semantics differ from Smalltalk, you expose yourself to a number of interoperability issues, depending how much different it is. Some of these problems are easy, some of them tricky. Most of them tricky :-) So better stick to Smalltalk semantics... And what is the worst :-) even if you manage to make it up and running, then only to find out that "ordinary" programmers don't like it. They want only one language to rule them all. How many times I have heard "I don't like programming in this or that, I want program everything in Smalltalk (substitute for your favorite)". So, be prepared. If you'd still give it a go, I'd be happy to discuss details. My 2 cents. Jan On Tue, 2015-08-04 at 10:08 +0200, Clément Bera wrote: > Hello Pharoers, > > I'd like to do something a bit crazy and I think it's possible in > Pharo so I'm asking for advises here. > > I would like to have packages / hierarchy of classes in Pharo that > have methods written with a different syntax. > > I know that syntax coloring and most refactoring tools work on AST. > So is it possible, for a given class, to override #parser or > #parserClass class side in a similar way that you can override > #compiler and #compilerClass, and from then on, the class methods > will use this parser instead of RBParser to be parse its methods > source code to the AST in the compilation chain and for syntax > coloring (hence with full compatibility with the class browser) ? > > I am talking about another syntax that would be parsed to the same > AST for now, though as the compiler can be changed too, I guess a > complete separate compilation chain and AST could work fine if the > AST has common APIs with RB for the refactoring browser and syntax > coloring. > > What do you think ?
