Type operators in GHC

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Type operators in GHC

Simon Peyton Jones
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Brent Yorgey-2
On Wed, Jan 18, 2012 at 02:27:21PM +0000, Simon Peyton-Jones 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

This is not actually that strange.  Lots of code that works with
arrows uses type variables like (~>) or similar, and to have to change
to (b `arr` c) instead of (b ~> c) would be annoying.  For example,
check out the 'netwire' package:

  http://hackage.haskell.org/packages/archive/netwire/3.1.0/doc/html/Control-Wire-Types.html

I'm not sure at this point which way I would lean on the issue.
Having infix type constructors that don't have to start with : is
something I would like, too.  But I just thought I would point out
that code like tc192 is not as esoteric as you seem to think.

I do agree, however, that letting things like (~>) be EITHER type
constructors OR type variables depending on what is in scope is out of
the question: it's non-compositional and makes the parser's job quite
difficult.

-Brent

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Brandon Allbery
On Wed, Jan 18, 2012 at 10:42, Brent Yorgey <[hidden email]> wrote:
I'm not sure at this point which way I would lean on the issue.
Having infix type constructors that don't have to start with : is
something I would like, too.  But I just thought I would point out
that code like tc192 is not as esoteric as you seem to think.

I seem to recall @src outputting a Prelude definition for something (Monoid?) that used (*) as a type variable.

--
brandon s allbery                                      [hidden email]
wandering unix systems administrator (available)     (412) 475-9364 vm/sms


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Iavor Diatchki
Hello,

My preference would be to change the behavior of the "TypeOperator"
flag.  Here is my reasoning:
  * Having two operators with slightly different meanings would be
very confusing, not just for beginners but for everyone.
  * The two behaviors are not compatible in the sense that they can't
co-exist in the same language standard.  So something is bound to
break later on, and it'd be better to update packages now, before we
have grown a bigger code base that uses two incompatible extensions.
  * As I see it, having type-operator variables is useful in (some)
APIs (e.g., the parameters of the arrow classes), while type-operator
constructors are useful in defining concrete types/type-functions
(e.g., concrete implementations of arrows).  I expect that there are a
lot more concrete implementations than APIs (this is the whole point
of abstraction, after all!) so I think that it is a good trade-off to
use the nicer notation for the more common case.

-Iavor
PS: In the interest of fairness, I am also partial to the new notation
because I've been working on support for arithmetic at the type-level,
and seem to have developed a bit of an allergy to typing :+:, :*:, :<=
etc all the time :-)


On Wed, Jan 18, 2012 at 9:36 AM, Brandon Allbery <[hidden email]> wrote:

> On Wed, Jan 18, 2012 at 10:42, Brent Yorgey <[hidden email]> wrote:
>>
>> I'm not sure at this point which way I would lean on the issue.
>> Having infix type constructors that don't have to start with : is
>> something I would like, too.  But I just thought I would point out
>> that code like tc192 is not as esoteric as you seem to think.
>
>
> I seem to recall @src outputting a Prelude definition for something
> (Monoid?) that used (*) as a type variable.
>
> --
> brandon s allbery                                      [hidden email]
> wandering unix systems administrator (available)     (412) 475-9364 vm/sms
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Edward Kmett-2
In reply to this post by Simon Peyton Jones
I can live with it and I probably have as many packages as anyone that will be broken by it. =/

Things like


will need a pretty invasive rewrite, but the simplicity is worth it, and it makes for much better operators at the type level.

I can pre-emptively change the packages so as to be compatible with both, so I have an upgrade path, which makes it all good.

-Edward

On Wed, Jan 18, 2012 at 9:27 AM, Simon Peyton-Jones <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Joachim Breitner-2
In reply to this post by Simon Peyton Jones
Hello,

while I agree that operators are usually more useful als type
constructors than as type variables, I’m wondering if it is future-proof
to completely get rid of a possibility for infix type variables. With
the type class system getting stronger and stronger, would this not mean
that there will be more and more use cases for infix type variables?
Maybe the change should at keep a (small) window open. Maybe, similar to
the current situation, a special character to indicate variables, not
constructors?

(I have no good idea, but here is at least one: A dot '.' as the first
character indicates a type variable; compared to a ':' this is a
non-capitalized character).


Also, is there maybe another way of distinguishing constructors and
variables, besides capitalization, that works equally well for operators
and non-operators? That could also help if a user would like to use
unicode characters in the name of a constructor that are letters but
don’t have a upper or titlecase variant. But then, this has probably
been given thought a long time ago, without a better solution than
capitalization resp. leading ':'.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
  [hidden email]  |  [hidden email]  |  GPG: 0x4743206C
  xmpp: [hidden email] | http://www.joachim-breitner.de/


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

