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

Remove the * kind syntax #143

Merged
merged 14 commits into from Aug 4, 2018

Conversation

Projects
None yet
@int-index
Copy link
Contributor

int-index commented Jun 9, 2018

The Haskell Report uses * to denote the kind of inhabited types. As we move towards DependentHaskell, it is increasingly painful to support this historical choice of name. We propose to slowly and carefully remove this syntactic oddity from the language.

Rendered

@AntC2

This comment has been minimized.

Copy link

AntC2 commented Jun 9, 2018

We've already had a substantial debate on * vs Type on another proposal or two. I rather thought the whole issue was already decided.

What your 'jokiness' [later removed] fails to acknowledge is the huge amount of educational and reference materials that will go out of date as a result. Also the huge amount of code that can be and still is written without needing the fancy type/kind machinery for which *'s current syntax is inconvenient. You say

Firstly, the * syntax is unfortunate because it is confusing to some beginners. There are frequent cases where people familiar with regular expressions mistake * for a wildcard, ...

"Frequent"? I've never seen anybody with that sort of confusion. Provide evidence. "Wildcard"? Then how on earth do they cope with * meaning multiplication? You do not seem to be proposing * be used for wildcard, so those people are going to continue to make "mistakes", aren't they? Perhaps you should include proposing type wildcard _ get changed to *?

When I was learning Haskell, -> and * and parens seemed a perfectly ergonomic notation to explain the arity of functions: it fits hand-in-glove with λ-calculus and Hindley-Milner.

Yes, 25+ years ago somebody might have foreseen things like type operators and Type-in-Type, and chosen a different symbol. And that symbol would have taken on the sense * now has. But they didn't, and it's never inconvenienced me.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 10, 2018

What your arrogant 'humour' fails to acknowledge is the huge amount of educational and reference materials that will go out of date as a result.

I do acknowledge it right in the proposal, in the "Costs and Drawbacks" section. Hence the long deprecation period with helpful warnings. I certainly don't take this issue lightly! But there will be more than enough time to adapt.

"Frequent"? I've never seen anybody with that sort of confusion.

The evidence is anecdotal, I've seen @goldfirere mention it, and it happened in my teaching experience as well. I hope you're not expecting me to provide the names, phone numbers, and home addresses of the students 😄

Then how on earth do they cope with * meaning multiplication?

Firstly, I'm not saying it's hard to cope with overloaded meanings of *, I'm just saying that the initial impression might be misleading.

Secondly, multiplication is an even more common phenomenon than a wildcard, so that's not a problem. It's also used for bullets in Markdown, etc. However, those uses are all clearly distinct.

And thirdly, * standing for multiplication and wildcards is widespread, while * standing for the kind of inhabited types is (to my knowledge) specific to Haskell. For instance, Agda uses Set, Coq and Idris use Type, so Haskell is the odd one here. Even if you can find other languages that use * in the same way as Haskell, it's still not as common.

When I was learning Haskell, -> and * and parens seemed a perfectly ergonomic notation to explain the arity of functions: it fits hand-in-glove with λ-calculus and Hindley-Milner.

That's because this is indeed perfectly ergonomic notation! I happen to like that * is just a single character, and I really like its Unicode variant too. In another proposal you can see me arguing that at least ★ should keep its current meaning. And I'd never suggest that the choice of * was ill-informed: it was made in a different context, for a language wildly different from modern Haskell with -XKitchenSink.

And this happens to be the crux of the issue. If we want Haskell to evolve further, we should do something about this syntactic conflict. It really bothers me that silly syntactic conflicts prevent actual language development.

