Consider the following piece of code:
data Val = lam(str arg, Exp body)
| let(list[Binding] bindings, Val v);
data Exp = val(Val v)
| var(str name)
| app(Exp e, str x)
| let(list[Binding] bindings, Exp exp)
| seq(Exp e1, Exp e2);
data Binding = binding(str name, Exp exp);
public Exp normalise(let(bs, e)) {
switch (normalise(e)) {
case let(bbs, ee): return let(bs + bbs, ee);
case _: return let(bs, e);
}
}
public default Exp normalise(e) = e;
Guess what do I get when I try to load it:
rascal>import ExpAbstractSyntax;
project://Hossein/src/ExpAbstractSyntax.rsc:17,21: value(...) is not allowed in patterns
My first guess was that Rascal fails to deduce types for the overloads and thinks they are values! So, I changed the first overload to public Exp normalise(Exp let(bs, e)), and guess what? I got an even more confusing error message:
rascal>import ExpAbstractSyntax;
project://Hossein/src/ExpAbstractSyntax.rsc:17,21: Exp(...) is not allowed in patterns
And, as some of you might have guessed, the problem is that I have two type constructors with the same label. I take it that the Rascal team is too busy with more important matters at the moment that they can't specifically focus on improving error reporting. But, is employing a few Masters students to sweep such trivial cases that difficult?
A constructive recommendation here for the Rascal community is to collect all the misleading error messages they encounter centrally and someone will hopefully take care of them anon. I myself have a couple of more which I'll submit ASAP.
Yes, we should improve this message (and many others).
The answer to solving this particular issue is to use a qualified constructor name:
public Exp normalise(Exp::let(bs, e)) { ... }
My third example of misleading Rascal error messages is when a circular module dependency is created. Here is the demo:
module M1
import String;
import M2;
data ADT = adt_label(str s);
module M2
import M1;
public ADT f() = adt_label("");
module M3
import M1;
import M2;
rascal>import M3;
project://.../src/M2.rsc:5,7: Undeclared type: ADT
M1 and M2 obviously have a circular dependency. The error message, on the other hand, wrongly says it cannot find ADT.
Again, I would flag this a bug rather than a misleading error message. Don't you think that this should just work?
JurgenVinju (Jan 30)editcircular dependency is allowed when importing in Rascal. This is to facilitate modular language definition, such a for example C: cohesion in separate expression and statements modules is so high, that some circular coupling between modules is warranted and we want to separate them.
JurgenVinju (Apr 02)editHere is another instance of confusing error messages Rascal emits:
Let's say that I have a pivotal ADT named A in a module M with several other modules like M1, M2, ... importing it and making use of A. If I update A and close its file, upon any further use of the contents in M1 or M2, I will receive an error message saying something like: "No such module M"! This is despite the fact that M is (and used to be a recognised) module in the project.
I understand that this happens because the object code previously produced for M -- which is now outdated -- doesn't live up-to-date with the modifications in the source code. As a result, I have come to know that I need to manually reimport M and all the way down in the import reference tree to M1, M2, ... to get the entire project updated. I have also come to know that refreshing the project would not do in most cases. Anyway, the most important point here is that the error message is very misleading and totally unhelpful.
Sounds like a bug to me. Why would the module be unavailable? all that I can come up with for now is that it has a syntax error in or something to make it unavailable. Would love a small example to check this out...
JurgenVinju (Jan 30)editAsked: Jan 03
Seen: 26 times
Last updated: Jan 24
Copyright CWI, 2010-2012. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Hi Hossein. Yes, this one is particularly annoying. Master students are not the answer here unfortunately. What we need is a "static checker" that can produce proper error messages. The current error messages are produced in a dynamic fashion at eval-time with not much information about context.
JurgenVinju (Jan 05)editA full-blown static checker sounds great but it's a much bigger task which I get the impression that the Rascal development team is not currently prepared for. Sweeping such trivial cases though seems doable using local patches for now. And, the static checker will hopefully arrive anon... :)
Hossein (Jan 05)edit