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
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@gmail.com [mailto:conal.elliott@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@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.htm...
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users****
** **
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users