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
Control what sort of entity a deprecated pragma applies to #167
Conversation
I think Not against this proposal, but I'm wondering if we could reuse haddock syntax for this. For example, in Haddock syntax we can annotate constructor or the type without ambiguity: -- | Type documentation
data Foo =
-- | Constructor documentation
Foo x so why not something like -- | DEPRECATE: This type is deprecated
data Foo =
-- | DEPRECATE: This constructor is deprecated
Foo x Perhaps as a solution to this problem we can ask people to use haddock syntax, and then deprecate the Just an idea. |
I note that a module deprecation is positional. One says (I think)
One could do the same for data constructors, thus
or in GADT syntax
This positional story works well when the deprecation is attached to the definition of the thing. If you want to import something, deprecate it, and re-export it, it would not work so well. But (I think) we can't do that anyway today. |
After reading this proposal, it seems like this is limited in scope to disambiguating prefix type constructors from prefix data constructors. But what about the following scenario? module A where
type a <+> b = ...
(<+>) :: Int -> Int -> Int
a <+> b = ...
{-# DEPRECATED (<+>) "Don't use (<+>)" #-} It's unclear which The reason I'm picking this nit is because there is a separate, previously accepted proposal (Require namespacing fixity declarations for type names and Sorry for continuing to bikeshed about this name even more, but at the very least I'd like this proposal to be consistent with the other proposal (even if we end up changing the other proposal to use |
Thank you for all your comments! |
8140791
to
1948441
Compare
pinging @nomeata - I think this is ready to be reviewed. |
Sorry for the delay, ICFP… Before brining this before the committee, I’d like to raise one point: We already added a way to distinguish between the type constructor and the data constructor in export lists, and the While it is a bit strange to call a data constructor In fact, I would be open to just extending
What is the rationale for this? I would expect that |
@nomeata thanks for the comments. I do agree that
This is coming from the implementation that I already have in mind. I just added that bit to the proposal trying to cover all the possible corner cases. Frankly speaking, I am not sure whether this feature is even widely used (specifying several entities in one pragma). So this is just an implementation side-effect, so to speak, which I included in the proposal for the sake of completeness. |
Even if that was the easiest way to implement it, and may few people use this feature, we should still strive for consistency with the rest of the language. And if in export lists (where we already have such qualifiers) they bind more tightly than commas, then I think they should do that here as well. |
@nomeata for sure, this is a good point and I wholeheartedly agree! |
What is the status of this? |
@bgamari proposal is updated according to the comments. I guess it is waiting to be reviewed by the committee .. |
Cool, @nomeata, it sounds like this needs a shepard. |
@nineonine, could you please mention the idea of positional DEPRECATED pragmas as described here by Simon in the list of alternatives? |
Before I am ready to make a recommendation, are there any thoughts (pro or contra) about moving to positional DEPRECATED pragmas instead? In fact, I think that this approach is better as it enables more fine-grained control over deprecated entities and we don't have to use |
Added positional deprecation idea. |
@nineonine will you be able to rewrite/reimplement the proposal if the Committee decides in favor of positional pragmas? |
@bravit sounds good. |
Hang on. No one has addressed Ryan's point, where he points to the already accepted proposal about namespacing for Isn't namespacing for We don't want to add inconsistent solutions! Arguably, if we like |
@simonpj, in fact, it was addressed. We have three options here: to choose either "data", "value", or "pattern". Richard Eisenberg wrote on the committee's mailing list:
The same argument applies to infix/WARNING proposal, so I think that we could change it either (anyway, it is not implemented yet afaik). I personally prefer "data" over "value", and "value" over "pattern", but I'm not ready to die for that. |
OK -- so at let's agree, at least, that whatever is decided here applies equally to the infix/WARNING proposal. And I would argue that it ought to apply equally to export and import lists, though that would need a careful migration path. OK, so do we really want to write
Obviously And Personally I'm fine with
would be pretty strange. But I don't expect it to happen in 99.999% of programs, and I care about the 99% case a lot. |
Updated the proposal to use |
I was thinking today about the implementation and it led me to the following question - what do we want to happen when wrong specifier was used? {-# DEPRECATED type ack "blah" #-}
ack = () Currently I see 3 options:
|
@nineonine did you see #214? That is a more ambitious attempt to fix all that, which likely subsumes this proposal. Please comment there as well, if you find it lacking (or to voice your support)! |
@nomeata no I didn't! thanks. Although, I am a bit confused now. What is the destiny of this proposal/thread and ticket 3427? |
@nineonine it turned out that the proposal on namespacing in the DEPRECATED pragma (among other things) was already accepted more than a year ago. That's why there is no sense in accepting this proposal now. That proposal and your proposal are now subsumed by #214. Hopefully, it will be accepted and implemented once, that will close the ticket you mentioned. |
This proposal would allow to specify which entity (type or data constructor) you want to deprecate.
rendered
gitlab issue