Consider the following program:
—–
module foo
imports
liblib
signature
sorts Foo
constructors
Foo: Foo
strategies

main = !0 => Foo ; !Foo
——-

This program will fail, since the term on the rhs of => cannot match 0. If we remove the Foo:Foo constructor, the program will run, and produce 0 as a result.

Since variables can start with uppercase letters, and the current module system does not support constructor hiding, existing programs can break in extremely subtle ways if somebody introduces a new constructor which overlaps with an existing variable name.

This is a case that strc can easily report as a conflict, and it should.

Submitted on 30 April 2006 at 12:44

STR-555, martin:
The problem with this issue is that there is no way to determine if the programmer intended to match against the constructor Foo or the variable Foo. Introducing this warning in the compiler will show the warning for matching against nullary constructors as well, which is probably not acceptable.

As a solution I’ve been proposing to require the use of () in a nullary constructor (i.e Foo() instead of Foo). In this way Foo is no longer ambiguous: it always refers to the variable Foo. If the () is required, then we can warn about Foo being used as the name of a variable, since this is probably still not desirable.

However, this proposal is a bit controversial, in particular because the ATerm library does not print the () by default and it is useful if you can copy ATerms printed by the ATerm library without changes into Stratego source code.

Of course, it would break existing code as well.

STR-555, karltk:
You are of course correct when you point out that this is rather tricky issue. If the sole techinical reason for not fixing this is the ATerm library, I suggest we patch the ATerm library to act properly.

If this is impossible, I’d still like to see warnings for the particular case above. No matter how you turn it around, the ambiguity between variables and nullary constructors, is positively harmful, and if we can’t fix it properly, it doesn’t help our users by hiding it, which is effectively what we’re doing by keeping the compiler silent.

If you’re worried about users getting annoyed by the warnings, perhaps we can have a -Wall like option that enable this kind of style warnings.

STR-555, martin:
I would be prefer such a fix in the aterm library and maybe the CWI guys don’t have a problem with this change (we have never proposed it). Still, we need to agree that we are going to require the (). Visser had a rather strong preference for not requiring () in the past, but he might have changed his mind.