Hello,
I have a couple of pragmatic questions:
1. To "fix" my code so that it is compatible with this change I need to do
the following:
1. Whenever I have kind signatures mentioning `*`, replace `*` with
`Type`
2. Import `Data.Kind(Type)`
3. Resolve conflicts involving existing datatypes named `Type`.
2. If my code has all of the properties below, then it will break as soon
as this change is adopted, so I have to fix it in some way straight away:
1. uses `*` is a binary type operator, and
2. uses `*` in kind signatures, and
3. uses the `PolyKinds` language extension.
3. If my code does not have the properties in (2) but uses `*` in kind
signatures, it will continue to work for 2 GHC releases, but then it will
break, so I should do (1) sometime before.
Is my understanding correct?
-Iavor
On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner
Hi,
Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
An alternative that hasn't been suggested so far is to have -XStarIsType control the pretty-printer as well as the parser. Simon PJ and I discussed this this morning, thinking it was a good idea. Upon further consideration, my preference would be to bite the bullet and just switch to printing Type always, but I'm not really against the print-*-with-XStarIsType idea.
I’m with Simon here. We have, I believe, precedence where error messages are affected by the language extension in scope, so this might satisfy the principle of least surprise, and also cause the least contention among our users.
We can still apply this rule when `-XNoStarIsType`:
One slightly separate question is what to print. The proposal currently suggests to print Type. There was concern in this thread that it would be printed fully-qualified, but I like Joachim's suggestion in the last known email in this thread to special-case printing of Type; even if it's not imported, it would print as Type, not Data.Kind.Type. (Unless some other Type were in scope.) It is also easy to teach GHC to print a bespoke warning when a user writes Type when it is out of scope, telling them to import Data.Kind.
The proposal currently does not state which modules export Type. I can infer from the text that it is Data.Kind, but this could be made explicit. Also, the proposal should state whether it is re-exported from Prelude or not (I assume it is not).
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee