Indeed, Helvetia did this and little more. For example: - it provided a way to combine multiple syntaxes within the same method - it provided complete debugging with stepping and proper highlighting
The only reason this was not productized more thoroughly at the time is that we did not have Opal. But, as we have it now, it would be really cool to have Helvetia resurrected. Especially now that, as Thierry said, we also start to have moldable tools so the tooling part becomes easier, too. @Clement: would you like to look at Helvetia and explore how feasible it is to resurrect it? Cheers, Doru On Tue, Aug 4, 2015 at 11:09 AM, Esteban Lorenzano <[email protected]> wrote: > Hi, > > AFAIK, this was Lukas phd thesis: Helvetia. > > http://scg.unibe.ch/research/helvetia > > cheers, > Esteban > > On 04 Aug 2015, at 10:48, Thierry Goubier <[email protected]> > wrote: > > Le 04/08/2015 10:08, Clément Bera a écrit : > > 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) ? > > > It depends on how the system browser is implemented, but it sounds doable. > > I would be able to do that fairly easily on AltBrowser, since commands > (all menus and shortcuts, including refactorings) are delegated to the node > you are using (i.e. the class, the method, the command) in the browser. > Syntax coloring is sort of keyed to the node (i.e. a comment node doesn't > do syntax coloring the way a method node does). > > 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. > > > No, that wouldn't work for refactoring. I believe RB apply refactorings by > source code changes, and so it would introduce the old syntax in the middle > of the new. > > If you use a SmaCC-based parser for the new syntax, then you would get > along the refactoring engine for that syntax and AST. > > Writing a syntax coloring tool from a Parser is extremely easy, > independently of the way this parser is implemented. It can be > auto-generated; I did some experiments with Usman on that, and they were > very interesting, in particular about the speed of the resulting syntax > coloring tool. > > What do you think ? > > > It is a good way to "mold" the browser, in a way. Doru, what do you think? > > Thierry > > > -- www.tudorgirba.com "Every thing has its own flow"
