Helvetia in Pharo?

Hello Doru

On 3/2/17, Tudor Girba <[hidden email]> wrote:
.....
> That said, I do want to have mechanisms that allow us to embed other
> languages and DSLs in our environment. In this area I prefer the approach
> put forward by Helvetia because it is not invasive and highly flexible (and
> now should even not be expensive to have anymore).

Just wondering what you mean by this.
Could you please elaborate a bit what you mean that it would now be
less expensive to have a Helvetia system in Pharo? The last time it
was implemented was in Pharo 1.1.2 **

Regards
Hannes

**http://scg.unibe.ch/research/helvetia

Hi,

Helvetia requires a couple of things:
- Flexible parsing. Lukas built PetitParser for this and now PetitParser2 is even faster and more powerful (for example, with bounded seas parsing) while preserving the same flexibility.
- Flexible compilation toolchain. At the time, Lukas employed a significant amount of overrides. Now we have Opal which makes this step easier.
- Moldable development tools. GT was designed with moldability in mind so at least the debugging part should be easier to handle. We still need work in the area of syntax highlighting, completion and editing.

Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

On Thu, Mar 2, 2017 at 8:51 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> Helvetia requires a couple of things:

BTW, with Nick Papoylias we have a working version of Helvetia for
Pharo 5.0/Moose 6.0 here:
https://github.com/UMMISCO/Helvetia

We have the permissions of Lukas Renggli and Oscar Nierstrasz to port
Helvetia to recent versions of Pharo.

We are using Helvetia for our own research about Domain-Specific Languages
for complex system especially in the context of the Kendrick DSL for
epidemiology: https://ummisco.github.io/kendrick/

> - Flexible parsing. Lukas built PetitParser for this and now PetitParser2 is even faster and more powerful (for example, with bounded seas parsing) while preserving the same flexibility.
> - Flexible compilation toolchain. At the time, Lukas employed a significant amount of overrides. Now we have Opal which makes this step easier.

This has been the most difficult part of the port because the API
change a lot since the PhD of Lukas :-)
At the moment, the modifications that we have done are still a little
bit hackish and more integration with Opal has to be done in the
future.

> - Moldable development tools. GT was designed with moldability in mind so at least the debugging part should be easier to handle. We still need work in the area of syntax highlighting, completion and editing.


We will move soon the code on github so people could send pull requests.

Regards,
--
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/