syntax error in pretty-printed kind ascriptions

[megacz]

Program below; here's the output:

$ inplace/bin/ghc-stage1 -ddump-tc \
  -XNoMonomorphismRestriction -XTypeOperators test.hs
[1 of 1] Compiling Foo              ( test.hs, test.o )
TYPE SIGNATURES
    baz :: forall (** :: * -> * -> *) x. (Num x, Foo (**)) => (**) x x

Note how the first occurrence of (**) is missing parens.

Patch to fix it is attached.

Sample program:

module Foo
where
class Foo (**) where
  bar :: x -> x ** x
baz = bar 3

[simonpj]

Thanks; I've commmited your change.

Note, though, that it's likely that we're considering making operators like '*' into type constructors rather that type variables'. This is inconsitent with terms, but is jolly convenient:

data a + b = Left a | Right b

Of course there'll be a flag. But let us know if you think that having operators be type variables is very useful. (I tend to think it's more confusing than useful.)

Simon

[sebf]

I have seen people use operators as type variables for arrows like this:

{{ arr :: Arrow (~>) => (a -> b) -> (a ~> b) }}

Your example is also compelling. Not sure what I would find more confusing: type variable operators or an exception to the naming rule for constructors. I'd probably use a flag to change the default when I need it.

Sebastian

[megacz]

Simon, I found it confusing at first too, but eventually got used to it.

How about letting the user choose tyvar-or-tycon on a symbol-by-symbol basis, the same way we currently choose fixity on an identifier-by-identifier basis? I don't mind writing the code for this.

I do find operators-as-type-variables very useful, particularly (**) in the definition of GArrows

 http://git.megacz.com/?p=ghc-base.git;a=blob;f=GHC/HetMet/GArrow.hs#l43

• a

[megacz]

I like Sebastian's example too (I have been considering rewriting GArrow.hs using (~>) for a while now).

Are "tycon symols" usable as datacons too? I'm a bit fuzzy on how the namespaces work; GHC's NameSpace?.lhs considers the datacon namespace to be disjoint from the tycon namespace, and also considers the tyvar namespace to be disjoint from the variable-name namespace. But most users seem to think of "the capitalized-word namespace" and "the uncapitalized-word namespace".

I ask because it would be nice to be able to use symbols as associated types:

class Category g => GArrow g where
  data (**) :: * -> * -> *
  -- ...

So would -XSymbolsAreTyCons (or whatever it will be called) allow the program above?

Thanks,

• a

[megacz]

Grr, in my previous post, "namespace" should actually be "lexical token class", and in my example (**) is a tycon, not a datacon.

Apparently this still is confusing for me :)

At the moment, if I understand correctly, -XTypeOperators considers symbols starting with a colon to belong to the tycon/type/datacon lexical token class ("upper case identifiers") while all other symbols belong to the expression/tyvar lexical token class ("lower case identifiers"). With -XSymbolsAreTyCons, does "starts with a colon" no longer matter? That would be sort of nice.

• a

[simonpj]

See also  http://hackage.haskell.org/trac/haskell-prime/wiki/InfixTypeConstructors

Yes, with -XSymbolsAreTyCons, all operator symbols would be tycons, irrespective of the leading colon.

Allowing symbol-by-symbol control would be more complicated. But it might have the advantage of applying uniformly to the term world too. Thus:

constructor *
variable T

data S T = Int * T

would mean the same as

data S t = Star Int t

It's a bit confusing though.

(PS: You can use the "Change" lnk in your comment to edit a previous remark.)

[megacz]

(PS: You can use the "Change" lnk in your comment to edit a previous remark.)

Unfortunately only TRAC_ADMIN's like you get the "change" link...

 http://trac-hacks.org/ticket/1588