Open montymxb opened 3 years ago
On Nov 13, 2020, at 12:57 PM, Benjamin Wilson Friedman notifications@github.com wrote:
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.
This is a good point. I think const could be compiled and should run well when applied to pairs, and it should result in a runtime error when applied to Nothing. It's basically similar to Haskell incomplete pattern errors.
-- Martin
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 ifT
was properly extended, but in the case of passingNothing
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 ofNothing
with no way to check this.