Skip to content

Add comparable typevar constraints #229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
radrow opened this issue Feb 20, 2020 · 0 comments · May be fixed by #390
Open

Add comparable typevar constraints #229

radrow opened this issue Feb 20, 2020 · 0 comments · May be fixed by #390
Labels
enhancement New feature or request

Comments

@radrow
Copy link
Member

radrow commented Feb 20, 2020

Currently all types can be combined with == and =<-like relation operators. While this works cool on ints, strings and possibly some other types, it seems to be completely useless for custom ADTs and functions. In my opinion the expression ((x, y) => x) == ((x, y) => y) shouldn't typecheck, as it may lead to hard to find bugs.
Another example: FixedTTL(x) > FixedTTL(y) works as expected comparing x > y, but if we accidentally compare FixedTTL and RelativeTTL the first one will be always greater, no matter of the arguments.

To solve this issue I propose adding qualification to typevars (similar to typeclasses, but restricted only to Ord and Eq):

// Most general type is spelled 'a. It cannot be compared and unified with generalized non-comparable typevar.
function id(x : 'a) : 'a = x

// Types that can be compared using `==` operator would have double tick before the tvar name
function neq(x : ''a, y : ''a) : bool = !(x == y)

// Types forming a linear order would require triple tick (or something else, this is starting to look ugly)
function lt(x : '''a, y : '''a) : bool = x < y
// ''a unifies with '''a
function spec_eq(x : '''a, y : '''a) : bool = x == y

The new syntax opens another way of dealing with it:

function 
  lt : 'a is ord, ('a, 'a) => bool
  lt(x, y) = x < y

I think this is the place where we could accept operator overloading. Although in situations where == can be derived automatically it is usually the best and the only solution, the < like operators can be more tricky so we could let the users define the comparison by themselves. Of course not stateful nor payable.

@radrow radrow added the enhancement New feature or request label Feb 20, 2020
@ghallak ghallak linked a pull request Jun 14, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant