Redeclaration of common keyword fields in ADTs as non-common keyword fields

[sungshik]

Describe the bug

There are inconsistencies in how the typechecker and interpreter handle redeclaration of common keyword fields in ADTs as non-common keyword fields.

To Reproduce

Typechecker:

data Foo = foo(int x = 1, int x = 5);  // Error: "Double declaration of field `x`"
data Bar(int x = 1) = bar(int x = 5);  // No error
data Baz(int x = 1) = baz(str x = ""); // No error

Interpreter:

rascal>data Foo = foo(int x = 1, int x = 5);
ok
rascal>foo().x
int: 5
rascal>data Bar(int x = 1) = bar(int x = 5);
ok
rascal>bar().x
int: 1
rascal>data Baz(int x = 1) = baz(str x = "");
io.usethesource.vallang.exceptions.RedeclaredKeywordParameterException: Keyword parameter x was declared earlier as int

Expected behavior

In general, after discussing it with @DavyLandman and @rodinaarssen, I would expect the following rules:

1. Redeclaring a non-common keyword field as a non-common keyword field is forbidden.
2. Redeclaring a common keyword field as a non-common keyword field with the same type is allowed (to change the default).
3. Redeclaring a common keyword field as a non-common keyword field with a different type is forbidden.

Applied to the examples above:

• The compiler and interpreter should report errors for Foo. The interpreter doesn't do this yet.
• The compiler and interpreter should not report errors for Bar, and the defalut should be 5. The interpreter doesn't do this yet.
• The compiler and interpreter should report errors for Baz. The typechecker doesn't do this yet.

[sungshik]

Hi @jurgenvinju, what do you think about this?

[jurgenvinju]

Hi @sungshik

Yes indeed. Redeclaration of a common keyword field as a non-common keyword field is an important feature that allows one to specialize the default.

For example:

// this defines the contract for all ErrorMessages
data ErrorMessage(Severity severity=info(), loc src = |unknown:///|, str message = "<toAllCaps(getName(severity) )> something happened", ErrorMessage cause = spontaneous())
   = spontaneous();

// here we override selected common keyword parameters
data ErrorMessage
    = unexpectedType(Type got, Type expected, Severty severity=error(), str message = "Expected <expected> but got <got>")
    | divideByZero(Severity severity=fatal(), str messages  = "division by zero")
    ;

This is the way to create lazily computed and fields based on local information (like got and expected are used in message). Similar to synthesized attributed in AG systems.

[jurgenvinju]

About the different type, we should have a small conversation.

We can not write function types with keyword fields yet. But we will soon:

// proposed syntax for a function/constructor type with a keyword field 
myADT (int age = ...): 

The default is not present in the type, since that is a property of a function instance (not abstract). This guarantees uniques of default expressions (very important).

When we pass a function such a type as a parameter, we get the Haskell way of sub-typing (according to B. Liskov's substitution principle:

myADT (num age) <: myADT (int age)

So the parameter type is contra-variant.

It is important to have the same sub-typing rules for functions as for constructors, because a constructor is always ready to play the role of a function in Rascal.

Conclusion: contra-variance should be allowed between common keyword parameters and non-common keyword parameters with the same name.

[jurgenvinju]

Not having first-class keyword parameter types yet makes this more complex than it should be. Suddenly all kinds of corner cases appear, while a first-class keyword parameter in the function type could deal with all these cases through asubtype and alub.

• afunc already has room for keyword parameter types, but does not implement contra-variance
• FunctionType in the interpreter does not handle keyword parameter types
• acons exists in the type checker, but really that is an alias for afunc. It would help if we no longer treat constructor functions as a special case. This is only possible if we use keyword parameters consistently for afunc as well.
• note that for normal parameters, afunc is variant: both co-variant and contra-variant to allow for pattern matching semantics.