
The Rascal Metaprogramming Language - nerdponx
http://www.rascal-mpl.org/
======
bdamm
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.

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

~~~
jurgenv
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.

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

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

~~~
ashton314
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… ¯\\_(ツ)_/¯

~~~
seanmcdirmid
> 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.

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

~~~
seanmcdirmid
Very diverse.

------
IlegCowcat
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.

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

~~~
Darmani
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.

~~~
erezsh
How is GLR more general than CFGs?

~~~
jurgenv
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.

------
rs23296008n1
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.

------
Quipunotch104
OMeta was here

------
skissane
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.)

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

------
misterdoubt
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.

~~~
jurgenv
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.

