Skip to content
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

Unidirectional Coercible #198

Open
int-index opened this issue Jan 25, 2019 · 9 comments
Open

Unidirectional Coercible #198

int-index opened this issue Jan 25, 2019 · 9 comments
Labels
Dormant The proposal is not being actively discussed, but can be revived

Comments

@int-index
Copy link
Contributor

For newtypes that guarantee some invariant, we might want to coerce in one direction (unwrap) but not the other.

newtype NonNegative a = NonNegative a

coerce :: NonNegative a -> a -- safe
coerce :: a -> NonNegative a -- unsafe

Right now the only option is to not export the constructor, which makes both directions of coerce unavailable.

@nomeata
Copy link
Contributor

nomeata commented Jan 26, 2019

This has been in the back of our heads for a while. But there are a few can of worms, such as now type constructors have not only roles, but also variances....

@goldfirere
Copy link
Contributor

I agree that this would be nice, but doing it right would take at least one peer-reviewed publication, perhaps more. Indeed we would need variances, but we also need a new theory of FC/Core that can deal with non-symmetrical coercions. This would be interesting for me to pursue (and it's related to ideas I've wanted to write about), but no one should hold their breath.

@monoidal
Copy link
Contributor

Linear types could use unidirectional coerce :: (a ->. b) ->. (a -> b).

@goldfirere
Copy link
Contributor

Is this ticket achieving any goal right now? I move to close it. This won't be solved anytime soon, I don't think.

@int-index
Copy link
Contributor Author

Is this ticket achieving any goal right now?

It's a feature request.

This won't be solved anytime soon, I don't think.

If this is ground for closing, so be it. I think it's good to have it open as a reminder that this is a desired feature, but I don't feel strongly.

@goldfirere
Copy link
Contributor

goldfirere commented May 28, 2019

I actually agree with @int-index here. I will leave open and label accordingly.

(The close/open below is purely an accidental button press -- there is absolutely no intention there.)

@goldfirere goldfirere reopened this May 28, 2019
@goldfirere goldfirere added Dormant The proposal is not being actively discussed, but can be revived Needs research labels May 28, 2019
@Ericson2314
Copy link
Contributor

The axioms proposed to be removed in #274 could be added back as one-way coercions. This is better than the situations both with and without #274 because it avoids the cost and semantic change of eta-expansion.

@Icelandjack
Copy link
Contributor

Icelandjack commented Jan 20, 2020

With dependent types is there a way to somehow add a proof obligation? Taking the NonNegative example as an example, pretending Coercible has user instances:

instance Coercible (NonNegative a) a

but in the other direction.. I assume this won't make sense but it doesn't hurt to ask

instance pi (x :: a). (Num a, Ord a, x >= 0) => Coercible a (NonNegative a)

@Ericson2314
Copy link
Contributor

I like this.

One small tweak:

instance pi (x :: a). (Num a, Ord a, (x >= 0) ~ True) => Coercible a (NonNegative a)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dormant The proposal is not being actively discussed, but can be revived
Development

No branches or pull requests

6 participants