ChildsplayOSU / bogl

Haskell implementation of the BoGL language
https://bogl.engr.oregonstate.edu
BSD 3-Clause "New" or "Revised" License
7 stars 1 forks source link

Issue with extending Tuples #169

Open montymxb opened 3 years ago

montymxb commented 3 years ago

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.

MartinErwig commented 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