The Rascal Metaprogramming Language | Hacker News Reader

The Rascal Metaprogramming Language

rascal-mpl.org

154 pointsnerdponx33 comments

It is a niche that needs filling for sure, but I'm concerned that the code analysis and transformation talent is going to continue in the current path, namely, spread out thinly across many environments, languages, and toolkits. What we need is not only a wonderful tool for static code analysis, generation, and transformation, but also an energetic juggernaut of a foundation to evangelize and drive adoption of it. Otherwise, talent will end up corralled in to the Eclipse SDKs of the world.

Interesting! Can anyone comment on how it fits in compared to XTRAN (http://www.xtran-llc.com/), Xtext (http://www.eclipse.org/Xtext/), or Epsilon (http://www.eclipse.org/epsilon/doc/eol/)?

Goals are often similar, but methods very different. Epsilon and Rascal share many design decisions. Rascal is based fully on immutable data, including relations, while the EMF is based on objects.

Thanks! That's exactly what I wanted to know.

Curious how people who use this find it compares to an environment like Racket?

I’d like to ask the same. Most PL research is done with Racket; I imagine this might have a steep uphill battle if it wants to gain traction. But maybe it’s target application is sufficiently specialized… ¯\_(ツ)_/¯

> Most PL research is done with Racket

A lot of PL research is done with Racket, but I doubt it is even close to being most, or even more than 1 or 2%.

As for Rascal vs Racket, they really are going after different language engineering niches.

How would you describe the distribution of languages used in PL research?

Very diverse.

I don't really know Racket. But from what i've seen, it's mostly sold as a language to create new languages in. Rascal on the other was designed to analyse existing languages. They wanted to have a single framework to analyse both Java and C++ for example. The goal was to be able to easily add new syntax and reuse semantic analysis, I believe.

I have programmed in both Rascal and Racket (for university courses). I really prefer Racket.

Though most of that might be because Rascal isn't really polished for mainstream usage. Rascal doesn't have a lot of good error messages at the moment (the most common error message you might see, is CallFailed, with just the bare minimum of information where it occured).

Another issue is how to run Rascal. Currently, you can only install it as an Eclipse plugin, and that seems to be the only way to run it.

Edit: I see that last statement is false. There is a commandline REPL. But I do not know if it works well.

Reminds me of Coccinelle - a language for writing semantic patches for C (like eg: add close_foo(fooid) in every function that has open_foo for each fooid etc...) , but I see Rascal can do some more.

Since Rascal has integrated Context Free Grammars, does this mean it incorporates the Earley Algorithm for parsing ?

Like many things from the Netherlands, it uses SGLR parsing (scannerless GLR, where GLR = generalized LR), which actually handles a class slightly more general than CFG s.

That was version 0.1 bootstrapped off SDF2. Since 2009 Rascal is based on a topdown general algorithm calked GLL. It's still Scannerless with declarative disambiguation, like SGLR. Currently it's evolving to data-dependent GLL to be able to model the offside rule, the C pre-processor and symbol table, and other "interesting" stuff we encounter in programming languages. See thesis by Afroozeh and Izmaylova.

How is GLR more general than CFGs?

GLR, GLL and Earley's parser (with the tree construction) are labeled "context-free general" parsing algorithms because they can handle _any_ context-free grammar while the other algorithms associated with sub-classes of CFGs, such as LR, LALR and LL do not implement all CFGs. In particular this comes in handy for languages which are unambiguous yet require a lot of lookahead or context to avoid parser action conflicts. The context-free general algorithms are popular among people who have to rapidly prototype languages or implement many different language processing tools without the opportunity to spend months on a parser. We pay in speed. GLR and GLL typically run nearly linearly on normal files, while Earley has a bad average case behavior which is often quadratic.

Another benefit of context-free general implementations is composability of grammars. Since CFGs are closed under composition you can implement modular grammar formalisms using a context-free general parser.

Another main drawback is that (un)ambiguity of context-free grammars is undecidable, and so prototypes generated using GLR, GLL and Earley may produce more than one tree, and in release mode you migh report an unexpected static error to your user in that case. We deal with this drawback using random testing/fuzzing and some static analysis.

I'm getting the sense that this project is building something that appears to be complete gibberish to me right now but that in 3 months time it will become absolutely important that I learn it quickly.

Bookmarked so that future me doesn't get angry at losing this.

OMeta was here

I wish they made their licensing clearer. Their website has nothing to say about this. There is no "LICENSE" file at the top-level of their main source repo, nor any discussion of licensing in their README.

Many of their actual source files have a copyright notice at the top including an EPL (Eclipse Public License) grant, so it looks like this is licensed under EPL. But they could make that fact clearer. (Also, I haven't actually checked every single source file, so there is some risk some of them might be under different license terms.)

What was developed in IBM time and what was written as Eclipse plugin is EPL. The rest is BSD2.

Situation: "many different tools, possibly even written in different languages."

Many different languages?! Ridiculous! We need to develop one universal system "for any kind of metaprogramming task: to construct parsers for programming languages, to analyze and transform source code, or to define new DSLs with full IDE support. "

Soon:

Situation: many+1 different tools, definitely written in different languages.

Working with code Analysis and transformation techniques at the same time was always about glueing database and logic progressing tech to functional programming and algebraic specification tech for us. Just having those linguistically integrated before you start thinking about a language progressing tool makes working with Rascal a lot of fun.

Reply on news.ycombinator.com