Which features of Rascal do you hate?

answered Nov 09 '11

Vadim Zaytsev
63 ● 1 ● 8

1. The longest match hack, i.e. [a-z]+ !>> [a-z] which starts to look kinda scary when [a-z] itself is a sophisticated line long twist.

2. Having to define the ADT and the grammar separately and the inability to transform one to another.

3. Typing-related errors when you have to unfold your awesome looking one-liner into a blob of code with insensible variable names just because there was this one point where the type inferred did not match the type you intended, and you could not cast there.

PS: I am deliberately posting those hated things that can and will eventually be improved ;)

answered Nov 09 '11

Vadim Zaytsev
63 ● 1 ● 8

Oh yes, the inability to “undefine” variables.

In order to check if some piece of code works, you type in something like “x = …;”, and starting from that moment, all your list comprehensions that feature “[… | x <- …]” are broken, and you will never be able to figure out the reason why.

I know one is supposed to use only comprehensible names for variables, but real world programmers tend to easily forget about that rule when prototyping… and Rascal is the language for prototyping. Or at least, it should be.

answered Nov 08 '11

Radu Mereuta
96 ● 6

1. One of the things that I don't like, is the error message: "Implementation Error... somewhere in $shell$". I know this is only an alpha version, but when I get something like this, all I can do, is to play around and maybe I get lucky and fix something that Rascal didn't like.

2. I'm not really a big fan of concrete syntax matching. I've been playing with SDF and Stratego for a while, and I find their concept of matching on AST's much more simple because after the implosion from ParseTree to AST you loose a lot of unwanted information. I know that there is the ADT in Rascal, but I don't see why I have to declare the syntax and the corresponding data types, and after I found all the bugs in my grammar, now I have to find all the bugs in my data types, and then modify both because implode is not general enough.

3. Slow(er) than SDF, but this already improved already from the previous version, and I hope it will still improve :).

answered Jan 26

Hossein
81 ● 8 ● 20

updated Jan 26

One of the things I personally found disgusting about Rascal is about when two modules M1 and M2 introduce the same name N. In such a case, at the usage-point, if you do not qualify N with either M1 or M2, Rascal won't tell you that it's confused and can't choose between M1::N and M2::N. Instead, it only silently makes its independent choice!

Imagine that Rascal chose M1::N and what you meant was M2::N. Whilst you do observe your program's malfunction in the runtime, you're left with no information whatsoever of where things went wrong! You might be lucky to narrow down the size to finally capture the unqualified instance of N usage. Or, you might keep getting a sporadic runtime behaviour, especially if the two instances have no interface difference so that at usage point you at least get a Rascal exception reporting its failure to perform your desired operation. This silently caters such a notorious genre of bugs that the compiler should have prevented so easily in the first place.