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
-XNoImplicitForAll
, -XNoPatternSignatureBinds
#285
Conversation
Removed comma
A few minor remarks:
|
Done
That as my intent. Maybe I should re-title it?
Mmm, I prefer extensions to be monotonic where possible. Also this made me think some teachers may which to prevent polymorphism altogether with |
With Should |
I think |
This would be the first precedent where a People using a Dependent Haskell kitchen sink likely already have
|
Isn't |
I meant "enables a different extension". AFAIK |
Ah, so it's an argument against |
Thanks @neongreen, you made my "Mmm, I prefer extensions to be monotonic where possible" a lot clearer. |
@monoidal great point, I also forgot data declarations. |
OK added something about instances and also data types. I am not sure what to do about classes; that is now an unresolved question. I am also being very conservative about variables in signatures in patterns, perhaps moreso than people would like. |
What is special about classes? They are the same as data types. So, for your example,
There are two ways to rewrite it:
|
@int-index Yeah I feel better now. @int-index @rae so the overly-conservative thing was that in other proposals places we say a type signature in a pattern binds a variable that is unified (it is fresh "syntactically" but not "semantically"). I don't want to fight against that completely, but I rather there at least be a way to opt-out of it. I've written this proposal such that you'd have to opt in if you have |
I generally prefer fewer implications among extensions -- fewer implications means that I have less to remember. And an implication from a |
…ForAll` This feature is not yet implemented, but @goldfirere realized in ghc-proposals#452 it was not explicitly covered. @aspiwack thought perhaps it was simple enough that we could do as a separate PR against the existing proposal, and I thought that sounded reasonable so I am opining this. Note that ghc-proposals#448 has good positive effects with this change, but I think it is OK in this case to serve this change alone and ignore the larger context. It's a "bug fix" that stands alone, and spooky good effects downstream can merely be icing on the cake, to discuss in ghc-proposals#425's motivation / effects and interactions sections.
…ForAll` This feature is not yet implemented, but @goldfirere realized in ghc-proposals#452 it was not explicitly covered. @aspiwack thought perhaps it was simple enough that we could do as a separate PR against the existing proposal, and I thought that sounded reasonable so I am opining this. Note that ghc-proposals#448 has good positive effects with this change, but I think it is OK in this case to serve this change alone and ignore the larger context. It's a "bug fix" that stands alone. When Spooky effects downstream are bad, we shouldn't do this, but then they are good, as I believe is the case with the broader ghc-proposals#425 plan, we can safely leave them be discussed in ghc-proposals#425's motivation / effects and interactions sections.
…ForAll` This feature is not yet implemented, but @goldfirere realized in ghc-proposals#452 it was not explicitly covered. @aspiwack thought perhaps it was simple enough that we could do as a separate PR against the existing proposal, and I thought that sounded reasonable so I am opining this. Note that ghc-proposals#448 has good positive effects with this change, but I think it is OK in this case to serve this change alone and ignore the larger context. It's a "bug fix" that stands alone. When spooky effects downstream are bad, we shouldn't do this, but then they are good, as I believe is the case with the broader ghc-proposals#425 plan, we can safely leave them be discussed in ghc-proposals#425's motivation / effects and interactions sections.
…ForAll` This feature is not yet implemented, but @goldfirere realized in ghc-proposals#452 it was not explicitly covered. @aspiwack thought perhaps it was simple enough that we could do as a separate PR against the existing proposal, and I thought that sounded reasonable so I am opining this. Note that ghc-proposals#448 has good positive effects with this change, but I think it is OK in this case to ignore that for now. This is a "bug fix" that can stand alone. When spooky effects downstream are bad, we shouldn't do this, but then they are good, we can safely leave them be discussed later, in this case in ghc-proposals#448's motivation / effects and interactions sections.
…ForAll` This feature is not yet implemented, but @goldfirere realized in ghc-proposals#452 it was not explicitly covered. @aspiwack thought perhaps it was simple enough that we could do as a separate PR against the existing proposal, and I thought that sounded reasonable so I am opining this. Note that ghc-proposals#448 has good positive effects with this change, but I think it is OK in this case to ignore that for now. This is a "bug fix" that can stand alone. When spooky effects downstream are bad, we shouldn't do this, but then they are good, we can safely leave them be discussed later, in this case in ghc-proposals#448's motivation / effects and interactions sections.
It came to my attention this morning (by @lexi-lambda and @tek) that I missed an aspect of this proposal. The Proposed Change Specification refers only to implicit scoping of variables in type signatures and in pattern signatures. But the examples include things like the scoping of To me, the text in the Proposed Change Specification defines the payload of a proposal. Thus, acceptance of this proposal has no effect on This leads to two questions:
|
It's been a while, but I recall I purposefully kept the list of items out of the proposed change and in examples because I assume I would miss one :). The normative part assumes "pattern signatures" was well-defined enough to include it and perhaps that was a mistake. The |
in particular, {-# LANGUAGE WhateverIsNeededForBraveUnifiedNamespace #-}
k = Type
data T (a :: k) -- captured now nicely illustrates all the issues following from the violation principle (in your proposal) are at play, so I would like to be able to fix that. |
probably sensible to link the implementation MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8629 |
It helped to see the place where this came up: I left https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8629#note_444076 and so "cross posting" that here. IMO the confusion stems from the fact that #425 is the one type variable proposal not to be subsumed into #448. I suggest we subsume it too; we need a unified spec that gets rid of all the silly semantic drift between things which ought to work the same way. |
The proposal has been accepted; the following discussion is mostly of historic interest.
Provide a way to opt out of implicit
forall
binding of free variables in type signatures. Compliments the unified namespace proposal (#270) by making all bindings usable in type signatures.Rendered