Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#10188 closed bug (fixed)

prefix type-level cons can't be parsed

Reported by: Kinokkory Owned by: Kinokkory
Priority: normal Milestone: 8.0.1
Component: Compiler (Parser) Version: 7.8.4
Keywords: Cc: Kinokkory
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case:
Blocked By: Blocking:
Related Tickets: #10189 Differential Rev(s): Phab:D768
Wiki Page:

Description (last modified by Kinokkory)

Whereas other type operators (whether used as type families or used as data constructors) can be safely used in a prefix form, only the type-level cons of the built-in list kind can't be used in a prefix form.

It really is a problem because we don't have any means to express the type-level cons itself in source code. This for example prevents us from writing a generic type-level foldr that takes the built-in list and other similar data types alike.

In a ghci:

> :set -XDataKinds -XTypeOperators
> data Listy a = a ::: Listy a | Nily
> :kind! (:::)
(:::) :: k -> Listy k -> Listy k
= forall (k :: BOX). (':::)
> :kind! (:)

<interactive>:1:2: parse error on input :

Change History (13)

comment:1 Changed 3 years ago by simonpj

Good point. This is just a question of fixing the parser. Would anyone like to have a go?


comment:2 Changed 3 years ago by thomie

Component: CompilerCompiler (Parser)

comment:3 Changed 3 years ago by Kinokkory

Description: modified (diff)

comment:4 Changed 3 years ago by goldfire

It's unfortunate (and a bug) that the code you wrote doesn't work, but there is support for the feature you want:

> :kind '(:)
'(:) :: k -> [k] -> [k]

Note the '.

comment:5 in reply to:  4 Changed 3 years ago by Kinokkory

Oh, I didn't know that. Thanks a lot!

In a ghci:

> :kind! '(:::)
'(:::) :: k -> Listy k -> Listy k
= forall (k :: BOX). (':::)
> :kind! (':::)

<interactive>:1:3: parse error on input :::
> :kind! (':)

<interactive>:1:3: parse error on input :

The message "forall (k :: BOX). (':::)" seems inconsistent with the parsing mechanism that allows "'(:::)" instead of (':::). I'll report this as another new bug!

comment:6 Changed 3 years ago by Kinokkory

comment:7 Changed 3 years ago by Kinokkory

Cc: Kinokkory added
Milestone: 7.12.1
Owner: set to Kinokkory

comment:8 Changed 3 years ago by Kinokkory

Differential Rev(s): Phab:D768
Status: newpatch

comment:9 Changed 3 years ago by Kinokkory

This patch makes (:) Int [Float, Double] and Int : [Float, Double] parsed.

In fact, infix type-level cons also used to be not parsed without '.

Essentially, I changed the definition of tyconsym by adding | ':' ....

tyconsym :: { Located RdrName }
        : CONSYM                { sL1 $1 $! mkUnqual tcClsName (getCONSYM $1) }
        | VARSYM                { sL1 $1 $! mkUnqual tcClsName (getVARSYM $1) }
        | ':'                   { sL1 $1 $! consDataCon_RDR }
        | '*'                   { sL1 $1 $! mkUnqual tcClsName (fsLit "*") }
        | '-'                   { sL1 $1 $! mkUnqual tcClsName (fsLit "-") }

By the way I wonder what | '*' ... and | '-' ... are for.

comment:10 Changed 3 years ago by goldfire

Looking more closely at this, I think this was not a bug in the parser, but in the pretty-printer. The pretty-printer prints type-level ::: as (':::), but it should be '(:::), which is what is parsed. Normal type-level cons is parsed the same way, with the tick outside the parentheses. (Which I think is confusing, but that ship has sailed.)

On the other hand, it does seem draconian to require the tick for cons, when : has no possible other interpretation as a type-level constant. So, considering this as a feature request, I think it's a good one. Thanks for the patch!

Did you end up submitting a separate bug report for the pretty-printer? That's still outstanding, I believe.

comment:11 Changed 3 years ago by Austin Seipp <austin@…>

In 012ea0b96cc041bced4565d74bef7ccb75f1af0d/ghc:

parser: allow type-level cons in prefix position

Reviewed By: austin

Differential Revision:

GHC Trac Issues: #10188

comment:12 Changed 3 years ago by Kinokkory

Resolution: fixed
Status: patchclosed

comment:13 Changed 2 years ago by thoughtpolice


Milestone renamed

Note: See TracTickets for help on using tickets.