To start, this was not in the old spec for the language, but is something that is now in the current formal specification (this is related to #168 ).
Writing the following produces a type of (Int,Int) without the extension, and without an error.
type T = (Int,Int) & {Nothing}Furthermore, if this did work, there is a matter of how we can handle/distinguish a tuple value from a symbol. Take the following for example:
const : T -> T
const(x,y) = Nothing
Passing in (1,1) could work if T was properly extended, but in the case of passing Nothing we have an issue with the extra parameter y for unpacking the tuple. This could be rectified with a single arg, and tuple projection, but now we have an issue of determining the base type of the underlying value, as projections will fail on a value of Nothing with no way to check this.
To start, this was not in the old spec for the language, but is something that is now in the current formal specification (this is related to #168 ).
Writing the following produces a type of
(Int,Int)without the extension, and without an error.Furthermore, if this did work, there is a matter of how we can handle/distinguish a tuple value from a symbol. Take the following for example:
Passing in
(1,1)could work ifTwas properly extended, but in the case of passingNothingwe have an issue with the extra parameter y for unpacking the tuple. This could be rectified with a single arg, and tuple projection, but now we have an issue of determining the base type of the underlying value, as projections will fail on a value ofNothingwith no way to check this.