M Farkas-Dyck
On 19/01/2012, Joachim Breitner <[hidden email]> wrote:
> (I have no good idea, but here is at least one: A dot '.' as the first
> character indicates a type variable; compared to a ':' this is a
> non-capitalized character).

So that all symbols that start in dot are variables, and all others
are types/constructors?

> Also, is there maybe another way of distinguishing constructors and
> variables, besides capitalization, that works equally well for operators
> and non-operators? That could also help if a user would like to use
> unicode characters in the name of a constructor that are letters but
> don’t have a upper or titlecase variant. But then, this has probably
> been given thought a long time ago, without a better solution than
> capitalization resp. leading ':'.

Sometimes I thought to use "∀" to quantify over type variables, as
over term variables, at least as an option.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Joachim Breitner-2
Hi,

Am Donnerstag, den 19.01.2012, 07:11 -0500 schrieb Matthew Farkas-Dyck:
> On 19/01/2012, Joachim Breitner <[hidden email]> wrote:
> > (I have no good idea, but here is at least one: A dot '.' as the first
> > character indicates a type variable; compared to a ':' this is a
> > non-capitalized character).
>
> So that all symbols that start in dot are variables, and all others
> are types/constructors?

exactly, that would be an option to get the benefit of the proposal
(nicer type constructor operator names) without giving up completely on
type variable operators names.

Greetings,
Joachim
--
Joachim "nomeata" Breitner
  [hidden email]  |  [hidden email]  |  GPG: 0x4743206C
  xmpp: [hidden email] | http://www.joachim-breitner.de/


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Ian Lynagh
In reply to this post by M Farkas-Dyck
On Thu, Jan 19, 2012 at 07:11:19AM -0500, Matthew Farkas-Dyck wrote:
>
> Sometimes I thought to use "∀" to quantify over type variables, as
> over term variables, at least as an option.

Do you mean that in

    f :: (x, X, (+), (:+))

only x would be a type variable and X, (+), (:+) would be type
constructors, but that in

    g :: forall y, Y, (*), (:*) .
         (x, X, (+), (:+), y, Y, (*), (:*))

y, Y, (*), (:*) would be type variables and x, X, (+), (:+) would be
whatever is in scope (constructors, unless there is an enclosing forall
that binds them)?

Perhaps we should be heading towards a case-insensitive syntax for type
names.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

M Farkas-Dyck
On 19/01/2012, Ian Lynagh <[hidden email]> wrote:

> Do you mean that in
>
>     f :: (x, X, (+), (:+))
>
> only x would be a type variable and X, (+), (:+) would be type
> constructors, but that in
>
>     g :: forall y, Y, (*), (:*) .
>          (x, X, (+), (:+), y, Y, (*), (:*))
>
> y, Y, (*), (:*) would be type variables and x, X, (+), (:+) would be
> whatever is in scope (constructors, unless there is an enclosing forall
> that binds them)?

Just so.

> Perhaps we should be heading towards a case-insensitive syntax for type
> names.

I've often had that thought myself, for types and terms both. It would
make it much nicer to do general numeric computations in Haskell (e.g.
fluid mechanics) since one could use upper-case term names, which are
often customary. I actually designed a compiled-to-Haskell language
for just this reason (for fluid mechanics lab), but it's very crude.

That said, for word-names, the case-sensitive system we have is nice and brief.

>
> Thanks
> Ian
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Conal Elliott
In reply to this post by Simon Peyton Jones
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: Type operators in GHC

Simon Peyton Jones

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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

 


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Cale Gibbard
There's a fair amount of code out there which uses (~>) as a type
variable (we have ~10k lines of heavy arrow code at iPwn). It would be
*really* nice if that could be accommodated somehow. But the proposal
you just gave at least would allow for a textual substitution, so not
quite so bad as having to change everything to prefix notation.

On 14 September 2012 19:26, Simon Peyton-Jones <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]>
> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Sjoerd Visscher-2
+1. Making ":" the signal for type variables would break even more code, f.e. fclabels.

"~" almost means "variable", so I'd like that as a prefix.

Sjoerd

On Sep 15, 2012, at 2:09 AM, Cale Gibbard <[hidden email]> wrote:

