Type operators in GHC

[Conal Elliott]

Hi Simon,

Yes, I could live with (.->), (.+), etc more easily than `arr`, `plus` etc.

Better yet would be a LANGUAGE pragma I can add to my libraries to get the
old behavior back.

Better still for me personally would be for other libraries to add a
LANGUAGE pragma to get the 7.6.1 behavior. I can live without this option.

Using a ":" prefix for type ctor variables would break the other half of my
types in these libraries. I use type variables with names like (~>), (+>),
(-->) etc in order to express abstractions, and then I typically use those
abstractions to define concrete type ctors with names like (:->), (:+>),
(:-->), etc.

My regrets for raising these issues so late in the game.

-- Conal

On Fri, Sep 14, 2012 at 4:26 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  Fair point.  So you are saying it’d be ok to say****
>
> ** **
>
>   data T (.->)  = MkT (Int .-> Int)****
>
> ** **
>
> where (.+) is a type variable?   Leaving ordinary (+) available for type
> constructors.****
>
> ** **
>
> If we are inverting the convention I wonder whether we might invert it
> completely and use “:” as the “I’m different” herald as we do for **
> constructor** operators in terms.  Thus****
>
> ** **
>
>   data T (:->)  = MkT (Int :-> Int)****
>
> ** **
>
> That seems symmetrical, and perhaps nicer than having a new notation.  ***
> *
>
>                         ****
>
>          In terms                                      In types        ***
> *
>
> -----------------------------------------------------------------------***
> *
>
> a        Term variable                             Type variable****
>
> A        Data constructor                         Type constructor****
>
> +        Term variable operator               Type constructor operator***
> *
>
> :+      Data constructor operator           Type variable operator****
>
> ** **
>
> Any other opinions?****
>
> ** **
>
> Simon****
>
> ** **
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 06 September 2012 23:59
> *To:* Simon Peyton-Jones
> *Cc:* GHC users
> *Subject:* Re: Type operators in GHC****
>
> ** **
>
> Oh dear. I'm very sorry to have missed this discussion back in January.
> I'd be awfully sad to lose pretty infix notation for type variables of kind
> * -> * -> *. I use them extensively in my libraries and projects, and
> pretty notation matters.
>
> I'd be okay switching to some convention other than lack of leading ':'
> for signaling that a symbol is a type variable rather than constructor,
> e.g., the *presence* of a leading character such as '.'.
>
> Given the increasing use of arrow-ish techniques and of type-level
> programming, I would not classify the up-to-7.4 behavior as a "foolish
> consistency", especially going forward.
>
> -- Conal
>
> ****
>
> On Wed, Jan 18, 2012 at 6:27 AM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:****
>
> Dear GHC users
>
> As part of beefing up the kind system, we plan to implement the "Type
> operators" proposal for Haskell Prime
> http://hackage.haskell.org/trac/haskell-prime/wiki/InfixTypeConstructors
>
> GHC has had type operators for some kind, so you can say
>         data a :+: b = Left a | Right b
> but you can only do that for operators which start with ":".
>
> As part of the above wiki page you can see the proposal to broaden this to
> ALL operators, allowing
>         data a + b = Left a | Right b
>
> Although this technically inconsistent the value page (as the wiki page
> discussed), I think the payoff is huge. (And "A foolish consistency is the
> hobgoblin of little minds", Emerson)
>
>
> This email is (a) to highlight the plan, and (b) to ask about flags.  Our
> preferred approach is to *change* what -XTypeOperators does, to allow type
> operators that do not start with :.  But that will mean that *some*
> (strange) programs will stop working. The only example I have seen in tc192
> of GHC's test suite
>         {-# LANGUAGE TypeOperators #-}
>         comp :: Arrow (~>) => (b~>c, c~>d)~>(b~>d)
>       comp = arr (uncurry (>>>))
>
> Written more conventionally, the signature would look like
>         comp :: Arrow arr => arr (arr b c, arr c d) (arr b d)
>       comp = arr (uncurry (>>>))
> or, in infix notation
>         {-# LANGUAGE TypeOperators #-}
>         comp :: Arrow arr => (b `arr` c, c `arr` d) `arr` (b `arr` d)
>       comp = arr (uncurry (>>>))
>
> But tc192 as it stands would become ILLEGAL, because (~>) would be a type
> *constructor* rather than (as now) a type *variable*.  Of course it's
> easily fixed, as above, but still a breakage is a breakage.
>
> It would be possible to have two flags, so as to get
>   - Haskell 98 behaviour
>   - Current TypeOperator behaviuor
>   - New TypeOperator behaviour
> but it turns out to be Quite Tiresome to do so, and I would much rather
> not.  Can you live with that?
>
>
>
> http://chrisdone.com/posts/2010-10-07-haskelldb-and-typeoperator-madness.html
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120916/1b824016/attachment-0001.htm>