Short notation often looks pleasant, especially after you get used to it. But the truth is that it creates a less inclusive environment (you become a part of the ingroup after you realize that in kinds, * stands for neither multiplication nor a wildcard in Haskell, otherwise you're in the outgroup), while a simple name like Type is self-explanatory for beginners (thus inclusive).

So * is an piece of syntax that:

  • needs to be explained explicitly to beginners
  • conflicts with other language features

and for me, these two points outweigh its conciseness and looking beautiful in LaTeX documents.

@goldfirere

This comment has been minimized.

Copy link
Contributor

goldfirere commented Jun 10, 2018

I am in full support of this proposal, very much including the long timeframe for its implementation.

I should note that I agree with the drawbacks @AntC2 points out, but for me, the benefits outweigh the costs. @int-index's defense of the proposal expresses my thoughts as well as or better than I could, so I won't repeat those arguments. I will add the name of one student of Haskell initially confused by *: me. Without thinking it through, I initially believed that * was some kind of global supertype. I figured out the truth in the end, but several students in my Haskell class last spring fell into the same misconception, trying to relate * to Java's Object. This is all anecdotal, of course, and there is no way to provide evidence.

Thanks, @int-index, for writing this proposal!

@AntC2

This comment has been minimized.

Copy link

AntC2 commented Jun 10, 2018

Thanks @int-index for your response: those are sensible points, sensibly expressed. Get them in the proposal proper.

The trouble with appealing to anecdote is that each anecdote is equally valid, so we can't take a reasoned approach. Contra @goldfirere I will add the name of one student never confused by *: me. (My background included all sorts of languages with various uses for *; and various symbols for wildcards.) If you want to appeal to confusion amongst users, a good place to look is StackOverflow or Haskell-Beginners. That's where I went wrt ScopedTypeVariables.

Actually, kind * as a wildcard isn't an entirely silly idea. Way, way back, GHCi would also show kinds like ? or ??, meaning: some type-or-other, not necessarily the same as the one denoted in this signature by *.

BTW, who are these 'beginners' learning about kinds? You don't need them to program in H98, even if you add in common extensions. I think there's a more reasoned justification for removing *; and I'd like to think that tinkering with my favourite language is well-founded in reason:

  • As Haskell's type- and kind-level features get richer (with Type Families, Type Operators, PolyKinds, Kind Signatures, DataKinds, Type-in-type, ...), its type/kind-level language is converging on needing as much syntax as at the term-level.

  • Then for consistency, we'd like to apply the same lexical rules in both:

    • A (type) operator is any lexeme consisting of symbols.
    • A (type) argument/operand is any lexeme consisting of alphanumerics.
  • In which case, lexeme * is an anomaly: it's an operator at term level, but currently an operand at type/kind level. GHC works round that anomaly with a bunch of special-purpose parsing.

  • This proposal is to move towards more regular lexing; whilst allowing plenty of warning time for legacy code to adapt.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 10, 2018

Actually, kind * as a wildcard isn't an entirely silly idea. Way, way back, GHCi would also show kinds like ? or ??, meaning: some type-or-other, not necessarily the same as the one denoted in this signature by *.

Indeed, the ? and ?? kinds are the OpenKind machinery which I already mention in the proposal. See also this StackOverflow answer https://stackoverflow.com/questions/5359707/

BTW, who are these 'beginners' learning about kinds? You don't need them to program in H98, even if you add in common extensions. I

I think you are mistaken here. Every H98 user needs to understand kinds to see why instance Functor Int is not a thing. That's why kinds are mentioned in the Haskell Report.

Even if kinds are never specified by the user, they are inferred, checked, and will show up in error messages.

As Haskell's type- and kind-level features get richer <...>
Then for consistency, we'd like to apply the same lexical rules in both <...>
In which case, lexeme * is an anomaly: it's an operator at term level, but currently an operand at type/kind level <...>
This proposal is to move towards more regular lexing <...>

Yes, that's a good way to justify the removal *. But I don't think I need to modify the proposal as you suggest — I already appeal to these points when I talk about the conflict with -XTypeOperators.

@takenobu-hs

This comment has been minimized.

Copy link
Contributor

takenobu-hs commented Jun 10, 2018

Interesting.
I have one question.

How will GHCi display * in this proposal?

Current GHCi:

ghci> :kind Maybe
Maybe :: * -> *

This proposal?:

ghci> :kind Maybe
Maybe :: (TYPE 'LiftedRep) -> (TYPE 'LiftedRep)

I like this proposal.
However, I think that the above two display are not different for beginners in terms of difficulty.

Of Course, I think that this proposal is good for Dependent Haskell.

@AntC2

This comment has been minimized.

Copy link

AntC2 commented Jun 10, 2018

I'm trying to get you to use professional, reasoned language. That's why I wrote out the words for you. If you want this to be taken seriously, use serious terminology. At the moment there's too much jokiness that will quickly go stale. Why should I (or anybody relying on Haskell for mission-critical software) trust that somebody knows what they're doing if so much is described with in-jokes?

Remove the following phrases [later removed]:

You might think the decision is already made and writing it up is just a chore. (The proposal certainly reads like that.) This is a massive, code-breaking and documentation-breaking change. What we don't want (because this has happened before) is a bunch of surprised users complaining after the fact that they weren't consulted/didn't have a chance to comment. We (or rather, you as the one in the gun) need somewhere to point to to show you carefully considered all the impacts. In (say) 3 years time when -XStarIsType gets switched off by default and compiles fail, how is that proposal going to read?

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 10, 2018

@takenobu-hs Under this proposal (and its current implementation), we have the following rules for pretty-printing:

  • When -XStarIsType is enabled, TYPE 'LiftedRep is printed as * (or to if -XUnicodeSyntax and -fprint-unicode-syntax are specified).
  • When -XStarIsType is disabled, TYPE 'LiftedRep is printed as Type. This is justified by having type Type = TYPE 'LiftedRep exported by Data.Kind. Ideally we would want to qualify it as Data.Kind.Type when there are conflicting definitions of Type in scope, but the current implementation doesn't handle this.
  • If we refer to a part of the source code that the user wrote, no transformation is applied. So if the user is asking :k Type with -XStarIsType, she will get Type :: * and not * :: *. This is to preserve the property that ppr . parse = id.
@takenobu-hs

This comment has been minimized.

Copy link
Contributor

takenobu-hs commented Jun 10, 2018

@int-index thanks. It is displayed as follows.

When -XStarIsType is disabled (maybe, beginner's default settings) :

ghci> :kind Maybe
Maybe :: Type -> Type

When -XStarIsType is enabled :

ghci> :kind Maybe
Maybe :: * -> *
@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 10, 2018

@takenobu-hs Correct. The reason I didn't cover it in this proposal is that it's covered in #83, this proposal is about deciding how to get to the point where -XStarIsType is switched off by default.

@AntC2

a bunch of surprised users complaining after the fact that they weren't consulted/didn't have a chance to comment

I certainly want to avoid that! I would appreciate if you (and others) would share this proposal on communication channels available to you to get the widest exposure possible before we make a decision.

@int-index int-index force-pushed the int-index:remove-star-kind branch from 68a61be to 6e7a9cc Jun 10, 2018

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 10, 2018

if all I can see is clowning around?

@AntC2 I shuffled some words around, hopefully now you can see the proposal itself.

@AntC2

This comment has been minimized.

Copy link

AntC2 commented Jun 10, 2018

@int-index thank you. Yes much better. I also shuffled.

Proposals aren't literature/don't need to be entertaining. A writing style that doesn't draw attention to itself; but rather melts into the background and gets the ideas across, is what's appropriate.

@andrewthad

This comment has been minimized.

Copy link
Contributor

andrewthad commented Jun 10, 2018

I’m in favor of this proposal. I have always found the use of * as a non-infix identifier in types to be inconsistent with the rest of the language. I’m also in favor of the long deprecation period.

@hithroc

This comment has been minimized.

Copy link

hithroc commented Jun 10, 2018

Without thinking it through, I initially believed that * was some kind of global supertype

I've had a similar experience.

@vmchale

This comment has been minimized.

Copy link

vmchale commented Jun 11, 2018

Several things come to mind:

  1. I think you are underestimating the effects this would have on the Haskell ecosystem. In particular, it would be impossible to support old and new versions without using CPP or fancy stuff in your .cabal file. It would also potentially make old papers obsolete (papers tend not to be revised) as well as old books. One of the wonderful things about the Haskell98 standard is that code from papers 20 years old will still compile and run.

  2. Benefits for beginners seem to be overstated. In any case, designing a language for beginner-friendliness will be to the detriment of more important things.

  3. I am unaware of how GHC will actually implement a multiplicative solver for dependent types. Is this planned? I know ATS only has a solver for first-order arithmetic. I think Idris does something more complicated.

  4. I'm unclear as to why we could not add a -XNoStarIsType extension which would be automatically implied by -XDependentHaskell or the like.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 11, 2018

Thanks @vmchale for bringing up these points!

I think you are underestimating the effects this would have on the Haskell ecosystem. In particular, it would be impossible to support old and new versions without using CPP or fancy stuff in your .cabal file.

I don't think I'm underestimating it, but I think that the proposed deprecation schedule is appropriate.

Libraries tend to support the last 3–5 releases. Even at this point using CPP almost always becomes a necessity. In this proposal, we have 9 transitional releases that don't require any changes at all, and 6 more releases that only require to enable -XStarIsType explicitly. That's total of 15 releases that support the old syntax, although with warnings. This means that there will be a point in time where a library can support the last 15 versions of GHC with no CPP by simply adding -XStarIsType to default-extensions in the .cabal file. Or the last 18 versions and all future versions by using Type imported from Data.Kind instead.

This is far beyond the regular version span that can be supported without CPP.

It would also potentially make old papers obsolete (papers tend not to be revised) as well as old books. One of the wonderful things about the Haskell98 standard is that code from papers 20 years old will still compile and run.

Books and papers get obsolete either way. A rare paper limits itself to Haskell98 — normally a paper is about the latest research, and this probably means using the latest language features as well. By this line of reasoning, we shouldn't have breaking changes at all, ever, which is possible, but will make the language an accumulating ball of complexity (case in point: C++).

Also, since Haskell98 does not allow kind signatures, the code will not break under this proposal. Only code that uses -XKindSignatures (or extensions that imply it) will be affected.

Benefits for beginners seem to be overstated

A couple of people shared their past experience as a beginner right in this thread, admitting to having misconceptions about * due to its name. Maybe it's not a major issue, but it's an issue worth considering.

designing a language for beginner-friendliness will be to the detriment of more important things.

Yes, trade-offs are everywhere. Fortunately, in case of this proposal, both beginners and people focused on using advanced features get something out of it. I wouldn't say either of these motivators is more important than the other, but personally I'm more concerned about getting rid of the conflict with -XTypeOperators.

I am unaware of how GHC will actually implement a multiplicative solver for dependent types. Is this planned?

I think the particulars are beyond the scope of this proposal. Fact is that Haskell already has type-level multiplication:

~$ ghci
GHCi, version 8.2.2: http://www.haskell.org/ghc/  :? for help
Prelude> :set -XTypeOperators -XDataKinds
Prelude> import GHC.TypeNats
Prelude GHC.TypeNats> :kind! 2 * 5
2 * 5 :: Nat
= 10

I'm unclear as to why we could not add a -XNoStarIsType extension which would be automatically implied by -XDependentHaskell or the like.

Indeed, that's the plan. However, there are associated costs:

  • We end up with two dialects of Haskell. It's conceivable that if we leave it at that, then even modern literature and code will keep using * in some cases, but Type in others. This creates unnecessary mental overhead for anyone reading a .hs file (ideally, people shouldn't trace what extensions are enabled just to check how foo * bar parses).

  • It makes the language bigger, so even 10 or 20 years down the road people will have to keep in mind that both * and Type exist.

  • The implementation will have to be maintained forever. Its cost is: special cases in the lexer, special cases in the parser, special cases in the pretty-printer, special cases in the AST, special cases in the renamer, special cases in the typechecker.

@vmchale Let me know if I failed to address any of your concerns, thanks for your thoughtful criticism.

@vmchale

This comment has been minimized.

Copy link

vmchale commented Jun 11, 2018

Ah, that was my oversight. I had assumed Kind signatures were part of Haskell2010. That alleviates my primary concern here.

This creates unnecessary mental overhead for anyone reading a .hs file (ideally, people shouldn't trace what extensions are enabled just to check how foo * bar parses).

Well, that will be the case currently even if the proposal is implemented.

@ekmett

This comment has been minimized.

Copy link

ekmett commented Jun 11, 2018

I have no problem with moving forward with the proposal to put the machinery in place.

I don't think you can push this through with as short a deprecation timetable as you'd like. I think that the timeline effectively being 2 years til it becomes a default warning is much too aggressive. (Keeping in mind our much accelerated release schedule, 4 releases isn't a long period of time any more.)

Libraries "typically" maintain a 3-5 year maintenance window, but this affects all sorts of libraries that have almost no dependencies that currently are easily maintained clear back to the 7.2 era at present. I have a couple of dozen of these. Those kinds of libraries have to become a sewer of CPP to hack around this sort of thing unless we push idioms on them like

#if __GLASGOW_HASKELL__ < whatever
#define Type *
#else
import Data.Kind
#endif

and get them to switch early.

I'd be much happier with time stolen out of those last 6 releases and pushed forward into the pre-deprecation window.

@gbaz

This comment has been minimized.

Copy link

gbaz commented Jun 11, 2018

The key parts of the timetable seem to be:

  1. Four releases in, we have -Wall warnings.
  2. Eight releases in, we disable this by default.
  3. Fourteen (!) releases in, we remove it.

For the timetable perhaps it would be good to specify "at least X releases or Y months" to take into account the variation on release schedule possible.

I'm also curious about metrics on hackage with regards to how many packages actually use kind-signatures such that they'd be affected by this.

@takenobu-hs

This comment has been minimized.

Copy link
Contributor

takenobu-hs commented Jun 11, 2018

Sorry if I'm missing context.
I'd like to know the grand plan of this proposal.

Is my understanding correct? As shown in the table below.

The kind representations of :kind command in GHCi :

Haskell 2010 old GHC
(7.10.3)
current GHC
(8.4.2)
This proposal
(switch enabled)
This proposal
(switch disabled)
Haskell 20xx
Lifted
(e.g. Int)
Type ?
Unlifted boxed
(e.g. ByteArray#)
# TYPE 'UnliftedRep TYPE 'UnliftedRep TYPE 'UnliftedRep ?
Unboxed
(e.g. Int#)
# TYPE 'IntRep TYPE 'IntRep TYPE 'IntRep ?

The "switch" means -XStarIsType.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 11, 2018

@takenobu-hs This is a nice table. Indeed, your understanding is correct.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 11, 2018

For the timetable perhaps it would be good to specify "at least X releases or Y months" to take into account the variation on release schedule possible.

@gbaz Sure, I added time estimations.

I'm also curious about metrics on hackage with regards to how many packages actually use kind-signatures such that they'd be affected by this.

I think it's safe to operate under assumption "nearly all of them". As to actual estimates, I don't know how useful they would be — we'd have to take into account if a library is maintained, if it's popular, etc, to make any judgements. I'd rather just rely on experience of vocal maintainers to make the decision, so I'm really glad to hear @ekmett comment on this proposal.

I don't think you can push this through with as short a deprecation timetable as you'd like. I think that the timeline effectively being 2 years til it becomes a default warning is much too aggressive.

The schedule was probably poorly written, but I intended it to say 3 years, not 2:

  • -Wcompat: 8.6, 8.8, 8.10
  • -Wall: 8.12, 8.14, 8.16
  • default: 8.18, ...

I'd be much happier with time stolen out of those last 6 releases and pushed forward into the pre-deprecation window.

Done, I adjusted the timetable. Let me know if you're still unsatisfied with it. I'll trust your experience and just introduce whatever change you think is needed.

@takenobu-hs

This comment has been minimized.

Copy link
Contributor

takenobu-hs commented Jun 11, 2018

@int-index thanks again.

Indeed, the problem of literature and education is difficult.
But I feel this is a long-term challenge for Dependent Haskell.

@goldfirere

This comment has been minimized.

Copy link
Contributor

goldfirere commented Jun 11, 2018

Even after this proposal is fully executed and * can never mean Type, it still will be possible (by adding a little magic dust to the lexer and the parser -- but only those modules) to give a good error message for a poor use of *. So someone using an old resource will still have an easy time adapting their code.

Note that someone who uses a Haskell98 Monad instance has no such luck, even today! (They have to learn about Functor and Applicative and write instances for those, without GHC's guidance.)

@int-index int-index force-pushed the int-index:remove-star-kind branch from 1c699cf to 8ddede4 Jun 18, 2018

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 18, 2018

@AntC2 I tried to rewrite the motivation section to be more structured by splitting it into several points, as you suggest. I avoid talking about "beginners" or "confusion". And I make less assumptions.

Does the text read better now? Thanks!

@AntC2

This comment has been minimized.

Copy link

AntC2 commented Jun 18, 2018

Does the text read better now?

Thank you @int-index , yes much better.

@goldfirere thank you for your patient explanation. I goofed up. That doesn't help the discussion so I removed the goofy bits. Note to self: don't try to write up tricky type/kind stuff late on a Sunday night.

Maybe is not a type: it's a type constructor.

Yes we all need to learn to talk like that. And pronounce Type as "kind-of-type-not-constructor" or "kind-of-types-of-terms". Oh, except we're doing away with "kind". Then I'm still struggling with this from the proposal:

Type being a regular English word and a regular Haskell identifier

Using a "regular Haskell identifier" I get, for lexical consistency. Using an English word only helps if that word aids intuition. And having the word as Type is by now presumably baked in concrete.

I'm inclined to prefer a non-word. Can I still use bigstar with UnicodeSyntax? Can I define a synonym TnC ("type not constructor")? But presumably error messages will show Type.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 18, 2018

Using an English word only helps if that word aids intuition.

Hopefully, that is the case for Type. The intuition is that "types classify terms". Not all type-level entities do that, for instance, Maybe alone cannot classify terms, so it is not a proper type. As I said, I borrow this terminology from McBride. It is also consistent with the Haskell Report. I believe Type is a good name.

Can I define a synonym TnC ("type not constructor")?

Yes.

But presumably error messages will show Type.

The error messages, if not for a hack in the pretty printer, would show TYPE 'LiftedRep. I see no problem adding a flag to control the display of TYPE 'LiftedRep, which can be anything you like.

I'm inclined to prefer a non-word. Can I still use bigstar with UnicodeSyntax?

No, that will not be possible. Under this proposal in its current form, does not receive special treatment. To be honest, I do like how looks, especially in papers with all the other math notation. The problem is that I found it hard to argue for. I guess we can say that it is better (a) due to precedent in literature; (b) for its brevity. It also does not exhibit most of the problems that * does, e.g. it does not conflict with other notation. But if the only point we'd like to sacrifice is "no background knowledge", and to keep the "lexical consistency", "no language dialects", and "no type/term conflicts", we would have to make the following adjustment to the language:

  • is considered an alphanumeric identifier
  • type ★ = Type is exported from Data.Kind

This is actually not that bad. After all, it is neither punctuation nor a letter:

> Prelude Data.Char> isPunctuation '★'
False
> Prelude Data.Char> isAlpha '★'
False

so the choice is fairly arbitrary. However, currently it is considered an operator in terms, just like *:

Prelude> a ★ b = a + b
Prelude> 3 ★ 5
8

We would have to change that. I do not want to argue for yet another breaking change in this proposal. Making an alphanumeric identifier is not tied to this proposal of removing -XStarIsType. If someone created another proposal to argue for making an alphanumeric identifier, I would be in support.

@goldfirere

This comment has been minimized.

Copy link
Contributor

goldfirere commented Jun 18, 2018

I happen to have a recent copy of Hackage on my machine, so I took a look for . Precisely two packages use it to mean Type: EsounD (last updated in 2011) and maam (last updated in 2015). No packages use as a binary operator. More packages mention to support GHC's support of this operator than actually use it in earnest.

So: we could make into a prefix identifier (instead of its current infix status) without known breakage. But would people start to use it then? I don't know.

@treeowl

This comment has been minimized.

Copy link
Contributor

treeowl commented Jun 18, 2018

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jun 18, 2018

I don't really see the point of adding a different special case to the parser, and unicode is a bit hard to type anyway.

The special case in the lexer will be easy to implement. And people who use Unicode have their ways of typing it.

I added the to the "Alternatives" section to keep it in mind, but I would prefer to discuss it elsewhere (preferably in a separate proposal) as to not to distract from the main proposal.

@phadej

This comment has been minimized.

Copy link
Contributor

phadej commented Jun 18, 2018

What's about #? TYPE 'UnliftedRep is just too long and clunky to be used in low-level code.

@bgamari

This comment has been minimized.

Copy link
Contributor

bgamari commented Jun 18, 2018

What's about #? TYPE 'UnliftedRep is just too long and clunky to be used in low-level code.

We could introduce UnliftedType. However, users are also always free to introduce their own type synonyms.

@goldfirere

This comment has been minimized.

Copy link
Contributor

goldfirere commented Jun 18, 2018

Historical note: # (meaning an unlifted type) has never been parsed by any version of GHC. GHC used to print it in error messages, but it was output-only.

@takenobu-hs

This comment has been minimized.

Copy link
Contributor

takenobu-hs commented Jun 22, 2018

This is a note to remember.
In the next Haskell language report, we need to update the description of the kind * to Type.
Currently, the notation of the kind * is described in section 4.1, 4.2 and 4.6 in Haskell 2010 Language Report.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jul 10, 2018

@nomeata Do you think the discussion has ebbed down sufficiently to submit this proposal to the committee? It's been a month since the initial submission and 18 days since the last comment.

@nomeata

This comment has been minimized.

Copy link
Contributor

nomeata commented Jul 10, 2018

Yeah, looks like it. I am bit lost in all the discussion – how, if at all, is this proposal affect by #146 and is that reflected in the proposal text?

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jul 10, 2018

@nomeata In case #146 is accepted, I will introduce the following changes to the text of this proposal: int-index@bb9b2b6

This does not change the proposed deprecation plan or its effects.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jul 10, 2018

Alright, I see that you've just merged #146. Pushing the update.

@int-index

This comment has been minimized.

Copy link
Contributor Author

int-index commented Jul 14, 2018

@nomeata Is there something else holding up the submission? Let me know if so, I will try to address it. Thanks!

@nomeata

This comment has been minimized.

Copy link
Contributor

nomeata commented Jul 14, 2018

Eh, nothing. Will do that now.

@nomeata nomeata merged commit bb9b2b6 into ghc-proposals:master Aug 4, 2018

@nomeata

This comment has been minimized.

Copy link
Contributor

nomeata commented Aug 4, 2018

Accepted!

@int-index int-index deleted the int-index:remove-star-kind branch Aug 4, 2018

@bravit bravit added the Proposal label Nov 11, 2018

@int-index int-index referenced this pull request Nov 12, 2018

Open

Linear types #111

3 of 6 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.