> There's a fair amount of code out there which uses (~>) as a type
> variable (we have ~10k lines of heavy arrow code at iPwn). It would be
> *really* nice if that could be accommodated somehow. But the proposal
> you just gave at least would allow for a textual substitution, so not
> quite so bad as having to change everything to prefix notation.
>
> On 14 September 2012 19:26, Simon Peyton-Jones <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]>
>> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

--
Sjoerd Visscher
https://github.com/sjoerdvisscher/blog






_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Edward Kmett-2
In reply to this post by Simon Peyton Jones
One issue with this proposal is it makes it completely impossible to pick a type constructor operator that works with both older GHCs and 7.6.

It is a fairly elegant choice, but in practice it would force me and many others to stop using them completely for the next couple of years, as I wouldn't be able to support any users on older GHCs, or if I did I would have to export completely different operator names, and then the users would have to use conditional compilation to do different things with them. =/

As it is, I can and do at least choose : prefixed names for any type constructor I want to have be compatible with old GHCs.

Back when the change was initially proposed I think it was Igloo who suggested that it might be possible to allow the use of symbols as type variables if they were explicitly quantified by a forall.

Would that be a viable approach?

-Edward

On Fri, Sep 14, 2012 at 7:26 PM, Simon Peyton-Jones <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

 


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Conal Elliott
In reply to this post by Sjoerd Visscher-2
Hm. "~" is a sometimes-fine prefix for abstracting over arrowish things, but perhaps not so appealing for others doing pairish, sumish etc abstractions.

-- Conal

On Sat, Sep 15, 2012 at 4:47 AM, Sjoerd Visscher <[hidden email]> wrote:
+1. Making ":" the signal for type variables would break even more code, f.e. fclabels.

"~" almost means "variable", so I'd like that as a prefix.

Sjoerd

On Sep 15, 2012, at 2:09 AM, Cale Gibbard <[hidden email]> wrote:

> There's a fair amount of code out there which uses (~>) as a type
> variable (we have ~10k lines of heavy arrow code at iPwn). It would be
> *really* nice if that could be accommodated somehow. But the proposal
> you just gave at least would allow for a textual substitution, so not
> quite so bad as having to change everything to prefix notation.
>
> On 14 September 2012 19:26, Simon Peyton-Jones <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]>
>> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

--
Sjoerd Visscher
https://github.com/sjoerdvisscher/blog






_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Conal Elliott
In reply to this post by Cale Gibbard
I also have quite a lot of code (growing daily) that uses (~>) as a type variable. It's not the only such type variable, because some abstractions are about combining multiple arrowish things, e.g., more CT variations on Functor and Foldable that allow valuable flexibility missing in the standard library. In those cases, I typically use (+>) and (-->) as well.

-- Conal

On Fri, Sep 14, 2012 at 5:09 PM, Cale Gibbard <[hidden email]> wrote:
There's a fair amount of code out there which uses (~>) as a type
variable (we have ~10k lines of heavy arrow code at iPwn). It would be
*really* nice if that could be accommodated somehow. But the proposal
you just gave at least would allow for a textual substitution, so not
quite so bad as having to change everything to prefix notation.

On 14 September 2012 19:26, Simon Peyton-Jones <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]>
> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Conal Elliott
In reply to this post by Simon Peyton Jones
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

 



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Alexey Khudyakov
On Mon, Sep 17, 2012 at 1:07 AM, Conal Elliott <[hidden email]> wrote:
> 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.
>
What about treating operators as constructs unless they are mentioned
in the forall?

"~>" is constructor
> foo :: a ~> b

"~>" is variable
> foo :: forall a b (~>). a ~> b

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Type operators in GHC

Iavor Diatchki
In reply to this post by Conal Elliott
Hello,

I think that it would be a mistake to have two pragmas with incompatible behaviors:  for example, we would not be able to write modules that use Conal's libraries and, say, the type nats I've been working on.
If the main issue is the notation for arrows, has anoyone played with what can be done with the current (7.6) system?  I just thought of two variations that seem to provide a decent notation for writing arrow-ish programs.  The second one, in particular, mirrors the arrow notation at the value level, so perhaps that would be enough?

-Iavor


{-# LANGUAGE TypeOperators, KindSignatures #-}
module Test where

import Control.Category 

-- Variant 1: Post-fix annotation

type (a ---> b) c = c a b

f :: Category c => (x ---> y) c -> (y ---> z) c -> (x ---> z) c
f = undefined


-- Variant 2: Arrow notation

type a >-- (c :: * -> * -> *) = c a
type c --> b                  = c b

infix 2 >--
infix 1 -->

g :: Category c => (x >--c--> y) -> (y >--c--> z) -> (x >--c--> z)
g = undefined



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
12