I start to work to resurrect Helvetia some months ago by starting with QuasiQuote:
http://smalltalkhub.com/#!/~SergeStinckwich/Helvetia/ but I was distracted by other tasks. I'm still interested to made progress here. I will have a look when I came back from my hollidays. Sent from my iPhone > On 4 août 2015, at 17:01, Tudor Girba <[email protected]> wrote: > > 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"
