From eacameron at gmail.com Tue Nov 1 23:13:42 2016
From: eacameron at gmail.com (Elliot Cameron)
Date: Tue, 1 Nov 2016 19:13:42 -0400
Subject: Type Level "Application" Operator
Message-ID:
Folks,
Has there been a discussion about adding a type-level operator "$" that
just mimics "$" at the value level?
type f $ x = f x
infixr 0 $
Things like monad transformer stacks would look more "stack-like" with this:
type App = ExceptT Err $ ReaderT Config $ LogT Text IO
Elliot Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From evincarofautumn at gmail.com Wed Nov 2 06:31:05 2016
From: evincarofautumn at gmail.com (Jon Purdy)
Date: Tue, 1 Nov 2016 23:31:05 -0700
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
+1 from me, if only as a nice-to-have—it would be good to flesh out some
standard type operators in general.
On Nov 1, 2016 4:14 PM, "Elliot Cameron" wrote:
> Folks,
>
> Has there been a discussion about adding a type-level operator "$" that
> just mimics "$" at the value level?
>
> type f $ x = f x
> infixr 0 $
>
> Things like monad transformer stacks would look more "stack-like" with
> this:
>
> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
>
> Elliot Cameron
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jeffbrown.the at gmail.com Wed Nov 2 07:31:55 2016
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Wed, 2 Nov 2016 00:31:55 -0700
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
+1! Readability improvements are wonderful.
On Tue, Nov 1, 2016 at 11:31 PM, Jon Purdy
wrote:
> +1 from me, if only as a nice-to-have—it would be good to flesh out some
> standard type operators in general.
>
> On Nov 1, 2016 4:14 PM, "Elliot Cameron" wrote:
>
>> Folks,
>>
>> Has there been a discussion about adding a type-level operator "$" that
>> just mimics "$" at the value level?
>>
>> type f $ x = f x
>> infixr 0 $
>>
>> Things like monad transformer stacks would look more "stack-like" with
>> this:
>>
>> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
>>
>> Elliot Cameron
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
--
Jeff Brown | Jeffrey Benjamin Brown
Website | Facebook
| LinkedIn
(I often miss messages
here) | Github
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Wed Nov 2 14:24:12 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 2 Nov 2016 10:24:12 -0400
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
+1, but the operator you're looking for in App there would actually be a
type level version of (.).
type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a
type App = ExceptT Err . ReaderT Config . LogT Text . IO
which would need
type (.) f g x = f (g x)
infixr 9 .
to parse
-Edward
On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron wrote:
> Folks,
>
> Has there been a discussion about adding a type-level operator "$" that
> just mimics "$" at the value level?
>
> type f $ x = f x
> infixr 0 $
>
> Things like monad transformer stacks would look more "stack-like" with
> this:
>
> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
>
> Elliot Cameron
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From oleg.grenrus at iki.fi Wed Nov 2 14:42:25 2016
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Wed, 2 Nov 2016 16:42:25 +0200
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
To make it clear:
type level `.` won’t work as an type synonym, as it’s application isn’t saturated.
{-# LANGUAGE TypeOperators #-}
type (:.:) f g x = f (g x)
infixr 9 :.:
type App = Maybe :.: []
fails to compile with following errors (for a reason):
• The type synonym ‘:.:’ should have 3 arguments, but has been given 2
• In the type synonym declaration for ‘App’
> On 02 Nov 2016, at 16:24, Edward Kmett wrote:
>
> +1, but the operator you're looking for in App there would actually be a type level version of (.).
>
> type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a
>
> type App = ExceptT Err . ReaderT Config . LogT Text . IO
>
> which would need
>
> type (.) f g x = f (g x)
> infixr 9 .
>
> to parse
>
> -Edward
>
> On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron wrote:
> Folks,
>
> Has there been a discussion about adding a type-level operator "$" that just mimics "$" at the value level?
>
> type f $ x = f x
> infixr 0 $
>
> Things like monad transformer stacks would look more "stack-like" with this:
>
> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
>
> Elliot Cameron
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From eacameron at gmail.com Wed Nov 2 14:54:51 2016
From: eacameron at gmail.com (Elliot Cameron)
Date: Wed, 2 Nov 2016 10:54:51 -0400
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
Edward,
I had the exact same thought but I couldn't get it to work. Oddly enough, I
actually copied and pasted that example from my code which builds and runs
perfectly well. It seems that monad transformers work differently when
defined as a type (instead of newtype, which would require me to include
the type parameter)?
Somewhat related is the question of how to actually *export* this type
alias from a module.
> module Money (($)) where
>
> type f $ x = f x
> infixr 0 $
doesn't work because it tries to export Prelude.$. The only way around it
is to import Prelude hiding (($)). But this makes me wonder, is it actually
*impossible* in Haskell to export from the same module a function with the
same name at both the value and type level? Is it possible to export only
one of the two?
Elliot
On Wed, Nov 2, 2016 at 10:42 AM, Oleg Grenrus wrote:
> To make it clear:
>
> type level `.` won’t work as an type synonym, as it’s application isn’t
> saturated.
>
> {-# LANGUAGE TypeOperators #-}
> type (:.:) f g x = f (g x)
> infixr 9 :.:
>
> type App = Maybe :.: []
>
> fails to compile with following errors (for a reason):
>
> • The type synonym ‘:.:’ should have 3 arguments, but has been given 2
> • In the type synonym declaration for ‘App’
>
> > On 02 Nov 2016, at 16:24, Edward Kmett wrote:
> >
> > +1, but the operator you're looking for in App there would actually be a
> type level version of (.).
> >
> > type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a
> >
> > type App = ExceptT Err . ReaderT Config . LogT Text . IO
> >
> > which would need
> >
> > type (.) f g x = f (g x)
> > infixr 9 .
> >
> > to parse
> >
> > -Edward
> >
> > On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron
> wrote:
> > Folks,
> >
> > Has there been a discussion about adding a type-level operator "$" that
> just mimics "$" at the value level?
> >
> > type f $ x = f x
> > infixr 0 $
> >
> > Things like monad transformer stacks would look more "stack-like" with
> this:
> >
> > type App = ExceptT Err $ ReaderT Config $ LogT Text IO
> >
> > Elliot Cameron
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ryan.gl.scott at gmail.com Wed Nov 2 15:33:57 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 2 Nov 2016 11:33:57 -0400
Subject: Type Level "Application" Operator
Message-ID:
> But this makes me wonder, is it actually *impossible* in Haskell to export from the same module a function with the same name at both the value and type level? Is it possible to export only one of the two?
It's quite possible. You just have to use the "type" namespace in your
export list to disambiguate the term-level and type-level ($)s:
{-# LANGUAGE TypeOperators #-}
module Money (($), type ($)) where
type f $ x = f x
infixr 0 $
Also, +1 on the original suggestion to add ($) to base.
Ryan S.
From ryan.gl.scott at gmail.com Wed Nov 2 15:40:08 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 2 Nov 2016 11:40:08 -0400
Subject: Proposal: Add Data instance for Const
Message-ID:
GHC Trac #12438 [1] exists because there's no Data instance for Const
in base. I found this quite surprising, since we have Data instances
for just about every other type combinator out there (Identity, Sum,
Product, Compose, etc.), but not for Const. The fix for #12438 would
be quite simple: I propose we add
deriving instance (Data a, Data b) => Data (Const a b)
to Data.Data in base. Any objections?
Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/12438
From emertens at gmail.com Wed Nov 2 15:41:47 2016
From: emertens at gmail.com (Eric Mertens)
Date: Wed, 2 Nov 2016 08:41:47 -0700
Subject: Proposal: Add Data instance for Const
In-Reply-To:
References:
Message-ID: <8E87D287-3CBE-4B2F-B990-9AE3EEDF014A@gmail.com>
> On Nov 2, 2016, at 8:40 AM, Ryan Scott wrote:
>
> GHC Trac #12438 [1] exists because there's no Data instance for Const
> in base. I found this quite surprising, since we have Data instances
> for just about every other type combinator out there (Identity, Sum,
> Product, Compose, etc.), but not for Const. The fix for #12438 would
> be quite simple: I propose we add
>
> deriving instance (Data a, Data b) => Data (Const a b)
>
> to Data.Data in base. Any objections?
Seems like an oversight worth correcting to me.
--
Eric
From ekmett at gmail.com Wed Nov 2 16:05:07 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 2 Nov 2016 12:05:07 -0400
Subject: Proposal: Add Data instance for Const
In-Reply-To:
References:
Message-ID:
Definitely an oversight.
On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott wrote:
> GHC Trac #12438 [1] exists because there's no Data instance for Const
> in base. I found this quite surprising, since we have Data instances
> for just about every other type combinator out there (Identity, Sum,
> Product, Compose, etc.), but not for Const. The fix for #12438 would
> be quite simple: I propose we add
>
> deriving instance (Data a, Data b) => Data (Const a b)
>
> to Data.Data in base. Any objections?
>
> Ryan S.
> -----
> [1] https://ghc.haskell.org/trac/ghc/ticket/12438
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Wed Nov 2 16:35:12 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 2 Nov 2016 12:35:12 -0400
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID: <773CBCA2-44CF-4074-B284-9ADFE9BB5B23@gmail.com>
To make . work, we'd need both the ability to parse . at the type level without the compiler flipping out and assuming it is part of a rank n signature (which was the first issue I was trying to mention) and a form of "Really LiberalTypeSynonyms" like we use in ermine to allow the partial application so long as App is only used applied to an argument.
In theory non recursive partial application of type synonyms within a type synonym is perfectly admissible in Haskell type checking, it just complicates the expansion and we don't do it today.
Both are solvable, but are nowhere near the low hanging fruit that adding $ would be.
-Edward
> On Nov 2, 2016, at 10:42 AM, Oleg Grenrus wrote:
>
> To make it clear:
>
> type level `.` won’t work as an type synonym, as it’s application isn’t saturated.
>
> {-# LANGUAGE TypeOperators #-}
> type (:.:) f g x = f (g x)
> infixr 9 :.:
>
> type App = Maybe :.: []
>
> fails to compile with following errors (for a reason):
>
> • The type synonym ‘:.:’ should have 3 arguments, but has been given 2
> • In the type synonym declaration for ‘App’
>
>> On 02 Nov 2016, at 16:24, Edward Kmett wrote:
>>
>> +1, but the operator you're looking for in App there would actually be a type level version of (.).
>>
>> type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a
>>
>> type App = ExceptT Err . ReaderT Config . LogT Text . IO
>>
>> which would need
>>
>> type (.) f g x = f (g x)
>> infixr 9 .
>>
>> to parse
>>
>> -Edward
>>
>> On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron wrote:
>> Folks,
>>
>> Has there been a discussion about adding a type-level operator "$" that just mimics "$" at the value level?
>>
>> type f $ x = f x
>> infixr 0 $
>>
>> Things like monad transformer stacks would look more "stack-like" with this:
>>
>> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
>>
>> Elliot Cameron
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vlad.z.4096 at gmail.com Wed Nov 2 19:11:43 2016
From: vlad.z.4096 at gmail.com (Index Int)
Date: Wed, 2 Nov 2016 22:11:43 +0300
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
Edward, I don't quite follow why you think that (.) is needed here.
Monad transformers take two parameters, so your example is not
type-correct, whereas the original one is.
On Wed, Nov 2, 2016 at 5:24 PM, Edward Kmett wrote:
> +1, but the operator you're looking for in App there would actually be a
> type level version of (.).
>
> type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a
>
> type App = ExceptT Err . ReaderT Config . LogT Text . IO
>
> which would need
>
> type (.) f g x = f (g x)
> infixr 9 .
>
> to parse
>
> -Edward
>
> On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron wrote:
>>
>> Folks,
>>
>> Has there been a discussion about adding a type-level operator "$" that
>> just mimics "$" at the value level?
>>
>> type f $ x = f x
>> infixr 0 $
>>
>> Things like monad transformer stacks would look more "stack-like" with
>> this:
>>
>> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
>>
>> Elliot Cameron
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
From vlad.z.4096 at gmail.com Wed Nov 2 19:16:51 2016
From: vlad.z.4096 at gmail.com (Index Int)
Date: Wed, 2 Nov 2016 22:16:51 +0300
Subject: Proposal: Add Data instance for Const
In-Reply-To:
References:
Message-ID:
The proposed instance is overconstrained. You only need Typeable for
the second argument of Const (because it is phantom).
On Wed, Nov 2, 2016 at 7:05 PM, Edward Kmett wrote:
> Definitely an oversight.
>
> On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott wrote:
>>
>> GHC Trac #12438 [1] exists because there's no Data instance for Const
>> in base. I found this quite surprising, since we have Data instances
>> for just about every other type combinator out there (Identity, Sum,
>> Product, Compose, etc.), but not for Const. The fix for #12438 would
>> be quite simple: I propose we add
>>
>> deriving instance (Data a, Data b) => Data (Const a b)
>>
>> to Data.Data in base. Any objections?
>>
>> Ryan S.
>> -----
>> [1] https://ghc.haskell.org/trac/ghc/ticket/12438
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
From ryan.gl.scott at gmail.com Wed Nov 2 19:27:39 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 2 Nov 2016 15:27:39 -0400
Subject: Proposal: Add Data instance for Const
In-Reply-To:
References:
Message-ID:
> The proposed instance is overconstrained. You only need Typeable for the
second argument of Const (because it is phantom).
It's a phantom type, but the Data constraint is necessary because the way
deriving Data works. If You can read this [1] for an explanation behind
this design decision. Essentially, if GHC sees that a datatype has two type
parameters of kind *, then it generates a definition for the dataCast2
method, which allows for a higher-order version of the cast function. But
implementing dataCast2 requires that both type parameters be Data instances.
A separate question would be whether implementing dataCast2 could be done
without these Data constraints (and thus allowing the second type parameter
to only be an instance of Typeable, rather than Data). But that is outside
my area of expertise; I'd need someone more knowledgeable in the arts of
Data.Data than I.
For now, I am proposing what GHC currently considers to be a canonical Data
instance for Const. We can revisit the exact instance context details later
if need be.
Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/4028
On Wed, Nov 2, 2016 at 3:16 PM, Index Int wrote:
> The proposed instance is overconstrained. You only need Typeable for
> the second argument of Const (because it is phantom).
>
> On Wed, Nov 2, 2016 at 7:05 PM, Edward Kmett wrote:
> > Definitely an oversight.
> >
> > On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott
> wrote:
> >>
> >> GHC Trac #12438 [1] exists because there's no Data instance for Const
> >> in base. I found this quite surprising, since we have Data instances
> >> for just about every other type combinator out there (Identity, Sum,
> >> Product, Compose, etc.), but not for Const. The fix for #12438 would
> >> be quite simple: I propose we add
> >>
> >> deriving instance (Data a, Data b) => Data (Const a b)
> >>
> >> to Data.Data in base. Any objections?
> >>
> >> Ryan S.
> >> -----
> >> [1] https://ghc.haskell.org/trac/ghc/ticket/12438
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vlad.z.4096 at gmail.com Wed Nov 2 20:17:49 2016
From: vlad.z.4096 at gmail.com (Index Int)
Date: Wed, 2 Nov 2016 23:17:49 +0300
Subject: Proposal: Add Data instance for Const
In-Reply-To:
References:
Message-ID:
You propose to add the line
deriving instance (Data a, Data b) => Data (Const a b)
to Data.Data in base. I entered it into GHCi with -ddump-deriv and
this is what I got:
ghci> deriving instance (Data a, Data b) => Data (Const a b)
==================== Derived instances ====================
Derived instances:
instance (Data.Data.Data a_a53b, Data.Data.Data b_a53c) =>
Data.Data.Data (Data.Functor.Const.Const a_a53b b_a53c) where
Data.Data.gfoldl k_a53f z_a53g (Data.Functor.Const.Const a1_a53h)
= (z_a53g Data.Functor.Const.Const `k_a53f` a1_a53h)
Data.Data.gunfold k_a53i z_a53j _
= k_a53i (z_a53j Data.Functor.Const.Const)
Data.Data.toConstr (Data.Functor.Const.Const _)
= Ghci4.$cBHDVlUg6FI9L4iOviG5mer
Data.Data.dataTypeOf _ = Ghci4.$tBHDVlUg6FI9L4iOviG5mer
Ghci4.$tBHDVlUg6FI9L4iOviG5mer :: Data.Data.DataType
Ghci4.$cBHDVlUg6FI9L4iOviG5mer :: Data.Data.Constr
Ghci4.$tBHDVlUg6FI9L4iOviG5mer
= Data.Data.mkDataType "Const" [Ghci4.$cBHDVlUg6FI9L4iOviG5mer]
Ghci4.$cBHDVlUg6FI9L4iOviG5mer
= Data.Data.mkConstr
Ghci4.$tBHDVlUg6FI9L4iOviG5mer
"Const"
["getConst"]
Data.Data.Prefix
So GHC does not generate a definition for dataCast2 (and it default to
`const Nothing`, I suppose). I tried the same with the constraint
relaxed to Typeable and it worked. Am I missing something?
On Wed, Nov 2, 2016 at 10:27 PM, Ryan Scott wrote:
>> The proposed instance is overconstrained. You only need Typeable for the
>> second argument of Const (because it is phantom).
>
> It's a phantom type, but the Data constraint is necessary because the way
> deriving Data works. If You can read this [1] for an explanation behind
> this design decision. Essentially, if GHC sees that a datatype has two type
> parameters of kind *, then it generates a definition for the dataCast2
> method, which allows for a higher-order version of the cast function. But
> implementing dataCast2 requires that both type parameters be Data instances.
>
> A separate question would be whether implementing dataCast2 could be done
> without these Data constraints (and thus allowing the second type parameter
> to only be an instance of Typeable, rather than Data). But that is outside
> my area of expertise; I'd need someone more knowledgeable in the arts of
> Data.Data than I.
>
> For now, I am proposing what GHC currently considers to be a canonical Data
> instance for Const. We can revisit the exact instance context details later
> if need be.
>
> Ryan S.
> -----
> [1] https://ghc.haskell.org/trac/ghc/ticket/4028
>
> On Wed, Nov 2, 2016 at 3:16 PM, Index Int wrote:
>>
>> The proposed instance is overconstrained. You only need Typeable for
>> the second argument of Const (because it is phantom).
>>
>> On Wed, Nov 2, 2016 at 7:05 PM, Edward Kmett wrote:
>> > Definitely an oversight.
>> >
>> > On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott
>> > wrote:
>> >>
>> >> GHC Trac #12438 [1] exists because there's no Data instance for Const
>> >> in base. I found this quite surprising, since we have Data instances
>> >> for just about every other type combinator out there (Identity, Sum,
>> >> Product, Compose, etc.), but not for Const. The fix for #12438 would
>> >> be quite simple: I propose we add
>> >>
>> >> deriving instance (Data a, Data b) => Data (Const a b)
>> >>
>> >> to Data.Data in base. Any objections?
>> >>
>> >> Ryan S.
>> >> -----
>> >> [1] https://ghc.haskell.org/trac/ghc/ticket/12438
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>> >
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>
>
From ryan.gl.scott at gmail.com Wed Nov 2 20:33:09 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 2 Nov 2016 16:33:09 -0400
Subject: Proposal: Add Data instance for Const
In-Reply-To:
References:
Message-ID:
Ah, right. I forgot about this additional wrinkle - GHC only checks the
kinds of each type variable at the definition site, not at the site of the
Data instance. And Const is poly-kinded, so its second type variable is of
kind k, not *, so that's why GHC forgoes defining dataCast2 here. My bad.
So in this case, I suppose it doesn't hurt to relax the second constraint
to Typeable. There's the separate issue of whether this is a "correct" Data
instance, but GHC won't allow us to derive dataCast2 for the Data (Const a
b) instance in the first place, so it's a bit of a moot point.
Ryan S.
On Wed, Nov 2, 2016 at 4:17 PM, Index Int wrote:
> You propose to add the line
>
> deriving instance (Data a, Data b) => Data (Const a b)
>
> to Data.Data in base. I entered it into GHCi with -ddump-deriv and
> this is what I got:
>
> ghci> deriving instance (Data a, Data b) => Data (Const a b)
>
> ==================== Derived instances ====================
> Derived instances:
> instance (Data.Data.Data a_a53b, Data.Data.Data b_a53c) =>
> Data.Data.Data (Data.Functor.Const.Const a_a53b b_a53c) where
> Data.Data.gfoldl k_a53f z_a53g (Data.Functor.Const.Const a1_a53h)
> = (z_a53g Data.Functor.Const.Const `k_a53f` a1_a53h)
> Data.Data.gunfold k_a53i z_a53j _
> = k_a53i (z_a53j Data.Functor.Const.Const)
> Data.Data.toConstr (Data.Functor.Const.Const _)
> = Ghci4.$cBHDVlUg6FI9L4iOviG5mer
> Data.Data.dataTypeOf _ = Ghci4.$tBHDVlUg6FI9L4iOviG5mer
>
> Ghci4.$tBHDVlUg6FI9L4iOviG5mer :: Data.Data.DataType
> Ghci4.$cBHDVlUg6FI9L4iOviG5mer :: Data.Data.Constr
> Ghci4.$tBHDVlUg6FI9L4iOviG5mer
> = Data.Data.mkDataType "Const" [Ghci4.$cBHDVlUg6FI9L4iOviG5mer]
> Ghci4.$cBHDVlUg6FI9L4iOviG5mer
> = Data.Data.mkConstr
> Ghci4.$tBHDVlUg6FI9L4iOviG5mer
> "Const"
> ["getConst"]
> Data.Data.Prefix
>
> So GHC does not generate a definition for dataCast2 (and it default to
> `const Nothing`, I suppose). I tried the same with the constraint
> relaxed to Typeable and it worked. Am I missing something?
>
> On Wed, Nov 2, 2016 at 10:27 PM, Ryan Scott
> wrote:
> >> The proposed instance is overconstrained. You only need Typeable for the
> >> second argument of Const (because it is phantom).
> >
> > It's a phantom type, but the Data constraint is necessary because the way
> > deriving Data works. If You can read this [1] for an explanation behind
> > this design decision. Essentially, if GHC sees that a datatype has two
> type
> > parameters of kind *, then it generates a definition for the dataCast2
> > method, which allows for a higher-order version of the cast function. But
> > implementing dataCast2 requires that both type parameters be Data
> instances.
> >
> > A separate question would be whether implementing dataCast2 could be done
> > without these Data constraints (and thus allowing the second type
> parameter
> > to only be an instance of Typeable, rather than Data). But that is
> outside
> > my area of expertise; I'd need someone more knowledgeable in the arts of
> > Data.Data than I.
> >
> > For now, I am proposing what GHC currently considers to be a canonical
> Data
> > instance for Const. We can revisit the exact instance context details
> later
> > if need be.
> >
> > Ryan S.
> > -----
> > [1] https://ghc.haskell.org/trac/ghc/ticket/4028
> >
> > On Wed, Nov 2, 2016 at 3:16 PM, Index Int wrote:
> >>
> >> The proposed instance is overconstrained. You only need Typeable for
> >> the second argument of Const (because it is phantom).
> >>
> >> On Wed, Nov 2, 2016 at 7:05 PM, Edward Kmett wrote:
> >> > Definitely an oversight.
> >> >
> >> > On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott
> >> > wrote:
> >> >>
> >> >> GHC Trac #12438 [1] exists because there's no Data instance for Const
> >> >> in base. I found this quite surprising, since we have Data instances
> >> >> for just about every other type combinator out there (Identity, Sum,
> >> >> Product, Compose, etc.), but not for Const. The fix for #12438 would
> >> >> be quite simple: I propose we add
> >> >>
> >> >> deriving instance (Data a, Data b) => Data (Const a b)
> >> >>
> >> >> to Data.Data in base. Any objections?
> >> >>
> >> >> Ryan S.
> >> >> -----
> >> >> [1] https://ghc.haskell.org/trac/ghc/ticket/12438
> >> >> _______________________________________________
> >> >> Libraries mailing list
> >> >> Libraries at haskell.org
> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Libraries mailing list
> >> > Libraries at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Wed Nov 2 22:27:59 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 2 Nov 2016 18:27:59 -0400
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
On Wed, Nov 2, 2016 at 3:11 PM, Index Int wrote:
> Edward, I don't quite follow why you think that (.) is needed here.
> Monad transformers take two parameters, so your example is not
> type-correct, whereas the original one is.
>
Indeed, I appear to have hyper-corrected that example.
-Edward
On Wed, Nov 2, 2016 at 5:24 PM, Edward Kmett wrote:
> > +1, but the operator you're looking for in App there would actually be a
> > type level version of (.).
> >
> > type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a
> >
> > type App = ExceptT Err . ReaderT Config . LogT Text . IO
> >
> > which would need
> >
> > type (.) f g x = f (g x)
> > infixr 9 .
> >
> > to parse
> >
> > -Edward
> >
> > On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron
> wrote:
> >>
> >> Folks,
> >>
> >> Has there been a discussion about adding a type-level operator "$" that
> >> just mimics "$" at the value level?
> >>
> >> type f $ x = f x
> >> infixr 0 $
> >>
> >> Things like monad transformer stacks would look more "stack-like" with
> >> this:
> >>
> >> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
> >>
> >> Elliot Cameron
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From novadenizen at gmail.com Wed Nov 2 23:36:04 2016
From: novadenizen at gmail.com (Ken Bateman)
Date: Wed, 2 Nov 2016 19:36:04 -0400
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
Wouldn't there also be a problem with type unification? When unifying ((f
. g) a) and (h b) do you set ((f . g) ~ h) or ((g a) ~ b)?
On Nov 2, 2016 6:28 PM, "Edward Kmett" wrote:
> On Wed, Nov 2, 2016 at 3:11 PM, Index Int wrote:
>
>> Edward, I don't quite follow why you think that (.) is needed here.
>> Monad transformers take two parameters, so your example is not
>> type-correct, whereas the original one is.
>>
>
> Indeed, I appear to have hyper-corrected that example.
>
> -Edward
>
> On Wed, Nov 2, 2016 at 5:24 PM, Edward Kmett wrote:
>> > +1, but the operator you're looking for in App there would actually be a
>> > type level version of (.).
>> >
>> > type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a
>> >
>> > type App = ExceptT Err . ReaderT Config . LogT Text . IO
>> >
>> > which would need
>> >
>> > type (.) f g x = f (g x)
>> > infixr 9 .
>> >
>> > to parse
>> >
>> > -Edward
>> >
>> > On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron
>> wrote:
>> >>
>> >> Folks,
>> >>
>> >> Has there been a discussion about adding a type-level operator "$" that
>> >> just mimics "$" at the value level?
>> >>
>> >> type f $ x = f x
>> >> infixr 0 $
>> >>
>> >> Things like monad transformer stacks would look more "stack-like" with
>> >> this:
>> >>
>> >> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
>> >>
>> >> Elliot Cameron
>> >>
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >>
>> >
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu Nov 3 00:05:32 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 2 Nov 2016 20:05:32 -0400
Subject: Discussion: add pattern synonyms and a non-dependent eliminator to
Numeric.Natural
In-Reply-To:
References:
Message-ID:
Pattern synonyms:
pattern Successor :: Natural -> Natural
pattern Successor n <- (precMaybe -> Just n)
where
Successor n = n + 1
precMaybe :: Natural -> Maybe Natural
precMaybe 0 = Nothing
precMaybe n = Just (n - 1)
pattern Zero :: Natural
pattern Zero = 0
Eliminator:
toChurch :: Natural -> (a -> a) -> a -> a
toChurch 0 _ b = b
toChurch n f b = f (toChurch (n-1) f b)
There are several other possible argument orders, the most natural of which
is probably
natural :: a -> (a -> a) -> Natural
I don't have particularly strong feelings about whether we should pick one
or offer both.
There are two strictly accumulating versions, corresponding to different
versions of foldl'. But toChurch/natural is sufficient to define them:
toChurch', toChurch'' :: Natural -> (a -> a) -> a -> a
toChurch' n f = toChurch n (\r acc -> r $! f acc) id
toChurch'' n f = toChurch n (\r !acc -> r $ f acc) id
So we shouldn't necessarily feel obligated to include those. I doubt the
time is ripe for a dependent eliminator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Thu Nov 3 01:01:37 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 2 Nov 2016 21:01:37 -0400
Subject: Type Level "Application" Operator
In-Reply-To:
References:
Message-ID:
Even with "ReallyLiberalTypeSynonyms" you can't have (f . g) ~ h as that
would involve a partial application in a non type synonym, so there is no
issue with unification.
(.) only means something with all 3 arguments applied so that it can be
expanded, but you can still allow it to be formally passed around inside
other type synonyms so long as the final type synonym has all of its
arguments expanded.
type (.) f g x = f (g x)
type Foo = (.) Bar
Foo doesn't fully instantiate (.) but you can keep eta expanding it until
it does.
type Foo g x = (.) Bar g x = Bar (g x)
is a perfectly legitimate definition. You can do this expansion
automatically pretty easily. Given such a type synonym you can answer how
many arguments it must have before it is a real type.
At a use site Foo is not a type until it has been applied to two more
arguments, just like the eta expanded form above. Foo ~ Baz doesn't type
check for the same reason given
type Id a = a
you can't talk about Id ~ Bar. Id isn't a type. It needs an argument before
it makes sense.
This is what I mean by "ReallyLiberalTypeSynonyms". We actually wound up
with these by accident in the Ermine compiler we use at work, and they
turned out to be quite useful and harmless in practice.
We don't have this power today, but we do have LiberalTypeSynonyms, which
gets us close.
-Edward
On Wed, Nov 2, 2016 at 7:36 PM, Ken Bateman wrote:
> Wouldn't there also be a problem with type unification? When unifying ((f
> . g) a) and (h b) do you set ((f . g) ~ h) or ((g a) ~ b)?
>
> On Nov 2, 2016 6:28 PM, "Edward Kmett" wrote:
>
>> On Wed, Nov 2, 2016 at 3:11 PM, Index Int wrote:
>>
>>> Edward, I don't quite follow why you think that (.) is needed here.
>>> Monad transformers take two parameters, so your example is not
>>> type-correct, whereas the original one is.
>>>
>>
>> Indeed, I appear to have hyper-corrected that example.
>>
>> -Edward
>>
>> On Wed, Nov 2, 2016 at 5:24 PM, Edward Kmett wrote:
>>> > +1, but the operator you're looking for in App there would actually be
>>> a
>>> > type level version of (.).
>>> >
>>> > type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a
>>> >
>>> > type App = ExceptT Err . ReaderT Config . LogT Text . IO
>>> >
>>> > which would need
>>> >
>>> > type (.) f g x = f (g x)
>>> > infixr 9 .
>>> >
>>> > to parse
>>> >
>>> > -Edward
>>> >
>>> > On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron
>>> wrote:
>>> >>
>>> >> Folks,
>>> >>
>>> >> Has there been a discussion about adding a type-level operator "$"
>>> that
>>> >> just mimics "$" at the value level?
>>> >>
>>> >> type f $ x = f x
>>> >> infixr 0 $
>>> >>
>>> >> Things like monad transformer stacks would look more "stack-like" with
>>> >> this:
>>> >>
>>> >> type App = ExceptT Err $ ReaderT Config $ LogT Text IO
>>> >>
>>> >> Elliot Cameron
>>> >>
>>> >> _______________________________________________
>>> >> Libraries mailing list
>>> >> Libraries at haskell.org
>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>> >
>>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Nov 6 17:37:48 2016
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 6 Nov 2016 17:37:48 +0000
Subject: Proposal: relax type of asProxyTypeOf
Message-ID: <20161106173748.GJ6044@weber>
Did anything ever come of this proposal to relax the type of asProxyType of?
https://mail.haskell.org/pipermail/libraries/2014-December/024462.html
i.e. change
asProxyTypeOf :: a -> Proxy a -> a
to
asProxyTypeOf :: a -> proxy a -> a
I posted this issue on the Trac
https://ghc.haskell.org/trac/ghc/ticket/12805
but it was suggested I ask on the libraries list.
Tom
From david.feuer at gmail.com Sun Nov 6 19:31:07 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 6 Nov 2016 14:31:07 -0500
Subject: Proposal: relax type of asProxyTypeOf
In-Reply-To: <20161106173748.GJ6044@weber>
References: <20161106173748.GJ6044@weber>
Message-ID:
I think flexibility about the proxy type has become the norm, and we should
probably follow that guideline. However, it could theoretically break code.
asProxyTypeOf x (pure "I'm a string")
is currently accepted but would be rejected with the proposed change (since
the proxy type isn't fixed, GHC doesn't know that it's Applicative).
On Nov 6, 2016 12:37 PM, "Tom Ellis" <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
> Did anything ever come of this proposal to relax the type of asProxyType
> of?
>
> https://mail.haskell.org/pipermail/libraries/2014-December/024462.html
>
> i.e. change
>
> asProxyTypeOf :: a -> Proxy a -> a
>
> to
>
> asProxyTypeOf :: a -> proxy a -> a
>
> I posted this issue on the Trac
>
> https://ghc.haskell.org/trac/ghc/ticket/12805
>
> but it was suggested I ask on the libraries list.
>
> Tom
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Mon Nov 7 01:08:01 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 6 Nov 2016 20:08:01 -0500
Subject: Proposal: relax type of asProxyTypeOf
In-Reply-To:
References: <20161106173748.GJ6044@weber>
Message-ID:
The code in `tagged` has been generalized for a couple of years now, but
Data.Proxy either forked off of it before we made that generalization or
simply didn't get the more generalized type when it was moved into base.
I'm strongly +1 on this generalization for consistency with the tagged
package and with the other combinators already in base.
-Edward
On Sun, Nov 6, 2016 at 2:31 PM, David Feuer wrote:
> I think flexibility about the proxy type has become the norm, and we
> should probably follow that guideline. However, it could theoretically
> break code.
>
> asProxyTypeOf x (pure "I'm a string")
>
> is currently accepted but would be rejected with the proposed change
> (since the proxy type isn't fixed, GHC doesn't know that it's Applicative).
>
> On Nov 6, 2016 12:37 PM, "Tom Ellis" jaguarpaw.co.uk> wrote:
>
>> Did anything ever come of this proposal to relax the type of asProxyType
>> of?
>>
>> https://mail.haskell.org/pipermail/libraries/2014-December/
>> 024462.html
>>
>> i.e. change
>>
>> asProxyTypeOf :: a -> Proxy a -> a
>>
>> to
>>
>> asProxyTypeOf :: a -> proxy a -> a
>>
>> I posted this issue on the Trac
>>
>> https://ghc.haskell.org/trac/ghc/ticket/12805
>>
>> but it was suggested I ask on the libraries list.
>>
>> Tom
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ryan.gl.scott at gmail.com Mon Nov 7 13:49:37 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 7 Nov 2016 08:49:37 -0500
Subject: Proposal: relax type of asProxyTypeOf
Message-ID:
Oh, I didn't realize that the type had already been generalized in tagged!
[1]
I'm certainly +1 on this proposal.
Ryan S.
-----
[1]
https://github.com/ekmett/tagged/blob/93cd87830733ed641409a2a14776973e8be600cc/old/Data/Proxy.hs#L264
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fumiexcel at gmail.com Wed Nov 9 08:54:01 2016
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Wed, 9 Nov 2016 17:54:01 +0900
Subject: Proposal: relax type of asProxyTypeOf
In-Reply-To: <20161106173748.GJ6044@weber>
References: <20161106173748.GJ6044@weber>
Message-ID:
Strong +1 from me
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From baldurpet at gmail.com Mon Nov 14 18:11:59 2016
From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=)
Date: Mon, 14 Nov 2016 18:11:59 +0000
Subject: =?UTF-8?B?UHJvcG9zYWw6IEFkZCDigJh0eXBlIGYgfj4gZyA9IGZvcmFsbCBhLiBmIGEgLT4gZyBh?=
=?UTF-8?B?4oCZ?=
Message-ID:
What the subject says, add
type f ~> g = forall a. f a -> g a
to ‘base’. Further motivation (and arguments against) in GHC Trac ticket
12772 [1].
[1] https://ghc.haskell.org/trac/ghc/ticket/12772
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From emertens at gmail.com Mon Nov 14 18:36:31 2016
From: emertens at gmail.com (Eric Mertens)
Date: Mon, 14 Nov 2016 18:36:31 +0000
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsOiBBZGQg4oCYdHlwZSBmIH4+IGcgPSBmb3JhbGwgYS4gZiBhIC0+IA==?=
=?UTF-8?B?ZyBh4oCZ?=
In-Reply-To:
References:
Message-ID:
I'd prefer that we didn't prescribe a meaning to this generally useful type
operator. This type synonym is very easy to define in any module where it's
appropriate.
On Mon, Nov 14, 2016 at 10:12 AM Baldur Blöndal wrote:
> What the subject says, add
>
> type f ~> g = forall a. f a -> g a
>
> to ‘base’. Further motivation (and arguments against) in GHC Trac ticket
> 12772 [1].
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/12772
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Mon Nov 14 20:21:54 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 14 Nov 2016 15:21:54 -0500
Subject: Proposal: Add portable eliminator for Data.Type.Equality
Message-ID:
Most of Data.Type.Equality can be supported by any Haskell
implementation with Rank2Types and TypeOperators, using, for example,
the well-known definition
newtype a :~: b = Equality { subst :: forall f . f a -> f b }
(The parts that can't be supported so are the gcastWith function, the
~~ constraint, and the == type family.)
What's most prominently missing is the ability to *use* equality for
anything beyond castWith without leaning on GHC's equality
constraints.
I propose that we add the eliminator subst as a function:
subst :: a :~: b -> f a -> f b
subst Refl x = x
Note that we already have an introduction rule
Control.Category.id :: a :~: a
David Feuer
From david.feuer at gmail.com Mon Nov 14 20:28:00 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 14 Nov 2016 15:28:00 -0500
Subject: Proposal: Add portable eliminator for Data.Type.Equality
In-Reply-To:
References:
Message-ID:
Further support for my proposal: we already have the analogous partial version
Data.Typeable.gcast :: forall a b c. (Typeable a, Typeable b) => c a
-> Maybe (c b)
On Mon, Nov 14, 2016 at 3:21 PM, David Feuer wrote:
> Most of Data.Type.Equality can be supported by any Haskell
> implementation with Rank2Types and TypeOperators, using, for example,
> the well-known definition
>
> newtype a :~: b = Equality { subst :: forall f . f a -> f b }
>
> (The parts that can't be supported so are the gcastWith function, the
> ~~ constraint, and the == type family.)
>
> What's most prominently missing is the ability to *use* equality for
> anything beyond castWith without leaning on GHC's equality
> constraints.
>
> I propose that we add the eliminator subst as a function:
>
> subst :: a :~: b -> f a -> f b
> subst Refl x = x
>
> Note that we already have an introduction rule
>
> Control.Category.id :: a :~: a
>
> David Feuer
From johnw at newartisans.com Mon Nov 14 21:48:01 2016
From: johnw at newartisans.com (John Wiegley)
Date: Mon, 14 Nov 2016 13:48:01 -0800
Subject: Proposal: Add =?utf-8?Q?=E2=80=98type?= f ~> g = forall a. f a
-> g =?utf-8?Q?a=E2=80=99?=
In-Reply-To:
(Eric Mertens's message of "Mon, 14 Nov 2016 18:36:31 +0000")
References:
Message-ID:
>>>>> "EM" == Eric Mertens writes:
EM> I'd prefer that we didn't prescribe a meaning to this generally useful
EM> type operator. This type synonym is very easy to define in any module
EM> where it's appropriate.
I agree. Taking "~>" for natural transformations seems too specific.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
From winterkoninkje at gmail.com Tue Nov 15 05:24:42 2016
From: winterkoninkje at gmail.com (wren romano)
Date: Mon, 14 Nov 2016 21:24:42 -0800
Subject: Proposal: Add portable eliminator for Data.Type.Equality
In-Reply-To:
References:
Message-ID:
On Mon, Nov 14, 2016 at 12:21 PM, David Feuer wrote:
> I propose that we add the eliminator subst as a function:
>
> subst :: a :~: b -> f a -> f b
> subst Refl x = x
I'm all for adding this function, but do note that the type is
suboptimal since GHC lacks general functions (and higher-order pattern
matching) at the type level. Which means we'll actually end up wanting
a family of different "subst" functions to cover all the (relevant)
cases the definition above would cover in a language like Agda, Coq,
etc.
E.g.,
Prelude> let x :: Either Bool Int; x = Right 42
Prelude> :t (`subst` x)
(`subst` x) :: Int :~: b -> Either Bool b
When I might've really wanted/meant (Bool :~: b -> Either b Int)
--
Live well,
~wren
From winterkoninkje at gmail.com Tue Nov 15 05:28:39 2016
From: winterkoninkje at gmail.com (wren romano)
Date: Mon, 14 Nov 2016 21:28:39 -0800
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsOiBBZGQg4oCYdHlwZSBmIH4+IGcgPSBmb3JhbGwgYS4gZiBhIC0+IA==?=
=?UTF-8?B?ZyBh4oCZ?=
In-Reply-To:
References:
Message-ID:
I agree too. I use the name (~>) whenever I have some profunctor-like
type variable. Putting it in a library would be like defining "x" or
"a" in a library. Certainly natural transformations are helpful to
have a library around, but they should be given a better name.
On Mon, Nov 14, 2016 at 1:48 PM, John Wiegley wrote:
>>>>>> "EM" == Eric Mertens writes:
>
> EM> I'd prefer that we didn't prescribe a meaning to this generally useful
> EM> type operator. This type synonym is very easy to define in any module
> EM> where it's appropriate.
>
> I agree. Taking "~>" for natural transformations seems too specific.
>
> --
> John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
Live well,
~wren
From david.feuer at gmail.com Tue Nov 15 05:37:17 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 15 Nov 2016 00:37:17 -0500
Subject: Proposal: Add portable eliminator for Data.Type.Equality
In-Reply-To:
References:
Message-ID:
On Nov 15, 2016 12:24 AM, "wren romano" wrote:
> > subst :: a :~: b -> f a -> f b
> > subst Refl x = x
>
> I'm all for adding this function, but do note that the type is
> suboptimal since GHC lacks general functions (and higher-order pattern
> matching) at the type level. Which means we'll actually end up wanting
> a family of different "subst" functions to cover all the (relevant)
> cases the definition above would cover in a language like Agda, Coq,
> etc.
Yes, we will, but those can be written using `subst` and one or more
auxiliary types without additional "primitive" eliminators (see below).
> E.g.,
>
> Prelude> let x :: Either Bool Int; x = Right 42
>
> Prelude> :t (`subst` x)
> (`subst` x) :: Int :~: b -> Either Bool b
>
> When I might've really wanted/meant (Bool :~: b -> Either b Int)
We can write
newtype Flip f x y = Flip { unFlip :: f y x }
subst2 :: a :~: b -> f a x -> f b x
subst2 eq = unFlip . subst eq . Flip
The subst2 function will work on the left side of Either.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From oleg.grenrus at iki.fi Tue Nov 15 09:01:53 2016
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Tue, 15 Nov 2016 11:01:53 +0200
Subject: =?utf-8?Q?Re=3A_Proposal=3A_Add_=E2=80=98type_f_=7E=3E_g_=3D_for?=
=?utf-8?Q?all_a=2E_f_a_-=3E_g_a=E2=80=99?=
In-Reply-To:
References:
Message-ID: <39F7FE10-DA2D-4253-BEAB-B6ABE41B2A2D@iki.fi>
FWIW, i personally use `natural-transformation` library [1], which
provides this exact type alias, and also newtype around it (which is occasionally useful).
I’d rather promote the usage of the library (which has only `base` as dependency!).
- [1]: https://hackage.haskell.org/package/natural-transformation-0.3.1/docs/Control-Natural.html
> On 14 Nov 2016, at 20:11, Baldur Blöndal wrote:
>
> What the subject says, add
>
> type f ~> g = forall a. f a -> g a
>
> to ‘base’. Further motivation (and arguments against) in GHC Trac ticket 12772 [1].
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/12772
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From oleg.grenrus at iki.fi Tue Nov 15 09:13:12 2016
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Tue, 15 Nov 2016 11:13:12 +0200
Subject: Proposal: Add portable eliminator for Data.Type.Equality
In-Reply-To:
References:
Message-ID: <996E7FBA-41D4-47DD-BEE6-CEC1EB681D7B@iki.fi>
I’m -1
λ Prelude Data.Type.Equality > :t (`gcastWith` x) :: b :~: Bool -> Either b Int
(`gcastWith` x) :: b :~: Bool -> Either b Int
:: b :~: Bool -> Either b Int
gcastWith :: (a :~: b) -> (a ~ b => r) -> r
That type “unifies" with subst :: (a :~: b) -> c a -> c b (and is more “general”), if stare at it for long enough.
- Oleg
P.S. FWIW there is PR [1] to `eq` [2], if you want to play with Leibniz equality definition.
- [1]: http://hackage.haskell.org/package/eq
- [2]: https://github.com/ekmett/eq/pull/9/files
> On 15 Nov 2016, at 07:37, David Feuer wrote:
>
> On Nov 15, 2016 12:24 AM, "wren romano" wrote:
> > > subst :: a :~: b -> f a -> f b
> > > subst Refl x = x
> >
> > I'm all for adding this function, but do note that the type is
> > suboptimal since GHC lacks general functions (and higher-order pattern
> > matching) at the type level. Which means we'll actually end up wanting
> > a family of different "subst" functions to cover all the (relevant)
> > cases the definition above would cover in a language like Agda, Coq,
> > etc.
>
> Yes, we will, but those can be written using `subst` and one or more auxiliary types without additional "primitive" eliminators (see below).
>
> > E.g.,
> >
> > Prelude> let x :: Either Bool Int; x = Right 42
> >
> > Prelude> :t (`subst` x)
> > (`subst` x) :: Int :~: b -> Either Bool b
> >
> > When I might've really wanted/meant (Bool :~: b -> Either b Int)
>
> We can write
>
> newtype Flip f x y = Flip { unFlip :: f y x }
>
> subst2 :: a :~: b -> f a x -> f b x
> subst2 eq = unFlip . subst eq . Flip
>
> The subst2 function will work on the left side of Either.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From ekmett at gmail.com Tue Nov 15 12:02:05 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 15 Nov 2016 07:02:05 -0500
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsOiBBZGQg4oCYdHlwZSBmIH4+IGcgPSBmb3JhbGwgYS4gZiBhIC0+IA==?=
=?UTF-8?B?ZyBh4oCZ?=
In-Reply-To: <39F7FE10-DA2D-4253-BEAB-B6ABE41B2A2D@iki.fi>
References:
<39F7FE10-DA2D-4253-BEAB-B6ABE41B2A2D@iki.fi>
Message-ID:
I'm -1 on the proposal of adding this type to base.
One one hand, natural-transformation already provides this definition in a
"centralized" locale for folks who really do want to share it with a
ridiculously stripped down set of dependencies, which provides a place for
those who really want to get it from a central location as well. Not as
nice as no dependency at all in a world where we could all agree this is
the best thing to add to base, but darn close.
On the other:
As a type alias there is no real compatibility gain to be had. If both of
us define (~>) as above, then types written with types against my (~>) and
types written against your (~>) are *freely interchangeable*, even if you
might have to play with your import lists more carefully.
We can't hang any instances off of it, so almost all of the standard
arguments for moving it "closer to base" fail to take effect.
On the other, other hand, something like
newtype f ~> g = Nat { runNat :: forall a. f a -> g a }
is slightly easier to make a case for, because you can hang instances off
of it and share more than one line of code, but I'd be -1 on that as well,
because there are a host of issues with that definition as well not being
"one size fits all" either.
There are several viable definitions for a natural transformation depending
on how general you want to get -- and this one (like the one in
natural-transformation) conflates parametricity with naturality, so rapidly
stops being good enough as you drift into PolyKinds and then start wanting
a more accurate Category and Functor notions, which then force you to
parameterize over the underlying `->` in the definition.
Both of these definitions occupy awkward suboptimal points in the design
space, so I'd rather not see us locked into their use by enshrining either
one in base.
-Edward
On Tue, Nov 15, 2016 at 4:01 AM, Oleg Grenrus wrote:
> FWIW, i personally use `natural-transformation` library [1], which
> provides this exact type alias, and also newtype around it (which is
> occasionally useful).
>
> I’d rather promote the usage of the library (which has only `base` as
> dependency!).
>
> - [1]: https://hackage.haskell.org/package/natural-
> transformation-0.3.1/docs/Control-Natural.html
>
> On 14 Nov 2016, at 20:11, Baldur Blöndal wrote:
>
> What the subject says, add
>
> type f ~> g = forall a. f a -> g a
>
> to ‘base’. Further motivation (and arguments against) in GHC Trac ticket
> 12772 [1].
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/12772
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Tue Nov 15 20:09:54 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 15 Nov 2016 15:09:54 -0500
Subject: Proposal: Add portable eliminator for Data.Type.Equality
In-Reply-To: <996E7FBA-41D4-47DD-BEE6-CEC1EB681D7B@iki.fi>
References:
<996E7FBA-41D4-47DD-BEE6-CEC1EB681D7B@iki.fi>
Message-ID:
Yes, gcastWith is certainly "more general" than subst. Exporting subst
from Data.Type.Equality would allow programmers to write code that
doesn't *care* how :~: is represented.
On Tue, Nov 15, 2016 at 4:13 AM, Oleg Grenrus wrote:
> I’m -1
>
> λ Prelude Data.Type.Equality > :t (`gcastWith` x) :: b :~: Bool -> Either b Int
> (`gcastWith` x) :: b :~: Bool -> Either b Int
> :: b :~: Bool -> Either b Int
>
> gcastWith :: (a :~: b) -> (a ~ b => r) -> r
>
> That type “unifies" with subst :: (a :~: b) -> c a -> c b (and is more “general”), if stare at it for long enough.
>
> - Oleg
>
> P.S. FWIW there is PR [1] to `eq` [2], if you want to play with Leibniz equality definition.
>
> - [1]: http://hackage.haskell.org/package/eq
> - [2]: https://github.com/ekmett/eq/pull/9/files
>
>> On 15 Nov 2016, at 07:37, David Feuer wrote:
>>
>> On Nov 15, 2016 12:24 AM, "wren romano" wrote:
>> > > subst :: a :~: b -> f a -> f b
>> > > subst Refl x = x
>> >
>> > I'm all for adding this function, but do note that the type is
>> > suboptimal since GHC lacks general functions (and higher-order pattern
>> > matching) at the type level. Which means we'll actually end up wanting
>> > a family of different "subst" functions to cover all the (relevant)
>> > cases the definition above would cover in a language like Agda, Coq,
>> > etc.
>>
>> Yes, we will, but those can be written using `subst` and one or more auxiliary types without additional "primitive" eliminators (see below).
>>
>> > E.g.,
>> >
>> > Prelude> let x :: Either Bool Int; x = Right 42
>> >
>> > Prelude> :t (`subst` x)
>> > (`subst` x) :: Int :~: b -> Either Bool b
>> >
>> > When I might've really wanted/meant (Bool :~: b -> Either b Int)
>>
>> We can write
>>
>> newtype Flip f x y = Flip { unFlip :: f y x }
>>
>> subst2 :: a :~: b -> f a x -> f b x
>> subst2 eq = unFlip . subst eq . Flip
>>
>> The subst2 function will work on the left side of Either.
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
From drkoster at qq.com Thu Nov 17 02:43:16 2016
From: drkoster at qq.com (winter)
Date: Thu, 17 Nov 2016 10:43:16 +0800
Subject: Add ifThenElse and (?) to Data.Bool
Message-ID: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
It seems this’s a very old request, see https://wiki.haskell.org/If-then-else . I’d like to see following:
ifThenElse :: Bool -> a -> a -> a
ifThenElse True x _ = x
ifThenElse False _ y = y
infixr 1 ?
(?) :: Bool -> a -> a -> a
(?) = ifThenElse
in Date.Bool module, it will have advantages that:
+ It’s more composable than syntax.
+ Write (xxx ? yyy $ zzz) instead of (if xxx then yyy else zzz) is more consistent with (f . g $ x) style, and save key strokes.
+ In module with RebindableSyntax enabled, you can import ifThenElse to get default behavior.
Whether or not to be exported by Prelude is another question, but Data.Bool seems a good place to start with.
Cheers~
Winter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu Nov 17 03:03:17 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 16 Nov 2016 22:03:17 -0500
Subject: Add ifThenElse and (?) to Data.Bool
In-Reply-To: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
References: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
Message-ID:
If ifThenElse is good for RebindableSyntax, then I'm +1 on that (but I've
never played with that extension, so I don't really know). I'm -1 on (?).
We already have bool, which tends to be rather more useful when partially
applied.
On Nov 16, 2016 9:43 PM, "winter" wrote:
> It seems this’s a very old request, see https://wiki.haskell.org/If-then-else. I’d like to see following:
>
>
> ifThenElse :: Bool -> a -> a -> a
> ifThenElse True x _ = xifThenElse False _ y = y
>
>
> infixr 1 ?(?) :: Bool -> a -> a -> a(?) = ifThenElse
>
>
> in Date.Bool module, it will have advantages that:
>
>
> + It’s more composable than syntax.
>
> + Write (xxx ? yyy $ zzz) instead of (if xxx then yyy else zzz) is more consistent with (f . g $ x) style, and save key strokes.
>
> + In module with RebindableSyntax enabled, you can import ifThenElse to get default behavior.
>
>
> Whether or not to be exported by Prelude is another question, but Data.Bool seems a good place to start with.
>
>
> Cheers~
>
> Winter
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From m.farkasdyck at gmail.com Thu Nov 17 03:06:41 2016
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Wed, 16 Nov 2016 19:06:41 -0800
Subject: Add ifThenElse and (?) to Data.Bool
In-Reply-To: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
References: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
Message-ID:
Could we use `bool` rather than add a new term for RebindableSyntax?
i.e. define if-then-else in terms of `bool`.
From drkoster at qq.com Thu Nov 17 03:16:19 2016
From: drkoster at qq.com (winter)
Date: Thu, 17 Nov 2016 11:16:19 +0800
Subject: Add ifThenElse and (?) to Data.Bool
In-Reply-To:
References: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
Message-ID: <567AE701-1827-4CD1-B164-5E4A3E1C5413@qq.com>
I’m totally aware of the existence of bool, i suppose (?) is mainly used in fully application to get a different style than if-then-else syntax, say,
...
isGoo <- checkGoo
isGoo ? goo
$ woo
...
But like what the wiki suggested, (?) can be used in some high-order situations. I like this operator because the mnemonic of questioning meaning.
> On 17 Nov 2016, at 11:03, David Feuer wrote:
>
> If ifThenElse is good for RebindableSyntax, then I'm +1 on that (but I've never played with that extension, so I don't really know). I'm -1 on (?). We already have bool, which tends to be rather more useful when partially applied.
>
>
> On Nov 16, 2016 9:43 PM, "winter" > wrote:
> It seems this’s a very old request, see https://wiki.haskell.org/If-then-else . I’d like to see following:
>
> ifThenElse :: Bool -> a -> a -> a
> ifThenElse True x _ = x
> ifThenElse False _ y = y
>
> infixr 1 ?
> (?) :: Bool -> a -> a -> a
> (?) = ifThenElse
>
> in Date.Bool module, it will have advantages that:
>
> + It’s more composable than syntax.
> + Write (xxx ? yyy $ zzz) instead of (if xxx then yyy else zzz) is more consistent with (f . g $ x) style, and save key strokes.
> + In module with RebindableSyntax enabled, you can import ifThenElse to get default behavior.
>
> Whether or not to be exported by Prelude is another question, but Data.Bool seems a good place to start with.
>
> Cheers~
> Winter
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu Nov 17 03:25:17 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 16 Nov 2016 22:25:17 -0500
Subject: Add ifThenElse and (?) to Data.Bool
In-Reply-To:
References: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
Message-ID:
If this rebindable syntax is about what I think it is, that would seem
strange. bool is the Bool eliminator. It would seem weird to give it a type
like, say,
bool :: Monad m => m a -> m a -> m Bool -> m a
On Nov 16, 2016 10:06 PM, "M Farkas-Dyck" wrote:
> Could we use `bool` rather than add a new term for RebindableSyntax?
> i.e. define if-then-else in terms of `bool`.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ivan.miljenovic at gmail.com Thu Nov 17 03:49:22 2016
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Thu, 17 Nov 2016 14:49:22 +1100
Subject: Add ifThenElse and (?) to Data.Bool
In-Reply-To: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
References: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
Message-ID:
I'm -0.5 on ifThenElse (if it can be used with RebindableSyntax then
someone may want to use it, though I personally find the bool function
to be more than sufficient as I tend to find the "which branch do I
choose" argument to be the last when constructing function pipelines),
and -1 for the operator.
On 17 November 2016 at 13:43, winter wrote:
> It seems this’s a very old request, see
> https://wiki.haskell.org/If-then-else. I’d like to see following:
>
>
> ifThenElse :: Bool -> a -> a -> a
> ifThenElse True x _ = x
> ifThenElse False _ y = y
>
>
> infixr 1 ?
> (?) :: Bool -> a -> a -> a
> (?) = ifThenElse
>
>
> in Date.Bool module, it will have advantages that:
>
>
> + It’s more composable than syntax.
>
> + Write (xxx ? yyy $ zzz) instead of (if xxx then yyy else zzz) is more
> consistent with (f . g $ x) style, and save key strokes.
>
> + In module with RebindableSyntax enabled, you can import ifThenElse to get
> default behavior.
>
>
> Whether or not to be exported by Prelude is another question, but Data.Bool
> seems a good place to start with.
>
>
> Cheers~
>
> Winter
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
--
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com
From drkoster at qq.com Thu Nov 17 04:01:20 2016
From: drkoster at qq.com (winter)
Date: Thu, 17 Nov 2016 12:01:20 +0800
Subject: Add ifThenElse and (?) to Data.Bool
In-Reply-To: <567AE701-1827-4CD1-B164-5E4A3E1C5413@qq.com>
References: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
<567AE701-1827-4CD1-B164-5E4A3E1C5413@qq.com>
Message-ID: <65585F69-68EB-49D2-95BD-FB11614385C0@qq.com>
And here’s some other stuff i can came up with it(without obscured readability IMHO):
...
-- replacement for ifM in various package, similar to (>>= when)
(mFlag >>= (?)) flagEnabled -- mFlag :: Monad m => m Bool
$ flagDisabled
-- nicer if-then-else in applicative style
(?) <$> fFlag <$> flagEnabled
<*> flagDisabled
-- compose with predicates to define your own if
ifLower = (?) . isLower
ifLower ‘X’ lower
upper
...
Basically it's a good if-then-else replacement if you’re comfortable with point-free style.
> On 17 Nov 2016, at 11:16, winter wrote:
>
> I’m totally aware of the existence of bool, i suppose (?) is mainly used in fully application to get a different style than if-then-else syntax, say,
>
> ...
> isGoo <- checkGoo
> isGoo ? goo
> $ woo
> ...
>
>
> But like what the wiki suggested, (?) can be used in some high-order situations. I like this operator because the mnemonic of questioning meaning.
>
>
>
>> On 17 Nov 2016, at 11:03, David Feuer > wrote:
>>
>> If ifThenElse is good for RebindableSyntax, then I'm +1 on that (but I've never played with that extension, so I don't really know). I'm -1 on (?). We already have bool, which tends to be rather more useful when partially applied.
>>
>>
>> On Nov 16, 2016 9:43 PM, "winter" > wrote:
>> It seems this’s a very old request, see https://wiki.haskell.org/If-then-else . I’d like to see following:
>>
>> ifThenElse :: Bool -> a -> a -> a
>> ifThenElse True x _ = x
>> ifThenElse False _ y = y
>>
>> infixr 1 ?
>> (?) :: Bool -> a -> a -> a
>> (?) = ifThenElse
>>
>> in Date.Bool module, it will have advantages that:
>>
>> + It’s more composable than syntax.
>> + Write (xxx ? yyy $ zzz) instead of (if xxx then yyy else zzz) is more consistent with (f . g $ x) style, and save key strokes.
>> + In module with RebindableSyntax enabled, you can import ifThenElse to get default behavior.
>>
>> Whether or not to be exported by Prelude is another question, but Data.Bool seems a good place to start with.
>>
>> Cheers~
>> Winter
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Thu Nov 17 04:02:10 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 16 Nov 2016 23:02:10 -0500
Subject: Add ifThenElse and (?) to Data.Bool
In-Reply-To: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
References: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
Message-ID:
I'm pretty strongly -1 on adding (?). It is one of the few single character
operators available to the average user out of the box and this is a space
where we already have established combinators. It is a valuable portion of
the namespace to spend and each approach we offer means more inessential
complexity to newcomers to the language.
Given the existence of bool today I'm weakly -1 on ifThenElse. That said,
if we were to add RebindableSyntax support for it, I think that I'd
personally flip around to being in favor. It is a much more clear thing for
RebindableSyntax to call out to than something called "bool" that comes
with a different argument order.
These are just my personal feelings on the matter, and not any sort of
"cast in stone" CLC judgments.
-Edward
On Wed, Nov 16, 2016 at 9:43 PM, winter wrote:
> It seems this’s a very old request, see https://wiki.haskell.org/If-then-else. I’d like to see following:
>
>
> ifThenElse :: Bool -> a -> a -> a
> ifThenElse True x _ = xifThenElse False _ y = y
>
>
> infixr 1 ?(?) :: Bool -> a -> a -> a(?) = ifThenElse
>
>
> in Date.Bool module, it will have advantages that:
>
>
> + It’s more composable than syntax.
>
> + Write (xxx ? yyy $ zzz) instead of (if xxx then yyy else zzz) is more consistent with (f . g $ x) style, and save key strokes.
>
> + In module with RebindableSyntax enabled, you can import ifThenElse to get default behavior.
>
>
> Whether or not to be exported by Prelude is another question, but Data.Bool seems a good place to start with.
>
>
> Cheers~
>
> Winter
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Thu Nov 17 04:03:43 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 16 Nov 2016 23:03:43 -0500
Subject: Add ifThenElse and (?) to Data.Bool
In-Reply-To: <65585F69-68EB-49D2-95BD-FB11614385C0@qq.com>
References: <6367E495-3C15-4768-BD82-7707CB7BC83D@qq.com>
<567AE701-1827-4CD1-B164-5E4A3E1C5413@qq.com>
<65585F69-68EB-49D2-95BD-FB11614385C0@qq.com>
Message-ID:
(?) <$> fFlag <$> flagEnabled <*> flagDisabled
You probably don't want this. This performs both effects (!), regardless of
the flag, but only keeps one result.
-Edward
On Wed, Nov 16, 2016 at 11:01 PM, winter wrote:
> And here’s some other stuff i can came up with it(without obscured
> readability IMHO):
>
> ...
> -- replacement for ifM in various package, similar to (>>= when)
>
> (mFlag >>= (?)) flagEnabled -- mFlag :: Monad m => m Bool
> $ flagDisabled
>
> -- nicer if-then-else in applicative style
> (?) <$> fFlag <$> flagEnabled
> <*> flagDisabled
>
> -- compose with predicates to define your own if
> ifLower = (?) . isLower
> ifLower ‘X’ lower
> upper
> ...
>
>
> Basically it's a good if-then-else replacement if you’re comfortable with
> point-free style.
>
>
> On 17 Nov 2016, at 11:16, winter wrote:
>
> I’m totally aware of the existence of bool, i suppose (?) is mainly used
> in fully application to get a different style than if-then-else syntax, say,
>
> ...
> isGoo <- checkGoo
> isGoo ? goo
> $ woo
> ...
>
>
> But like what the wiki suggested, (?) can be used in some high-order
> situations. I like this operator because the mnemonic of questioning
> meaning.
>
>
>
> On 17 Nov 2016, at 11:03, David Feuer wrote:
>
> If ifThenElse is good for RebindableSyntax, then I'm +1 on that (but I've
> never played with that extension, so I don't really know). I'm -1 on (?).
> We already have bool, which tends to be rather more useful when partially
> applied.
>
> On Nov 16, 2016 9:43 PM, "winter" wrote:
>
>> It seems this’s a very old request, see https://wiki.haskell.org/If-then-else. I’d like to see following:
>>
>>
>> ifThenElse :: Bool -> a -> a -> a
>> ifThenElse True x _ = xifThenElse False _ y = y
>>
>>
>> infixr 1 ?(?) :: Bool -> a -> a -> a(?) = ifThenElse
>>
>>
>> in Date.Bool module, it will have advantages that:
>>
>>
>> + It’s more composable than syntax.
>>
>> + Write (xxx ? yyy $ zzz) instead of (if xxx then yyy else zzz) is more consistent with (f . g $ x) style, and save key strokes.
>>
>> + In module with RebindableSyntax enabled, you can import ifThenElse to get default behavior.
>>
>>
>> Whether or not to be exported by Prelude is another question, but Data.Bool seems a good place to start with.
>>
>>
>> Cheers~
>>
>> Winter
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: