From carter.schonwald at gmail.com  Tue Mar  3 20:28:20 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 3 Mar 2020 15:28:20 -0500
Subject: Improved interface to UArray
In-Reply-To: <CAK7nUjhLOTKAujZUE20b7B_VLo6C6ZvH4OAg3mdfoRot99Es0A@mail.gmail.com>
References: <CAK7nUjhLOTKAujZUE20b7B_VLo6C6ZvH4OAg3mdfoRot99Es0A@mail.gmail.com>
Message-ID: <CAHYVw0z1JC15DbuOpku8u2+sk617-F26oTK6iQTA-qhP0SLyHw@mail.gmail.com>

Hey Zemyla!
one fuzzy question i have, and perhaps you have a perspective on this,
would/could the PrimMonad machinery in primitive help simplify / clean up
stuff here too?

On Mon, Feb 24, 2020 at 9:46 AM Zemyla <zemyla at gmail.com> wrote:

> It's currently hard to describe that a type should be usable with UArray
> or IOUArray, and almost impossible to describe without QualifiedConstraints
> that it should be usable with STUArray. And it's actually impossible to use
> GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It
> also means that it's difficult to keep the three sets of instances in sync.
>
> Therefore, there should be (taking inspiration from primitive) a class
> that describes types which can be used in unboxed arrays. It'd be something
> along the lines of:
>
> class Unboxed e where
>   unsafeNewUArray :: Int# -> e -> State# s -> (# State# s,
> MutableByteArray# s #)
>   unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s,
> MutableByteArray# s #)) e
>   unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State#
> s, e #)
>   unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s ->
> State# s
>   unsafeIndexUArray :: ByteArray# -> Int# -> e
>
> And then the instances for UArray, STUArray, and IOUArray would be:
>
> instance Unboxed e => IArray UArray e where ...
> instance Unboxed e => MArray IOUArray e IO where ...
> instance Unboxed e => MArray (STUArray s) e (ST s) where ...
>
> Incidentally, this also means it'd be less effort to add instances like
> Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200303/4bf6fca3/attachment.html>

From zemyla at gmail.com  Tue Mar  3 20:30:42 2020
From: zemyla at gmail.com (Zemyla)
Date: Tue, 3 Mar 2020 14:30:42 -0600
Subject: Improved interface to UArray
In-Reply-To: <CAHYVw0z1JC15DbuOpku8u2+sk617-F26oTK6iQTA-qhP0SLyHw@mail.gmail.com>
References: <CAK7nUjhLOTKAujZUE20b7B_VLo6C6ZvH4OAg3mdfoRot99Es0A@mail.gmail.com>
 <CAHYVw0z1JC15DbuOpku8u2+sk617-F26oTK6iQTA-qhP0SLyHw@mail.gmail.com>
Message-ID: <CAK7nUjjPqHbVDqR+w9YVd02jSp=E7EywD5i5+pDU0jZ-3ijNEQ@mail.gmail.com>

We should probably use something similar, but I don't think a dependency on
primitive is a good idea.

On Tue, Mar 3, 2020, 14:28 Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Hey Zemyla!
> one fuzzy question i have, and perhaps you have a perspective on this,
> would/could the PrimMonad machinery in primitive help simplify / clean up
> stuff here too?
>
> On Mon, Feb 24, 2020 at 9:46 AM Zemyla <zemyla at gmail.com> wrote:
>
>> It's currently hard to describe that a type should be usable with UArray
>> or IOUArray, and almost impossible to describe without QualifiedConstraints
>> that it should be usable with STUArray. And it's actually impossible to use
>> GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It
>> also means that it's difficult to keep the three sets of instances in sync.
>>
>> Therefore, there should be (taking inspiration from primitive) a class
>> that describes types which can be used in unboxed arrays. It'd be something
>> along the lines of:
>>
>> class Unboxed e where
>>   unsafeNewUArray :: Int# -> e -> State# s -> (# State# s,
>> MutableByteArray# s #)
>>   unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s,
>> MutableByteArray# s #)) e
>>   unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (#
>> State# s, e #)
>>   unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s ->
>> State# s
>>   unsafeIndexUArray :: ByteArray# -> Int# -> e
>>
>> And then the instances for UArray, STUArray, and IOUArray would be:
>>
>> instance Unboxed e => IArray UArray e where ...
>> instance Unboxed e => MArray IOUArray e IO where ...
>> instance Unboxed e => MArray (STUArray s) e (ST s) where ...
>>
>> Incidentally, this also means it'd be less effort to add instances like
>> Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200303/0eb74c68/attachment.html>

From chessai1996 at gmail.com  Tue Mar  3 20:56:29 2020
From: chessai1996 at gmail.com (chessai .)
Date: Tue, 3 Mar 2020 12:56:29 -0800
Subject: Improved interface to UArray
In-Reply-To: <CAK7nUjjPqHbVDqR+w9YVd02jSp=E7EywD5i5+pDU0jZ-3ijNEQ@mail.gmail.com>
References: <CAK7nUjhLOTKAujZUE20b7B_VLo6C6ZvH4OAg3mdfoRot99Es0A@mail.gmail.com>
 <CAHYVw0z1JC15DbuOpku8u2+sk617-F26oTK6iQTA-qhP0SLyHw@mail.gmail.com>
 <CAK7nUjjPqHbVDqR+w9YVd02jSp=E7EywD5i5+pDU0jZ-3ijNEQ@mail.gmail.com>
Message-ID: <CAD34_k+_A-sKLPQo6T-6E_h2eDrF67N_Na4LGpMerKhNGJHqUg@mail.gmail.com>

Zemlya, could you expound on why you think a primitive dependency is a bad
idea? I'm just not sure what reasons you have in mind.

Thanks

On Tue, Mar 3, 2020, 12:31 PM Zemyla <zemyla at gmail.com> wrote:

> We should probably use something similar, but I don't think a dependency
> on primitive is a good idea.
>
> On Tue, Mar 3, 2020, 14:28 Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> Hey Zemyla!
>> one fuzzy question i have, and perhaps you have a perspective on this,
>> would/could the PrimMonad machinery in primitive help simplify / clean up
>> stuff here too?
>>
>> On Mon, Feb 24, 2020 at 9:46 AM Zemyla <zemyla at gmail.com> wrote:
>>
>>> It's currently hard to describe that a type should be usable with UArray
>>> or IOUArray, and almost impossible to describe without QualifiedConstraints
>>> that it should be usable with STUArray. And it's actually impossible to use
>>> GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It
>>> also means that it's difficult to keep the three sets of instances in sync.
>>>
>>> Therefore, there should be (taking inspiration from primitive) a class
>>> that describes types which can be used in unboxed arrays. It'd be something
>>> along the lines of:
>>>
>>> class Unboxed e where
>>>   unsafeNewUArray :: Int# -> e -> State# s -> (# State# s,
>>> MutableByteArray# s #)
>>>   unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s,
>>> MutableByteArray# s #)) e
>>>   unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (#
>>> State# s, e #)
>>>   unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s ->
>>> State# s
>>>   unsafeIndexUArray :: ByteArray# -> Int# -> e
>>>
>>> And then the instances for UArray, STUArray, and IOUArray would be:
>>>
>>> instance Unboxed e => IArray UArray e where ...
>>> instance Unboxed e => MArray IOUArray e IO where ...
>>> instance Unboxed e => MArray (STUArray s) e (ST s) where ...
>>>
>>> Incidentally, this also means it'd be less effort to add instances like
>>> Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
>>> _______________________________________________
>>> 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: <http://mail.haskell.org/pipermail/libraries/attachments/20200303/faac0a44/attachment.html>

From zemyla at gmail.com  Tue Mar  3 22:14:25 2020
From: zemyla at gmail.com (Zemyla)
Date: Tue, 3 Mar 2020 16:14:25 -0600
Subject: Improved interface to UArray
In-Reply-To: <CAD34_k+_A-sKLPQo6T-6E_h2eDrF67N_Na4LGpMerKhNGJHqUg@mail.gmail.com>
References: <CAK7nUjhLOTKAujZUE20b7B_VLo6C6ZvH4OAg3mdfoRot99Es0A@mail.gmail.com>
 <CAHYVw0z1JC15DbuOpku8u2+sk617-F26oTK6iQTA-qhP0SLyHw@mail.gmail.com>
 <CAK7nUjjPqHbVDqR+w9YVd02jSp=E7EywD5i5+pDU0jZ-3ijNEQ@mail.gmail.com>
 <CAD34_k+_A-sKLPQo6T-6E_h2eDrF67N_Na4LGpMerKhNGJHqUg@mail.gmail.com>
Message-ID: <CAK7nUjiJ2ygYYDsSdi_mxnPg-Vi4e0Y-64iGFGJJTgJOLPvqJg@mail.gmail.com>

Because a lot of the stuff is defined in GHC.Arr, in base. Also, the Prim
instance for Bool is different than the UArray instance for Bool.

On Tue, Mar 3, 2020, 14:56 chessai . <chessai1996 at gmail.com> wrote:

> Zemlya, could you expound on why you think a primitive dependency is a bad
> idea? I'm just not sure what reasons you have in mind.
>
> Thanks
>
> On Tue, Mar 3, 2020, 12:31 PM Zemyla <zemyla at gmail.com> wrote:
>
>> We should probably use something similar, but I don't think a dependency
>> on primitive is a good idea.
>>
>> On Tue, Mar 3, 2020, 14:28 Carter Schonwald <carter.schonwald at gmail.com>
>> wrote:
>>
>>> Hey Zemyla!
>>> one fuzzy question i have, and perhaps you have a perspective on this,
>>> would/could the PrimMonad machinery in primitive help simplify / clean up
>>> stuff here too?
>>>
>>> On Mon, Feb 24, 2020 at 9:46 AM Zemyla <zemyla at gmail.com> wrote:
>>>
>>>> It's currently hard to describe that a type should be usable with
>>>> UArray or IOUArray, and almost impossible to describe without
>>>> QualifiedConstraints that it should be usable with STUArray. And it's
>>>> actually impossible to use GeneralizedNewtypeDeriving to derive new
>>>> instances of IArray or MArray. It also means that it's difficult to keep
>>>> the three sets of instances in sync.
>>>>
>>>> Therefore, there should be (taking inspiration from primitive) a class
>>>> that describes types which can be used in unboxed arrays. It'd be something
>>>> along the lines of:
>>>>
>>>> class Unboxed e where
>>>>   unsafeNewUArray :: Int# -> e -> State# s -> (# State# s,
>>>> MutableByteArray# s #)
>>>>   unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s,
>>>> MutableByteArray# s #)) e
>>>>   unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (#
>>>> State# s, e #)
>>>>   unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s ->
>>>> State# s
>>>>   unsafeIndexUArray :: ByteArray# -> Int# -> e
>>>>
>>>> And then the instances for UArray, STUArray, and IOUArray would be:
>>>>
>>>> instance Unboxed e => IArray UArray e where ...
>>>> instance Unboxed e => MArray IOUArray e IO where ...
>>>> instance Unboxed e => MArray (STUArray s) e (ST s) where ...
>>>>
>>>> Incidentally, this also means it'd be less effort to add instances like
>>>> Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
>>>> _______________________________________________
>>>> 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: <http://mail.haskell.org/pipermail/libraries/attachments/20200303/e30fe90e/attachment.html>

From carter.schonwald at gmail.com  Tue Mar  3 23:39:14 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 3 Mar 2020 18:39:14 -0500
Subject: Improved interface to UArray
In-Reply-To: <CAK7nUjiJ2ygYYDsSdi_mxnPg-Vi4e0Y-64iGFGJJTgJOLPvqJg@mail.gmail.com>
References: <CAK7nUjhLOTKAujZUE20b7B_VLo6C6ZvH4OAg3mdfoRot99Es0A@mail.gmail.com>
 <CAHYVw0z1JC15DbuOpku8u2+sk617-F26oTK6iQTA-qhP0SLyHw@mail.gmail.com>
 <CAK7nUjjPqHbVDqR+w9YVd02jSp=E7EywD5i5+pDU0jZ-3ijNEQ@mail.gmail.com>
 <CAD34_k+_A-sKLPQo6T-6E_h2eDrF67N_Na4LGpMerKhNGJHqUg@mail.gmail.com>
 <CAK7nUjiJ2ygYYDsSdi_mxnPg-Vi4e0Y-64iGFGJJTgJOLPvqJg@mail.gmail.com>
Message-ID: <CAHYVw0yAYRVLqc01OS-QxGTMeiGOJ_o+2sh_sRZnLDW2u7RUsg@mail.gmail.com>

I meant specifically using PrimMonad, rather than the prim array
facilities, to write the instances

On Tue, Mar 3, 2020 at 5:14 PM Zemyla <zemyla at gmail.com> wrote:

> Because a lot of the stuff is defined in GHC.Arr, in base. Also, the Prim
> instance for Bool is different than the UArray instance for Bool.
>
> On Tue, Mar 3, 2020, 14:56 chessai . <chessai1996 at gmail.com> wrote:
>
>> Zemlya, could you expound on why you think a primitive dependency is a
>> bad idea? I'm just not sure what reasons you have in mind.
>>
>> Thanks
>>
>> On Tue, Mar 3, 2020, 12:31 PM Zemyla <zemyla at gmail.com> wrote:
>>
>>> We should probably use something similar, but I don't think a dependency
>>> on primitive is a good idea.
>>>
>>> On Tue, Mar 3, 2020, 14:28 Carter Schonwald <carter.schonwald at gmail.com>
>>> wrote:
>>>
>>>> Hey Zemyla!
>>>> one fuzzy question i have, and perhaps you have a perspective on this,
>>>> would/could the PrimMonad machinery in primitive help simplify / clean up
>>>> stuff here too?
>>>>
>>>> On Mon, Feb 24, 2020 at 9:46 AM Zemyla <zemyla at gmail.com> wrote:
>>>>
>>>>> It's currently hard to describe that a type should be usable with
>>>>> UArray or IOUArray, and almost impossible to describe without
>>>>> QualifiedConstraints that it should be usable with STUArray. And it's
>>>>> actually impossible to use GeneralizedNewtypeDeriving to derive new
>>>>> instances of IArray or MArray. It also means that it's difficult to keep
>>>>> the three sets of instances in sync.
>>>>>
>>>>> Therefore, there should be (taking inspiration from primitive) a class
>>>>> that describes types which can be used in unboxed arrays. It'd be something
>>>>> along the lines of:
>>>>>
>>>>> class Unboxed e where
>>>>>   unsafeNewUArray :: Int# -> e -> State# s -> (# State# s,
>>>>> MutableByteArray# s #)
>>>>>   unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s,
>>>>> MutableByteArray# s #)) e
>>>>>   unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (#
>>>>> State# s, e #)
>>>>>   unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s ->
>>>>> State# s
>>>>>   unsafeIndexUArray :: ByteArray# -> Int# -> e
>>>>>
>>>>> And then the instances for UArray, STUArray, and IOUArray would be:
>>>>>
>>>>> instance Unboxed e => IArray UArray e where ...
>>>>> instance Unboxed e => MArray IOUArray e IO where ...
>>>>> instance Unboxed e => MArray (STUArray s) e (ST s) where ...
>>>>>
>>>>> Incidentally, this also means it'd be less effort to add instances
>>>>> like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
>>>>> _______________________________________________
>>>>> 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: <http://mail.haskell.org/pipermail/libraries/attachments/20200303/95af096c/attachment.html>

From carter.schonwald at gmail.com  Tue Mar  3 23:41:21 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 3 Mar 2020 18:41:21 -0500
Subject: Improved interface to UArray
In-Reply-To: <CAHYVw0yAYRVLqc01OS-QxGTMeiGOJ_o+2sh_sRZnLDW2u7RUsg@mail.gmail.com>
References: <CAK7nUjhLOTKAujZUE20b7B_VLo6C6ZvH4OAg3mdfoRot99Es0A@mail.gmail.com>
 <CAHYVw0z1JC15DbuOpku8u2+sk617-F26oTK6iQTA-qhP0SLyHw@mail.gmail.com>
 <CAK7nUjjPqHbVDqR+w9YVd02jSp=E7EywD5i5+pDU0jZ-3ijNEQ@mail.gmail.com>
 <CAD34_k+_A-sKLPQo6T-6E_h2eDrF67N_Na4LGpMerKhNGJHqUg@mail.gmail.com>
 <CAK7nUjiJ2ygYYDsSdi_mxnPg-Vi4e0Y-64iGFGJJTgJOLPvqJg@mail.gmail.com>
 <CAHYVw0yAYRVLqc01OS-QxGTMeiGOJ_o+2sh_sRZnLDW2u7RUsg@mail.gmail.com>
Message-ID: <CAHYVw0zk89partjU6qS20zDn0rZ2-T0XKGShsvORkrTn9m9i3A@mail.gmail.com>

looking at current base,
https://downloads.haskell.org/ghc/latest/docs/html/libraries/base-4.13.0.0/GHC-Arr.html
it seems (naively to me) that nothing precludes the array package from
using PrimMonad m => for the IO etc monad instances,
with zero impact on the interface as defined in base. Or am I missing
something?

On Tue, Mar 3, 2020 at 6:39 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> I meant specifically using PrimMonad, rather than the prim array
> facilities, to write the instances
>
> On Tue, Mar 3, 2020 at 5:14 PM Zemyla <zemyla at gmail.com> wrote:
>
>> Because a lot of the stuff is defined in GHC.Arr, in base. Also, the Prim
>> instance for Bool is different than the UArray instance for Bool.
>>
>> On Tue, Mar 3, 2020, 14:56 chessai . <chessai1996 at gmail.com> wrote:
>>
>>> Zemlya, could you expound on why you think a primitive dependency is a
>>> bad idea? I'm just not sure what reasons you have in mind.
>>>
>>> Thanks
>>>
>>> On Tue, Mar 3, 2020, 12:31 PM Zemyla <zemyla at gmail.com> wrote:
>>>
>>>> We should probably use something similar, but I don't think a
>>>> dependency on primitive is a good idea.
>>>>
>>>> On Tue, Mar 3, 2020, 14:28 Carter Schonwald <carter.schonwald at gmail.com>
>>>> wrote:
>>>>
>>>>> Hey Zemyla!
>>>>> one fuzzy question i have, and perhaps you have a perspective on this,
>>>>> would/could the PrimMonad machinery in primitive help simplify / clean up
>>>>> stuff here too?
>>>>>
>>>>> On Mon, Feb 24, 2020 at 9:46 AM Zemyla <zemyla at gmail.com> wrote:
>>>>>
>>>>>> It's currently hard to describe that a type should be usable with
>>>>>> UArray or IOUArray, and almost impossible to describe without
>>>>>> QualifiedConstraints that it should be usable with STUArray. And it's
>>>>>> actually impossible to use GeneralizedNewtypeDeriving to derive new
>>>>>> instances of IArray or MArray. It also means that it's difficult to keep
>>>>>> the three sets of instances in sync.
>>>>>>
>>>>>> Therefore, there should be (taking inspiration from primitive) a
>>>>>> class that describes types which can be used in unboxed arrays. It'd be
>>>>>> something along the lines of:
>>>>>>
>>>>>> class Unboxed e where
>>>>>>   unsafeNewUArray :: Int# -> e -> State# s -> (# State# s,
>>>>>> MutableByteArray# s #)
>>>>>>   unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s,
>>>>>> MutableByteArray# s #)) e
>>>>>>   unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (#
>>>>>> State# s, e #)
>>>>>>   unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s
>>>>>> -> State# s
>>>>>>   unsafeIndexUArray :: ByteArray# -> Int# -> e
>>>>>>
>>>>>> And then the instances for UArray, STUArray, and IOUArray would be:
>>>>>>
>>>>>> instance Unboxed e => IArray UArray e where ...
>>>>>> instance Unboxed e => MArray IOUArray e IO where ...
>>>>>> instance Unboxed e => MArray (STUArray s) e (ST s) where ...
>>>>>>
>>>>>> Incidentally, this also means it'd be less effort to add instances
>>>>>> like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
>>>>>> _______________________________________________
>>>>>> 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: <http://mail.haskell.org/pipermail/libraries/attachments/20200303/4e5b5dbc/attachment.html>

From dominic at steinitz.org  Sat Mar  7 13:24:50 2020
From: dominic at steinitz.org (dominic at steinitz.org)
Date: Sat, 7 Mar 2020 13:24:50 +0000
Subject: Fwd: [nushio3/cmaes] Make work under ghc 8.6.3 (#3)
References: <62E7F210-BDAD-4968-B12F-8A8CB98D425A@steinitz.org>
Message-ID: <64711675-6FA2-4E56-9D7B-0675C7B7099D@steinitz.org>

The owner of https://hackage.haskell.org/package/cmaes has sadly passed away - see below. May I request ownership is transferred to me https://hackage.haskell.org/user/DominicSteinitz.

Many thanks

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.org
Twitter: @idontgetoutmuch

PS

> TakayukiMuranushi is part of the following groups:
> 
> Maintainers for Paraiso
> Maintainers for authoring
> Maintainers for binary-search
> Maintainers for citation-resolve
> Maintainers for cmaes
> Maintainers for doctest-prop
> Maintainers for dynamic-object
> Maintainers for embeddock-example
> Maintainers for embeddock
> Maintainers for formura
> Maintainers for typelevel-tensor
> Maintainers for unicode-show


From dominic at steinitz.org  Sat Mar  7 13:26:08 2020
From: dominic at steinitz.org (dominic at steinitz.org)
Date: Sat, 7 Mar 2020 13:26:08 +0000
Subject: Fwd: [nushio3/cmaes] Make work under ghc 8.6.3 (#3)
References: <nushio3/cmaes/pull/3/c593030266@github.com>
Message-ID: <AE1BBD01-717E-4A4D-BFD7-7D26B27538F3@steinitz.org>

I should have attached this.

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.org
Twitter: @idontgetoutmuch

> Begin forwarded message:
> 
> From: Masahiro Sakai <notifications at github.com>
> Subject: Re: [nushio3/cmaes] Make work under ghc 8.6.3 (#3)
> Date: 1 March 2020 at 02:05:26 GMT
> To: nushio3/cmaes <cmaes at noreply.github.com>
> Cc: idontgetoutmuch <dominic at steinitz.org>, Author <author at noreply.github.com>
> Reply-To: nushio3/cmaes <reply+AAL2POK6HTHVOLJEQ7ZGOCF4M34WNEVBNHHBVVURWQ at reply.github.com>
> 
> The author @nushio3 <https://github.com/nushio3> passed away in 2019 and cannot merge this pull request.
> It might be better to work on your fork, and possibly to take over ownership of the package on Hackage if you want to continue maintaining.
> 
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <https://github.com/nushio3/cmaes/pull/3?email_source=notifications&email_token=AAL2POPDAA2XBDJMVPKS44DRFG7GNA5CNFSM4HREDIY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOY6Q#issuecomment-593030266>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL2POOVBEDDCQULWJGRXNDRFG7GNANCNFSM4HREDIYQ>.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200307/46322c96/attachment.html>

From chessai1996 at gmail.com  Fri Mar 13 20:50:52 2020
From: chessai1996 at gmail.com (chessai .)
Date: Fri, 13 Mar 2020 13:50:52 -0700
Subject: New CLC co-chairs, New maintainers of `base`
Message-ID: <CAD34_kKadXndK_yM=j_smy+EzEuE2HyhOf5yovenf4wY4iqbuw@mail.gmail.com>

As you know from previous announcements, Edward Kmett is stepping down
as CLC Chair, and Ryan Scott is stepping down from the CLC altogether.
They are both also stepping down as co-maintainers of base. Carter
Schonwald and myself, chessai, will be the new CLC co-chair and
co-maintainers of base. Thank you again to Edward and Ryan for all of
their accomplishments and hard work. Carter and I look forward to
serving this wonderful community.

From chessai1996 at gmail.com  Sat Mar 14 03:59:22 2020
From: chessai1996 at gmail.com (chessai .)
Date: Fri, 13 Mar 2020 20:59:22 -0700
Subject: Improving the instances of Data.Functor.{Product,Sum}
Message-ID: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>

Consider the Eq instance for these types. Currently we rely on:

(Eq1 f, Eq1 g, Eq a)

But some potential improvements include changing to:

(Eq (f (g a))) (FlexibleContexts)

or

(forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a)
(QuantifiedConstraints)

There was a discussion sometime last year about the same thing
regarding Semigroup/Monoid instances for `Compose` [1]. Additionally,
the question has been raised again for Data.Functor.{Product,Sum} on
Gitlab [2, 3]. There has been no consensus in either case, but that's
not too worrying as both discussions have been brief. I'm currently
not happy with the {Eq,Ord,Show}{1,2} family of classes, and would
hope to work toward their removal, or at least the shrinking of their
presence in base. Even though the linked proposals are about a single
type, I think it's important that we come up with a decision and stick
with it. Having different APIs for different types here would be
pretty confusing, and some could even say sloppy.

Please let me know your thoughts.

[1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html
[2]: https://gitlab.haskell.org/ghc/ghc/issues/17015
[3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704

From emertens at gmail.com  Sat Mar 14 04:14:09 2020
From: emertens at gmail.com (Eric Mertens)
Date: Fri, 13 Mar 2020 21:14:09 -0700
Subject: Improving the instances of Data.Functor.{Product,Sum}
In-Reply-To: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
References: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
Message-ID: <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>

I prefer to avoid FlexibleInstances wherever I can. The last thing I'd
heard about quantified constraints was that they were buggy and I've been
avoiding relying on them. (I should probably review that assumptions at
some point.) Having a class like Eq1 is the cleaner option. I'd rather fix
up these classes than work to get rid of them.

On Fri, Mar 13, 2020 at 8:59 PM chessai . <chessai1996 at gmail.com> wrote:

> Consider the Eq instance for these types. Currently we rely on:
>
> (Eq1 f, Eq1 g, Eq a)
>
> But some potential improvements include changing to:
>
> (Eq (f (g a))) (FlexibleContexts)
>
> or
>
> (forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a)
> (QuantifiedConstraints)
>
> There was a discussion sometime last year about the same thing
> regarding Semigroup/Monoid instances for `Compose` [1]. Additionally,
> the question has been raised again for Data.Functor.{Product,Sum} on
> Gitlab [2, 3]. There has been no consensus in either case, but that's
> not too worrying as both discussions have been brief. I'm currently
> not happy with the {Eq,Ord,Show}{1,2} family of classes, and would
> hope to work toward their removal, or at least the shrinking of their
> presence in base. Even though the linked proposals are about a single
> type, I think it's important that we come up with a decision and stick
> with it. Having different APIs for different types here would be
> pretty confusing, and some could even say sloppy.
>
> Please let me know your thoughts.
>
> [1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html
> [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015
> [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


-- 
Eric Mertens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200313/3ff41144/attachment.html>

From zemyla at gmail.com  Sat Mar 14 04:22:02 2020
From: zemyla at gmail.com (Zemyla)
Date: Fri, 13 Mar 2020 23:22:02 -0500
Subject: Improving the instances of Data.Functor.{Product,Sum}
In-Reply-To: <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
References: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
 <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
Message-ID: <CAK7nUjiuLCoJNzjME6H6MsgUOyDgmfQrbvMyzUt7vct4=1_cug@mail.gmail.com>

Also, keeping it Haskell98 compliant makes it easier for newer users to
grok.

On Fri, Mar 13, 2020, 23:15 Eric Mertens <emertens at gmail.com> wrote:

> I prefer to avoid FlexibleInstances wherever I can. The last thing I'd
> heard about quantified constraints was that they were buggy and I've been
> avoiding relying on them. (I should probably review that assumptions at
> some point.) Having a class like Eq1 is the cleaner option. I'd rather fix
> up these classes than work to get rid of them.
>
> On Fri, Mar 13, 2020 at 8:59 PM chessai . <chessai1996 at gmail.com> wrote:
>
>> Consider the Eq instance for these types. Currently we rely on:
>>
>> (Eq1 f, Eq1 g, Eq a)
>>
>> But some potential improvements include changing to:
>>
>> (Eq (f (g a))) (FlexibleContexts)
>>
>> or
>>
>> (forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a)
>> (QuantifiedConstraints)
>>
>> There was a discussion sometime last year about the same thing
>> regarding Semigroup/Monoid instances for `Compose` [1]. Additionally,
>> the question has been raised again for Data.Functor.{Product,Sum} on
>> Gitlab [2, 3]. There has been no consensus in either case, but that's
>> not too worrying as both discussions have been brief. I'm currently
>> not happy with the {Eq,Ord,Show}{1,2} family of classes, and would
>> hope to work toward their removal, or at least the shrinking of their
>> presence in base. Even though the linked proposals are about a single
>> type, I think it's important that we come up with a decision and stick
>> with it. Having different APIs for different types here would be
>> pretty confusing, and some could even say sloppy.
>>
>> Please let me know your thoughts.
>>
>> [1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html
>> [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015
>> [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> --
> Eric Mertens
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200313/1ac44975/attachment.html>

From chessai1996 at gmail.com  Sat Mar 14 05:49:14 2020
From: chessai1996 at gmail.com (chessai .)
Date: Fri, 13 Mar 2020 22:49:14 -0700
Subject: Improving the instances of Data.Functor.{Product,Sum}
In-Reply-To: <CAK7nUjiuLCoJNzjME6H6MsgUOyDgmfQrbvMyzUt7vct4=1_cug@mail.gmail.com>
References: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
 <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
 <CAK7nUjiuLCoJNzjME6H6MsgUOyDgmfQrbvMyzUt7vct4=1_cug@mail.gmail.com>
Message-ID: <CAD34_kJ4sxV+yCaX65G8-bV=13ksb0GhVo2eEc20PgTi5WAjhA@mail.gmail.com>

Eric,

Could you expound on why you try to avoid Flexible{Contexts,Instances} in
your own code? That might be useful to look at here.

On Fri, Mar 13, 2020, 9:22 PM Zemyla <zemyla at gmail.com> wrote:

> Also, keeping it Haskell98 compliant makes it easier for newer users to
> grok.
>
> On Fri, Mar 13, 2020, 23:15 Eric Mertens <emertens at gmail.com> wrote:
>
>> I prefer to avoid FlexibleInstances wherever I can. The last thing I'd
>> heard about quantified constraints was that they were buggy and I've been
>> avoiding relying on them. (I should probably review that assumptions at
>> some point.) Having a class like Eq1 is the cleaner option. I'd rather fix
>> up these classes than work to get rid of them.
>>
>> On Fri, Mar 13, 2020 at 8:59 PM chessai . <chessai1996 at gmail.com> wrote:
>>
>>> Consider the Eq instance for these types. Currently we rely on:
>>>
>>> (Eq1 f, Eq1 g, Eq a)
>>>
>>> But some potential improvements include changing to:
>>>
>>> (Eq (f (g a))) (FlexibleContexts)
>>>
>>> or
>>>
>>> (forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a)
>>> (QuantifiedConstraints)
>>>
>>> There was a discussion sometime last year about the same thing
>>> regarding Semigroup/Monoid instances for `Compose` [1]. Additionally,
>>> the question has been raised again for Data.Functor.{Product,Sum} on
>>> Gitlab [2, 3]. There has been no consensus in either case, but that's
>>> not too worrying as both discussions have been brief. I'm currently
>>> not happy with the {Eq,Ord,Show}{1,2} family of classes, and would
>>> hope to work toward their removal, or at least the shrinking of their
>>> presence in base. Even though the linked proposals are about a single
>>> type, I think it's important that we come up with a decision and stick
>>> with it. Having different APIs for different types here would be
>>> pretty confusing, and some could even say sloppy.
>>>
>>> Please let me know your thoughts.
>>>
>>> [1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html
>>> [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015
>>> [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>
>>
>> --
>> Eric Mertens
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200313/6c4fdbcb/attachment.html>

From lemming at henning-thielemann.de  Sat Mar 14 07:29:32 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 14 Mar 2020 08:29:32 +0100 (CET)
Subject: Improving the instances of Data.Functor.{Product,Sum}
In-Reply-To: <CAD34_kJ4sxV+yCaX65G8-bV=13ksb0GhVo2eEc20PgTi5WAjhA@mail.gmail.com>
References: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
 <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
 <CAK7nUjiuLCoJNzjME6H6MsgUOyDgmfQrbvMyzUt7vct4=1_cug@mail.gmail.com>
 <CAD34_kJ4sxV+yCaX65G8-bV=13ksb0GhVo2eEc20PgTi5WAjhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2003140821330.4653@sputnik>


On Fri, 13 Mar 2020, chessai . wrote:

> Could you expound on why you try to avoid Flexible{Contexts,Instances} 
> in your own code? That might be useful to look at here.

I also try to avoid FlexibleInstances. FlexibleInstances are sometimes a 
consequence of multi-parameter type classes with too many parameters. E.g.

    instance Convert Int a
    instance Convert Integer a

which should be better a single-parameter type class on the first 
parameter.

FlexibleInstances might indicate too lax instances. E.g.

    instance C (A a) (B a) where

should be better

    isntance (a~b) => C (A a) (B b) where


Sometimes they are a sign of non-composability. E.g.

    instance StringClass String where

should be better

    instance CharClass a => StringClass [a] where

or

    instance (a ~ Char) => StringClass [a] where

depending, on what you need.

From rae at richarde.dev  Sat Mar 14 11:16:43 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 14 Mar 2020 11:16:43 +0000
Subject: Improving the instances of Data.Functor.{Product,Sum}
In-Reply-To: <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
References: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
 <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
Message-ID: <1A13B63F-E4F7-4124-AEF0-C0CB42E7546D@richarde.dev>



> On Mar 14, 2020, at 4:14 AM, Eric Mertens <emertens at gmail.com> wrote:
> 
> The last thing I'd heard about quantified constraints was that they were buggy and I've been avoiding relying on them. (I should probably review that assumptions at some point.)

Without expressing an opinion about chessai's proposal (which I have not really thought about): quantified constraints are in good shape and ready for prime time. They have limitations (e.g. you can't mention a type family to the right of the =>), but when they are valid, they work well. I'll never swear that a feature is bug-free, but I think it's reasonable to consider using quantified constraints in `base`.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200314/b264e736/attachment.html>

From chessai1996 at gmail.com  Sat Mar 14 14:10:47 2020
From: chessai1996 at gmail.com (chessai .)
Date: Sat, 14 Mar 2020 07:10:47 -0700
Subject: Improving the instances of Data.Functor.{Product,Sum}
In-Reply-To: <1A13B63F-E4F7-4124-AEF0-C0CB42E7546D@richarde.dev>
References: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
 <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
 <1A13B63F-E4F7-4124-AEF0-C0CB42E7546D@richarde.dev>
Message-ID: <CAD34_kJw72dJwSzvfNbQ95ie-p25Mu72PC52TYUHnBfZMpSOCw@mail.gmail.com>

I can second Richard's estimation of QuantifiedConstraints, I have used
them a lot in my own code since they were in HEAD. I consider it a
sufficiently stable feature to include in base or any library.

On Sat, Mar 14, 2020, 4:16 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Mar 14, 2020, at 4:14 AM, Eric Mertens <emertens at gmail.com> wrote:
>
> The last thing I'd heard about quantified constraints was that they were
> buggy and I've been avoiding relying on them. (I should probably review
> that assumptions at some point.)
>
>
> Without expressing an opinion about chessai's proposal (which I have not
> really thought about): quantified constraints are in good shape and ready
> for prime time. They have limitations (e.g. you can't mention a type family
> to the right of the =>), but when they are valid, they work well. I'll
> never swear that a feature is bug-free, but I think it's reasonable to
> consider using quantified constraints in `base`.
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200314/3c29c116/attachment.html>

From oleg.grenrus at iki.fi  Sat Mar 14 15:43:26 2020
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sat, 14 Mar 2020 17:43:26 +0200
Subject: Improving the instances of Data.Functor.{Product,Sum}
In-Reply-To: <CAD34_kJw72dJwSzvfNbQ95ie-p25Mu72PC52TYUHnBfZMpSOCw@mail.gmail.com>
References: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
 <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
 <1A13B63F-E4F7-4124-AEF0-C0CB42E7546D@richarde.dev>
 <CAD34_kJw72dJwSzvfNbQ95ie-p25Mu72PC52TYUHnBfZMpSOCw@mail.gmail.com>
Message-ID: <3d206fe2-6ad3-0343-51ed-66fa9ccd95a5@iki.fi>

QuantifiedConstraints are not buggy, but they are not _complete_
(I do mean that as "buggy" = not sound, properly expressive = complete).

There are at least three issues:

1. Instance definition need UndecidableInstances (in my opinion this is 
big deal)
2. Instances are not elegant (easy to write, but not elegant).
3. QuantifiedConstraints resists to be abstracted over

See https://gist.github.com/phadej/266d68cf5cc1229c3548b7965f4335f8 for
the standalone code file.

For the reasons below I wouldn't recommend using QuantifiedConstraints.
I very like them, but I'm not convinced the feature is ready for "prime 
time".
To put into perspective, I think code classes of `singletons` are more 
ready to
be included in `base` than changing instances of Data.Functor.Sum and 
.Product.
I do use singletons in my code more than QuantifiedConstraints. :)

I'm very worried how this change will affect libraries like `free` and
`recursion-schemes` and what builds on top of them.
This is not only change to `base`, it strongly guides how downstream
libraries should be written (or changed) as well.

On the other hand, I don't feel strongly about

     instance (Eq (f a), Eq (g a)) => Eq (Product f g a)

Yet, in the light of `free` it is "a step backwards".
See https://hackage.haskell.org/package/free-5/changelog

---

Simple example with `newtype Fix f = Fix (f (Fix f))`

     class Eq1 f where
         liftEq :: (a -> b -> Bool) -> f a -> f b -> Bool

     class Eq1 f => Ord1 f where
         liftCompare :: (a -> b -> Ordering) -> f a -> f b -> Ordering

     instance Eq1 f => Eq (Fix f) where
         (==) = eq where eq (Fix x) (Fix y) = liftEq eq x y

     instance Ord1 f => Ord (Fix f) where
         compare = cmp where cmp (Fix x) (Fix y) = liftCompare cmp x y

works. It's boilerplate, but it's already written.

However, if we want to use QuantifiedConstraints,
then we

1. need UndecidableInstances
2. and then the code turns out to be less elegant:

instance (forall x. Eq x => Eq (f x)) => Eq (Fix f) where
     (==) = eq where eq (Fix x) (Fix y) = x == y

instance (forall x. Ord x => Ord (f x)) => Ord (Fix f) where
     compare = cmp where cmp (Fix x) (Fix y) = compare x y

fails to compile with

     GHCi, version 8.8.3: https://www.haskell.org/ghc/  :? for help
     [1 of 1] Compiling Main             ( Ord1.hs, interpreted )

     Ord1.hs:28:10: error:
         • Could not deduce (Ord x)
             arising from the superclasses of an instance declaration

we need to write Ord instance differently

    instance (forall x. Ord x => Ord (f x), forall x. Eq x => Eq (f x)) 
=> Ord (Fix f) where
        compare = cmp where cmp (Fix x) (Fix y) = compare x y


This _cannot_ be made to work:

     forall x. Ord x => Ord (f x)

doesn't entail

     forall x. Eq x => Eq (f x)

If you try to write defaultLiftEq using liftCompare

     defaultLiftEq :: Ord1 f => (a -> b -> Bool) -> f a -> f b -> Bool
     defaultLiftEq eq x y = EQ == liftCompare _problem_ x y

then you will se a problem.

---

Third issue is that We cannot abstract over QuantifiedConstraints.

Take an example `Dict`. We can use `Dict` for various things.

     data Dict :: (k -> Constraint) -> k -> * where
         Dict :: c a => Dict c a

It nicely uses PolyKinds extension so we can write:

     eqInt :: Dict Eq Int
     eqInt = Dict

     eq1List :: Dict Eq1 []
     eq1List = Dict

And we can use Dict to *manually* thread information

     entail :: Dict Ord1 f -> Dict Eq1 f
     entail Dict = Dict

The selling pitch of QuantifiedConstraints, that we could get this for free.
Above Ord (Fix) example however makes me suspicious. Let's try:

     eqQList :: Dict (forall x. Eq x => Eq (f x)) []
     eqQList = undefined

But it doesn't work!

     Ord1.hs:53:28: error:
         • Expected kind ‘(* -> *) -> Constraint’,
             but ‘Eq (f x)’ has kind ‘*’
         • In the first argument of ‘Dict’, namely
             ‘(forall x. Eq x => Eq (f x))’
           In the type signature:
             eqQList :: Dict (forall x. Eq x => Eq (f x)) []
        |
     53 | eqQList :: Dict (forall x. Eq x => Eq (f x)) []
        |

     Ord1.hs:53:36: error:
         • Expected a type, but ‘Eq (f x)’ has kind ‘Constraint’
         • In the first argument of ‘Dict’, namely
             ‘(forall x. Eq x => Eq (f x))’
           In the type signature:
             eqQList :: Dict (forall x. Eq x => Eq (f x)) []
        |
     53 | eqQList :: Dict (forall x. Eq x => Eq (f x)) []
        |                                    ^^^^^^^^

Then we remember that we have seen that,
we **cannot define** type synonyms for quantified constraints

     type Eq1' f = forall x. Eq x => Eq (f x)

errors with

     Ord1.hs:56:33: error:
         • Expected a type, but ‘Eq (f x)’ has kind ‘Constraint’

Luckily GHC-8.10.1 (which is not released at the moment of writing)
will give us ability to say

     type Eq1' :: (* -> *) -> Constraint
     type Eq1' f = forall x. Eq x => Eq (f x)

This is promising! Let's try to fix eqQList

     eqQList2 :: Dict Eq1' []
     eqQList2 = undefined

But that doesn't work. Type-aliases have to be fully applied!

How in Haskell we fix issues when type-aliases (of classes) need to be 
partially
evaluated? We defined

     class ... => Example a b c
     instance ... => Example a b c

Third try

     eqQList3 :: Dict Eq1'' f
     eqQList3 = Dict

The type signature is accepted, but the implementation is not

    Ord1.hs:67:12: error:
        • Could not deduce (Eq (f x)) arising from a use of ‘Dict’

At this point I'm clueless.

---

Best regards,
Oleg

P.S. If we would like to take QuantifiedConstraints somewhere into use, 
then IMO we should start with MonadTrans class. IIRC it's well motivated 
in the paper. But UndecidableInstances is very unfortunate.

On 14.3.2020 16.10, chessai . wrote:
> I can second Richard's estimation of QuantifiedConstraints, I have 
> used them a lot in my own code since they were in HEAD. I consider it 
> a sufficiently stable feature to include in base or any library.
>
> On Sat, Mar 14, 2020, 4:16 AM Richard Eisenberg <rae at richarde.dev 
> <mailto:rae at richarde.dev>> wrote:
>
>
>
>>     On Mar 14, 2020, at 4:14 AM, Eric Mertens <emertens at gmail.com
>>     <mailto:emertens at gmail.com>> wrote:
>>
>>     The last thing I'd heard about quantified constraints was that
>>     they were buggy and I've been avoiding relying on them. (I should
>>     probably review that assumptions at some point.)
>
>     Without expressing an opinion about chessai's proposal (which I
>     have not really thought about): quantified constraints are in good
>     shape and ready for prime time. They have limitations (e.g. you
>     can't mention a type family to the right of the =>), but when they
>     are valid, they work well. I'll never swear that a feature is
>     bug-free, but I think it's reasonable to consider using quantified
>     constraints in `base`.
>
>     Richard
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200314/89dcc992/attachment.html>

From carter.schonwald at gmail.com  Sun Mar 15 20:43:07 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 15 Mar 2020 16:43:07 -0400
Subject: Improving the instances of Data.Functor.{Product,Sum}
In-Reply-To: <3d206fe2-6ad3-0343-51ed-66fa9ccd95a5@iki.fi>
References: <CAD34_kJxYdQMoEpOOXuSvjhJdPV3PGcrqiDgGiq1AzsafNDG9A@mail.gmail.com>
 <CALya092TxHWNuP7MKtH-ZVpYAydUQc1aTPqZmXcfzB3UAgtYDw@mail.gmail.com>
 <1A13B63F-E4F7-4124-AEF0-C0CB42E7546D@richarde.dev>
 <CAD34_kJw72dJwSzvfNbQ95ie-p25Mu72PC52TYUHnBfZMpSOCw@mail.gmail.com>
 <3d206fe2-6ad3-0343-51ed-66fa9ccd95a5@iki.fi>
Message-ID: <CAHYVw0zJ5_J2NBkgoEuk3+355Gkq6RwAjujYq-ydD3cAW-SNWg@mail.gmail.com>

as an additional point of data,
https://github.com/ekmett/bytes/pull/49#issuecomment-580924670  and the
indirectly linked ticket
https://gitlab.haskell.org/ghc/ghc/issues/17767#note_251123
is an example of how not trivial a pretty simple use of quantified
constraints / related machinery can be!


a good "guiding light" for core libraries in haskell perhaps should be
"what choices jointly give the best type inference, composability,
generality, performance, and usability" and when we hit a trade off for
these parameters, make sure we understand those and have very well
understood tradeoffs.

@daniel  for these sorts of instance renovation proposals, its probably
best to show case "heres the type  and instance and uses" in each of the K
different flavors and what gets better/easier/harder simpler.  I honestly
dont do it as often as I should myself!

In this case, putting together a tiny repo with different module doing the
various flavors and how they work might be best for grounding this. bonus
points if its cabalized so that folks on different lagging rates of ghc
versions can poke around :)

(one idea i've been thinking about is how to best make various phases of
possibly nontrivial proposals easy to evaluate and compare for impact and
benefit, but thats a discussion for another time)

as ever, be well all on this bizarre spring we're all experiencing

-Carter


On Sat, Mar 14, 2020 at 11:44 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

> QuantifiedConstraints are not buggy, but they are not _complete_
> (I do mean that as "buggy" = not sound, properly expressive = complete).
>
> There are at least three issues:
>
> 1. Instance definition need UndecidableInstances (in my opinion this is
> big deal)
> 2. Instances are not elegant (easy to write, but not elegant).
> 3. QuantifiedConstraints resists to be abstracted over
>
> See https://gist.github.com/phadej/266d68cf5cc1229c3548b7965f4335f8 for
> the standalone code file.
>
> For the reasons below I wouldn't recommend using QuantifiedConstraints.
> I very like them, but I'm not convinced the feature is ready for "prime
> time".
> To put into perspective, I think code classes of `singletons` are more
> ready to
> be included in `base` than changing instances of Data.Functor.Sum and
> .Product.
> I do use singletons in my code more than QuantifiedConstraints. :)
>
> I'm very worried how this change will affect libraries like `free` and
> `recursion-schemes` and what builds on top of them.
> This is not only change to `base`, it strongly guides how downstream
> libraries should be written (or changed) as well.
>
> On the other hand, I don't feel strongly about
>
>     instance (Eq (f a), Eq (g a)) => Eq (Product f g a)
>
> Yet, in the light of `free` it is "a step backwards".
> See https://hackage.haskell.org/package/free-5/changelog
>
> ---
>
> Simple example with `newtype Fix f = Fix (f (Fix f))`
>
>     class Eq1 f where
>         liftEq :: (a -> b -> Bool) -> f a -> f b -> Bool
>
>     class Eq1 f => Ord1 f where
>         liftCompare :: (a -> b -> Ordering) -> f a -> f b -> Ordering
>
>     instance Eq1 f => Eq (Fix f) where
>         (==) = eq where eq (Fix x) (Fix y) = liftEq eq x y
>
>     instance Ord1 f => Ord (Fix f) where
>         compare = cmp where cmp (Fix x) (Fix y) = liftCompare cmp x y
>
> works. It's boilerplate, but it's already written.
>
> However, if we want to use QuantifiedConstraints,
> then we
>
> 1. need UndecidableInstances
> 2. and then the code turns out to be less elegant:
>
> instance (forall x. Eq x => Eq (f x)) => Eq (Fix f) where
>     (==) = eq where eq (Fix x) (Fix y) = x == y
>
> instance (forall x. Ord x => Ord (f x)) => Ord (Fix f) where
>     compare = cmp where cmp (Fix x) (Fix y) = compare x y
>
> fails to compile with
>
>     GHCi, version 8.8.3: https://www.haskell.org/ghc/  :? for help
>     [1 of 1] Compiling Main             ( Ord1.hs, interpreted )
>
>     Ord1.hs:28:10: error:
>         • Could not deduce (Ord x)
>             arising from the superclasses of an instance declaration
>
> we need to write Ord instance differently
>
>    instance (forall x. Ord x => Ord (f x), forall x. Eq x => Eq (f x)) =>
> Ord (Fix f) where
>        compare = cmp where cmp (Fix x) (Fix y) = compare x y
>
>
> This _cannot_ be made to work:
>
>     forall x. Ord x => Ord (f x)
>
> doesn't entail
>
>     forall x. Eq x => Eq (f x)
>
> If you try to write defaultLiftEq using liftCompare
>
>     defaultLiftEq :: Ord1 f => (a -> b -> Bool) -> f a -> f b -> Bool
>     defaultLiftEq eq x y = EQ == liftCompare _problem_ x y
>
> then you will se a problem.
>
> ---
>
> Third issue is that We cannot abstract over QuantifiedConstraints.
>
> Take an example `Dict`. We can use `Dict` for various things.
>
>     data Dict :: (k -> Constraint) -> k -> * where
>         Dict :: c a => Dict c a
>
> It nicely uses PolyKinds extension so we can write:
>
>     eqInt :: Dict Eq Int
>     eqInt = Dict
>
>     eq1List :: Dict Eq1 []
>     eq1List = Dict
>
> And we can use Dict to *manually* thread information
>
>     entail :: Dict Ord1 f -> Dict Eq1 f
>     entail Dict = Dict
>
> The selling pitch of QuantifiedConstraints, that we could get this for
> free.
> Above Ord (Fix) example however makes me suspicious. Let's try:
>
>     eqQList :: Dict (forall x. Eq x => Eq (f x)) []
>     eqQList = undefined
>
> But it doesn't work!
>
>     Ord1.hs:53:28: error:
>         • Expected kind ‘(* -> *) -> Constraint’,
>             but ‘Eq (f x)’ has kind ‘*’
>         • In the first argument of ‘Dict’, namely
>             ‘(forall x. Eq x => Eq (f x))’
>           In the type signature:
>             eqQList :: Dict (forall x. Eq x => Eq (f x)) []
>        |
>     53 | eqQList :: Dict (forall x. Eq x => Eq (f x)) []
>        |
>
>     Ord1.hs:53:36: error:
>         • Expected a type, but ‘Eq (f x)’ has kind ‘Constraint’
>         • In the first argument of ‘Dict’, namely
>             ‘(forall x. Eq x => Eq (f x))’
>           In the type signature:
>             eqQList :: Dict (forall x. Eq x => Eq (f x)) []
>        |
>     53 | eqQList :: Dict (forall x. Eq x => Eq (f x)) []
>        |                                    ^^^^^^^^
>
> Then we remember that we have seen that,
> we **cannot define** type synonyms for quantified constraints
>
>     type Eq1' f = forall x. Eq x => Eq (f x)
>
> errors with
>
>     Ord1.hs:56:33: error:
>         • Expected a type, but ‘Eq (f x)’ has kind ‘Constraint’
>
> Luckily GHC-8.10.1 (which is not released at the moment of writing)
> will give us ability to say
>
>     type Eq1' :: (* -> *) -> Constraint
>     type Eq1' f = forall x. Eq x => Eq (f x)
>
> This is promising! Let's try to fix eqQList
>
>     eqQList2 :: Dict Eq1' []
>     eqQList2 = undefined
>
> But that doesn't work. Type-aliases have to be fully applied!
>
> How in Haskell we fix issues when type-aliases (of classes) need to be
> partially
> evaluated? We defined
>
>     class ... => Example a b c
>     instance ... => Example a b c
>
> Third try
>
>     eqQList3 :: Dict Eq1'' f
>     eqQList3 = Dict
>
> The type signature is accepted, but the implementation is not
>
>    Ord1.hs:67:12: error:
>        • Could not deduce (Eq (f x)) arising from a use of ‘Dict’
>
> At this point I'm clueless.
>
> ---
>
> Best regards,
> Oleg
>
> P.S. If we would like to take QuantifiedConstraints somewhere into use,
> then IMO we should start with MonadTrans class. IIRC it's well motivated in
> the paper. But UndecidableInstances is very unfortunate.
> On 14.3.2020 16.10, chessai . wrote:
>
> I can second Richard's estimation of QuantifiedConstraints, I have used
> them a lot in my own code since they were in HEAD. I consider it a
> sufficiently stable feature to include in base or any library.
>
> On Sat, Mar 14, 2020, 4:16 AM Richard Eisenberg <rae at richarde.dev> wrote:
>
>>
>>
>> On Mar 14, 2020, at 4:14 AM, Eric Mertens <emertens at gmail.com> wrote:
>>
>> The last thing I'd heard about quantified constraints was that they were
>> buggy and I've been avoiding relying on them. (I should probably review
>> that assumptions at some point.)
>>
>>
>> Without expressing an opinion about chessai's proposal (which I have not
>> really thought about): quantified constraints are in good shape and ready
>> for prime time. They have limitations (e.g. you can't mention a type family
>> to the right of the =>), but when they are valid, they work well. I'll
>> never swear that a feature is bug-free, but I think it's reasonable to
>> consider using quantified constraints in `base`.
>>
>> Richard
>>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://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: <http://mail.haskell.org/pipermail/libraries/attachments/20200315/6a97133e/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 18 18:46:47 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 18 Mar 2020 14:46:47 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
Message-ID: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>

hey everyone, because so much important stuff for the community, it makes
sense to add 2fa required for the org, are there any good reasons to either
wait to do this, or not do it? Feedback welcome!

(if theres no objections i'll do it friday or this weekend, so theres some
lead time for anyone who's not setup for that yet)

Best wishes and great health to all
-carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/0cfe7917/attachment.html>

From david.feuer at gmail.com  Wed Mar 18 19:45:21 2020
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 18 Mar 2020 15:45:21 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
Message-ID: <CAMgWh9s9DE58HLH4WBup0q2OajKEcC6d9ohm8ZXt+kn+kFRkUA@mail.gmail.com>

That's not a lot of lead time.

On Wed, Mar 18, 2020, 2:47 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> hey everyone, because so much important stuff for the community, it makes
> sense to add 2fa required for the org, are there any good reasons to either
> wait to do this, or not do it? Feedback welcome!
>
> (if theres no objections i'll do it friday or this weekend, so theres some
> lead time for anyone who's not setup for that yet)
>
> Best wishes and great health to all
> -carter
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/3bb8aa68/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 18 20:09:01 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 18 Mar 2020 16:09:01 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <CAMgWh9s9DE58HLH4WBup0q2OajKEcC6d9ohm8ZXt+kn+kFRkUA@mail.gmail.com>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <CAMgWh9s9DE58HLH4WBup0q2OajKEcC6d9ohm8ZXt+kn+kFRkUA@mail.gmail.com>
Message-ID: <CAHYVw0xA-Fzh1G-YUxWtV1HgOg=5o4jwYKNOipU-7dpYrYmA-g@mail.gmail.com>

true, otoh, 2fa in various usable forms has been widely available for
years, and we can reonboard people pretty easily. Its critical haskell
infra and to the best of my knowledge, current 2fa tooling is pretty
accessible to everyone globally. If someone has specific issues we can
address them as they arise!

On Wed, Mar 18, 2020 at 3:45 PM David Feuer <david.feuer at gmail.com> wrote:

> That's not a lot of lead time.
>
> On Wed, Mar 18, 2020, 2:47 PM Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> hey everyone, because so much important stuff for the community, it makes
>> sense to add 2fa required for the org, are there any good reasons to either
>> wait to do this, or not do it? Feedback welcome!
>>
>> (if theres no objections i'll do it friday or this weekend, so theres
>> some lead time for anyone who's not setup for that yet)
>>
>> Best wishes and great health to all
>> -carter
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/0a221b95/attachment.html>

From chessai1996 at gmail.com  Wed Mar 18 21:28:51 2020
From: chessai1996 at gmail.com (chessai .)
Date: Wed, 18 Mar 2020 14:28:51 -0700
Subject: [core libraries] Re: intent to enable 2fa requirement for
 github.com/haskell org
In-Reply-To: <CAHYVw0xA-Fzh1G-YUxWtV1HgOg=5o4jwYKNOipU-7dpYrYmA-g@mail.gmail.com>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <CAMgWh9s9DE58HLH4WBup0q2OajKEcC6d9ohm8ZXt+kn+kFRkUA@mail.gmail.com>
 <CAHYVw0xA-Fzh1G-YUxWtV1HgOg=5o4jwYKNOipU-7dpYrYmA-g@mail.gmail.com>
Message-ID: <CAD34_k+9nPmnS=dzSRzaS5E2q=YDm64ii3T8FM+4Me+bdUVdJg@mail.gmail.com>

I agree with Carter here, 2FA is very accessible and if someone runs into a
problem we can just tell them they need 2FA. It wouldn't be much more than
a 10 minute disruption. Perhaps we could send out notice that it will take
into effect at a certain point, maybe giving people a week or two. But we
should really have this be mandatory.

On Wed, Mar 18, 2020, 1:09 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> true, otoh, 2fa in various usable forms has been widely available for
> years, and we can reonboard people pretty easily. Its critical haskell
> infra and to the best of my knowledge, current 2fa tooling is pretty
> accessible to everyone globally. If someone has specific issues we can
> address them as they arise!
>
> On Wed, Mar 18, 2020 at 3:45 PM David Feuer <david.feuer at gmail.com> wrote:
>
>> That's not a lot of lead time.
>>
>> On Wed, Mar 18, 2020, 2:47 PM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> hey everyone, because so much important stuff for the community, it
>>> makes sense to add 2fa required for the org, are there any good reasons to
>>> either wait to do this, or not do it? Feedback welcome!
>>>
>>> (if theres no objections i'll do it friday or this weekend, so theres
>>> some lead time for anyone who's not setup for that yet)
>>>
>>> Best wishes and great health to all
>>> -carter
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "haskell-core-libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-core-libraries+unsubscribe at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0xA-Fzh1G-YUxWtV1HgOg%3D5o4jwYKNOipU-7dpYrYmA-g%40mail.gmail.com
> <https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0xA-Fzh1G-YUxWtV1HgOg%3D5o4jwYKNOipU-7dpYrYmA-g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/3da7a01d/attachment.html>

From alexandreR_B at outlook.com  Wed Mar 18 21:38:31 2020
From: alexandreR_B at outlook.com (=?iso-8859-1?Q?Alexandre_Rodrigues_Bald=E9?=)
Date: Wed, 18 Mar 2020 21:38:31 +0000
Subject: [core libraries] Re: intent to enable 2fa requirement for
 github.com/haskell org
In-Reply-To: <CAD34_k+9nPmnS=dzSRzaS5E2q=YDm64ii3T8FM+4Me+bdUVdJg@mail.gmail.com>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <CAMgWh9s9DE58HLH4WBup0q2OajKEcC6d9ohm8ZXt+kn+kFRkUA@mail.gmail.com>
 <CAHYVw0xA-Fzh1G-YUxWtV1HgOg=5o4jwYKNOipU-7dpYrYmA-g@mail.gmail.com>,
 <CAD34_k+9nPmnS=dzSRzaS5E2q=YDm64ii3T8FM+4Me+bdUVdJg@mail.gmail.com>
Message-ID: <MR2P264MB0515515A17C250BD7B2E1C89FFF70@MR2P264MB0515.FRAP264.PROD.OUTLOOK.COM>

This is a sensible measure, but I doubt people that contribute to GHC via GitHub (even if just for read access) are on this maling list.

Perhaps an issue can be created to notify people of this, rather than let them run into errors and wonder what they did wrong.

________________________________
De: ghc-devs <ghc-devs-bounces at haskell.org> em nome de chessai . <chessai1996 at gmail.com>
Enviado: Wednesday, March 18, 2020 9:28:51 PM
Para: Carter Schonwald <carter.schonwald at gmail.com>
Cc: David Feuer <david.feuer at gmail.com>; Haskell Libraries <libraries at haskell.org>; ghc-devs <ghc-devs at haskell.org>; core-libraries-committee at haskell.org <core-libraries-committee at haskell.org>
Assunto: Re: [core libraries] Re: intent to enable 2fa requirement for github.com/haskell org

I agree with Carter here, 2FA is very accessible and if someone runs into a problem we can just tell them they need 2FA. It wouldn't be much more than a 10 minute disruption. Perhaps we could send out notice that it will take into effect at a certain point, maybe giving people a week or two. But we should really have this be mandatory.

On Wed, Mar 18, 2020, 1:09 PM Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
true, otoh, 2fa in various usable forms has been widely available for years, and we can reonboard people pretty easily. Its critical haskell infra and to the best of my knowledge, current 2fa tooling is pretty accessible to everyone globally. If someone has specific issues we can address them as they arise!

On Wed, Mar 18, 2020 at 3:45 PM David Feuer <david.feuer at gmail.com<mailto:david.feuer at gmail.com>> wrote:
That's not a lot of lead time.

On Wed, Mar 18, 2020, 2:47 PM Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
hey everyone, because so much important stuff for the community, it makes sense to add 2fa required for the org, are there any good reasons to either wait to do this, or not do it? Feedback welcome!

(if theres no objections i'll do it friday or this weekend, so theres some lead time for anyone who's not setup for that yet)

Best wishes and great health to all
-carter
_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto:Libraries at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com<mailto:haskell-core-libraries+unsubscribe at googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0xA-Fzh1G-YUxWtV1HgOg%3D5o4jwYKNOipU-7dpYrYmA-g%40mail.gmail.com<https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0xA-Fzh1G-YUxWtV1HgOg%3D5o4jwYKNOipU-7dpYrYmA-g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/e875a0b0/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 18 22:07:25 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 18 Mar 2020 18:07:25 -0400
Subject: [core libraries] Re: intent to enable 2fa requirement for
 github.com/haskell org
In-Reply-To: <MR2P264MB0515515A17C250BD7B2E1C89FFF70@MR2P264MB0515.FRAP264.PROD.OUTLOOK.COM>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <CAMgWh9s9DE58HLH4WBup0q2OajKEcC6d9ohm8ZXt+kn+kFRkUA@mail.gmail.com>
 <CAHYVw0xA-Fzh1G-YUxWtV1HgOg=5o4jwYKNOipU-7dpYrYmA-g@mail.gmail.com>
 <CAD34_k+9nPmnS=dzSRzaS5E2q=YDm64ii3T8FM+4Me+bdUVdJg@mail.gmail.com>
 <MR2P264MB0515515A17C250BD7B2E1C89FFF70@MR2P264MB0515.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <CAHYVw0yw2zhuBRABEvGkxstVkPwG1_-ik7d70-njtz4sFbuhkg@mail.gmail.com>

theres a reason i emailed ghc-devs + libraries, to make sure its visible!

we can remediate any perms that get busted that need to be reinstated, but
its been sitting like it is for long enough :)

On Wed, Mar 18, 2020 at 5:38 PM Alexandre Rodrigues Baldé <
alexandreR_B at outlook.com> wrote:

> This is a sensible measure, but I doubt people that contribute to GHC via
> GitHub (even if just for read access) are on this maling list.
>
>
>
> Perhaps an issue can be created to notify people of this, rather than let
> them run into errors and wonder what they did wrong.
>
>
> ------------------------------
> *De:* ghc-devs <ghc-devs-bounces at haskell.org> em nome de chessai . <
> chessai1996 at gmail.com>
> *Enviado:* Wednesday, March 18, 2020 9:28:51 PM
> *Para:* Carter Schonwald <carter.schonwald at gmail.com>
> *Cc:* David Feuer <david.feuer at gmail.com>; Haskell Libraries <
> libraries at haskell.org>; ghc-devs <ghc-devs at haskell.org>;
> core-libraries-committee at haskell.org <core-libraries-committee at haskell.org
> >
> *Assunto:* Re: [core libraries] Re: intent to enable 2fa requirement for
> github.com/haskell org
>
> I agree with Carter here, 2FA is very accessible and if someone runs into
> a problem we can just tell them they need 2FA. It wouldn't be much more
> than a 10 minute disruption. Perhaps we could send out notice that it will
> take into effect at a certain point, maybe giving people a week or two. But
> we should really have this be mandatory.
>
> On Wed, Mar 18, 2020, 1:09 PM Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> true, otoh, 2fa in various usable forms has been widely available for
> years, and we can reonboard people pretty easily. Its critical haskell
> infra and to the best of my knowledge, current 2fa tooling is pretty
> accessible to everyone globally. If someone has specific issues we can
> address them as they arise!
>
> On Wed, Mar 18, 2020 at 3:45 PM David Feuer <david.feuer at gmail.com> wrote:
>
> That's not a lot of lead time.
>
> On Wed, Mar 18, 2020, 2:47 PM Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> hey everyone, because so much important stuff for the community, it makes
> sense to add 2fa required for the org, are there any good reasons to either
> wait to do this, or not do it? Feedback welcome!
>
> (if theres no objections i'll do it friday or this weekend, so theres some
> lead time for anyone who's not setup for that yet)
>
> Best wishes and great health to all
> -carter
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> --
> You received this message because you are subscribed to the Google Groups
> "haskell-core-libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-core-libraries+unsubscribe at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0xA-Fzh1G-YUxWtV1HgOg%3D5o4jwYKNOipU-7dpYrYmA-g%40mail.gmail.com
> <https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0xA-Fzh1G-YUxWtV1HgOg%3D5o4jwYKNOipU-7dpYrYmA-g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/92b566d1/attachment.html>

From oleg.grenrus at iki.fi  Wed Mar 18 22:47:47 2020
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Thu, 19 Mar 2020 00:47:47 +0200
Subject: [core libraries] Re: intent to enable 2fa requirement for
 github.com/haskell org
In-Reply-To: <MR2P264MB0515515A17C250BD7B2E1C89FFF70@MR2P264MB0515.FRAP264.PROD.OUTLOOK.COM>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <CAMgWh9s9DE58HLH4WBup0q2OajKEcC6d9ohm8ZXt+kn+kFRkUA@mail.gmail.com>
 <CAHYVw0xA-Fzh1G-YUxWtV1HgOg=5o4jwYKNOipU-7dpYrYmA-g@mail.gmail.com>
 <CAD34_k+9nPmnS=dzSRzaS5E2q=YDm64ii3T8FM+4Me+bdUVdJg@mail.gmail.com>
 <MR2P264MB0515515A17C250BD7B2E1C89FFF70@MR2P264MB0515.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <da362738-7e31-d459-0374-2a0d36376430@iki.fi>

For read access you don't need 2FA (= be in the GitHub organization). 
Can you clarify what could go wrong?

- Oleg

On 18.3.2020 23.38, Alexandre Rodrigues Baldé wrote:
>
> This is a sensible measure, but I doubt people that contribute to GHC 
> via GitHub (even if just for read access) are on this maling list.
>
> Perhaps an issue can be created to notify people of this, rather than 
> let them run into errors and wonder what they did wrong.
>
> ------------------------------------------------------------------------
> *De:* ghc-devs <ghc-devs-bounces at haskell.org> em nome de chessai . 
> <chessai1996 at gmail.com>
> *Enviado:* Wednesday, March 18, 2020 9:28:51 PM
> *Para:* Carter Schonwald <carter.schonwald at gmail.com>
> *Cc:* David Feuer <david.feuer at gmail.com>; Haskell Libraries 
> <libraries at haskell.org>; ghc-devs <ghc-devs at haskell.org>; 
> core-libraries-committee at haskell.org 
> <core-libraries-committee at haskell.org>
> *Assunto:* Re: [core libraries] Re: intent to enable 2fa requirement 
> for github.com/haskell org
> I agree with Carter here, 2FA is very accessible and if someone runs 
> into a problem we can just tell them they need 2FA. It wouldn't be 
> much more than a 10 minute disruption. Perhaps we could send out 
> notice that it will take into effect at a certain point, maybe giving 
> people a week or two. But we should really have this be mandatory.
>
> On Wed, Mar 18, 2020, 1:09 PM Carter Schonwald 
> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>
>     true, otoh, 2fa in various usable forms has been widely available
>     for years, and we can reonboard people pretty easily. Its critical
>     haskell infra and to the best of my knowledge, current 2fa tooling
>     is pretty accessible to everyone globally. If someone has specific
>     issues we can address them as they arise!
>
>     On Wed, Mar 18, 2020 at 3:45 PM David Feuer <david.feuer at gmail.com
>     <mailto:david.feuer at gmail.com>> wrote:
>
>         That's not a lot of lead time.
>
>         On Wed, Mar 18, 2020, 2:47 PM Carter Schonwald
>         <carter.schonwald at gmail.com
>         <mailto:carter.schonwald at gmail.com>> wrote:
>
>             hey everyone, because so much important stuff for the
>             community, it makes sense to add 2fa required for the org,
>             are there any good reasons to either wait to do this, or
>             not do it? Feedback welcome!
>
>             (if theres no objections i'll do it friday or this
>             weekend, so theres some lead time for anyone who's not
>             setup for that yet)
>
>             Best wishes and great health to all
>             -carter
>             _______________________________________________
>             Libraries mailing list
>             Libraries at haskell.org <mailto:Libraries at haskell.org>
>             http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>     -- 
>     You received this message because you are subscribed to the Google
>     Groups "haskell-core-libraries" group.
>     To unsubscribe from this group and stop receiving emails from it,
>     send an email to
>     haskell-core-libraries+unsubscribe at googlegroups.com
>     <mailto:haskell-core-libraries+unsubscribe at googlegroups.com>.
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0xA-Fzh1G-YUxWtV1HgOg%3D5o4jwYKNOipU-7dpYrYmA-g%40mail.gmail.com
>     <https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0xA-Fzh1G-YUxWtV1HgOg%3D5o4jwYKNOipU-7dpYrYmA-g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200319/bbd97b97/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 18 23:05:16 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 18 Mar 2020 19:05:16 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
Message-ID: <CAHYVw0wxO88BttBejW9bpOn-huZc47e7hq1G8iz4z+3CMK6t=Q@mail.gmail.com>

No. You don’t.  You can use a yubi key and or a totp tool like google
Authenticator or 1Password etc. no phones required

On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan at dcoutts.me.uk> wrote:

> On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> > hey everyone, because so much important stuff for the community, it
> > makes sense to add 2fa required for the org, are there any good
> > reasons to either wait to do this, or not do it? Feedback welcome!
>
> I think I might get cut off.
>
> Is it not still the case that github's 2fa needs a program running on a
> mobile phone, or an SMS-capable mobile phone? Is there any support for
> normal tools running on a normal Linux machine?
>
> (I think last time I tried to use the SMS route, it refused to send SMS
> messages to my landline, despite the fact that I can receive them)
>
>
> Duncan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/f4aea982/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 18 23:52:36 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 18 Mar 2020 19:52:36 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <a47baec89f766bd64517eb02bec49baf625cf095.camel@dcoutts.me.uk>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
 <CAHYVw0wxO88BttBejW9bpOn-huZc47e7hq1G8iz4z+3CMK6t=Q@mail.gmail.com>
 <a47baec89f766bd64517eb02bec49baf625cf095.camel@dcoutts.me.uk>
Message-ID: <CAHYVw0x5CTOmQDLp3+89muQ+vXgmcmgo=gCHs8kjBHOMb=5Ksw@mail.gmail.com>

Awesome!

After talking with several folks, feedback has been that best practices are
to make sure the notice is a week before hand.

So what I’ll do is personally reach out to those who aren’t 2fa enabled in
the Haskell gh org (and haven’t commented on this thread )and ask them to
enable 2fa on their GitHub account. Perhaps I should attach a 2fa options
explainer !

I’ll look at folks responses and if everyone active has made the switch
over, I’ll look to do a transition next Monday or Tuesday.


Be well! (Nyc and many other places are pretty strange right now :/ )

-Carter

On Wed, Mar 18, 2020 at 7:42 PM Duncan Coutts <duncan at dcoutts.me.uk> wrote:

> On Wed, 2020-03-18 at 19:05 -0400, Carter Schonwald wrote:
> > No. You don’t.  You can use a yubi key and or a totp tool like google
> > Authenticator or 1Password etc. no phones required
>
> It took me a while, but I have successfully managed to turn 2FA back
> into 1FA.
>
> In case it helps anyone else, generate your 2FA response with
>
> $ oathtool --totp -b $the-2fa-secret
>
> Where $the-2fa-secret is the code github gives you after the recovery
> codes (initially shown as a barcode, but they'll give you the actual
> code if you click the link).
>
> > On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan at dcoutts.me.uk>
> wrote:
> > > On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> > > > hey everyone, because so much important stuff for the community, it
> > > > makes sense to add 2fa required for the org, are there any good
> > > > reasons to either wait to do this, or not do it? Feedback welcome!
> > >
> > > I think I might get cut off.
> > >
> > > Is it not still the case that github's 2fa needs a program running on a
> > > mobile phone, or an SMS-capable mobile phone? Is there any support for
> > > normal tools running on a normal Linux machine?
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/aa93eb91/attachment.html>

From ben at well-typed.com  Wed Mar 18 19:05:39 2020
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 18 Mar 2020 15:05:39 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
Message-ID: <3F698C66-BFAE-46DA-B902-BE079C8DD69E@well-typed.com>

I agree that this would be a good idea.

Cheers,

— Ben 

On March 18, 2020 2:46:47 PM EDT, Carter Schonwald <carter.schonwald at gmail.com> wrote:
>hey everyone, because so much important stuff for the community, it
>makes
>sense to add 2fa required for the org, are there any good reasons to
>either
>wait to do this, or not do it? Feedback welcome!
>
>(if theres no objections i'll do it friday or this weekend, so theres
>some
>lead time for anyone who's not setup for that yet)
>
>Best wishes and great health to all
>-carter

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200318/602422f0/attachment.html>

From simonpj at microsoft.com  Thu Mar 19 08:57:26 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 19 Mar 2020 08:57:26 +0000
Subject: [core libraries] Re: intent to enable 2fa requirement for
 github.com/haskell org
In-Reply-To: <CAHYVw0x5CTOmQDLp3+89muQ+vXgmcmgo=gCHs8kjBHOMb=5Ksw@mail.gmail.com>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
 <CAHYVw0wxO88BttBejW9bpOn-huZc47e7hq1G8iz4z+3CMK6t=Q@mail.gmail.com>
 <a47baec89f766bd64517eb02bec49baf625cf095.camel@dcoutts.me.uk>
 <CAHYVw0x5CTOmQDLp3+89muQ+vXgmcmgo=gCHs8kjBHOMb=5Ksw@mail.gmail.com>
Message-ID: <VI1PR8303MB0093A566FABB1FD389932C72ADF40@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

I have not been following this.  What is the consequence for a regular GHC developer, or someone contributing to GHC?

In any announcement please give a way to verify “am I affected?”

Thanks

Simon

From: haskell-core-libraries at googlegroups.com <haskell-core-libraries at googlegroups.com> On Behalf Of Carter Schonwald
Sent: 18 March 2020 23:53
To: Duncan Coutts <duncan at dcoutts.me.uk>
Cc: Haskell Libraries <libraries at haskell.org>; core-libraries-committee at haskell.org; ghc-devs <ghc-devs at haskell.org>
Subject: [core libraries] Re: intent to enable 2fa requirement for github.com/haskell org

Awesome!

After talking with several folks, feedback has been that best practices are to make sure the notice is a week before hand.

So what I’ll do is personally reach out to those who aren’t 2fa enabled in the Haskell gh org (and haven’t commented on this thread )and ask them to enable 2fa on their GitHub account. Perhaps I should attach a 2fa options explainer !

I’ll look at folks responses and if everyone active has made the switch over, I’ll look to do a transition next Monday or Tuesday.


Be well! (Nyc and many other places are pretty strange right now :/ )

-Carter

On Wed, Mar 18, 2020 at 7:42 PM Duncan Coutts <duncan at dcoutts.me.uk<mailto:duncan at dcoutts.me.uk>> wrote:
On Wed, 2020-03-18 at 19:05 -0400, Carter Schonwald wrote:
> No. You don’t.  You can use a yubi key and or a totp tool like google
> Authenticator or 1Password etc. no phones required

It took me a while, but I have successfully managed to turn 2FA back
into 1FA.

In case it helps anyone else, generate your 2FA response with

$ oathtool --totp -b $the-2fa-secret

Where $the-2fa-secret is the code github gives you after the recovery
codes (initially shown as a barcode, but they'll give you the actual
code if you click the link).

> On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan at dcoutts.me.uk<mailto:duncan at dcoutts.me.uk>> wrote:
> > On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> > > hey everyone, because so much important stuff for the community, it
> > > makes sense to add 2fa required for the org, are there any good
> > > reasons to either wait to do this, or not do it? Feedback welcome!
> >
> > I think I might get cut off.
> >
> > Is it not still the case that github's 2fa needs a program running on a
> > mobile phone, or an SMS-capable mobile phone? Is there any support for
> > normal tools running on a normal Linux machine?
> >
--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com<mailto:haskell-core-libraries+unsubscribe at googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAHYVw0x5CTOmQDLp3%2B89muQ%2BvXgmcmgo%3DgCHs8kjBHOMb%3D5Ksw%40mail.gmail.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fhaskell-core-libraries%2FCAHYVw0x5CTOmQDLp3%252B89muQ%252BvXgmcmgo%253DgCHs8kjBHOMb%253D5Ksw%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Csimonpj%40microsoft.com%7C7f5dc75648ac4e8a4fe708d7cb977cae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637201723806844496&sdata=CP9SSJCInfaF%2Fxhd8%2FdO5zOj1Wsr%2FVbd6J9F5%2BeqHS4%3D&reserved=0>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200319/22e6642e/attachment-0001.html>

From rae at richarde.dev  Thu Mar 19 09:44:15 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 19 Mar 2020 09:44:15 +0000
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <CAHYVw0x5CTOmQDLp3+89muQ+vXgmcmgo=gCHs8kjBHOMb=5Ksw@mail.gmail.com>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
 <CAHYVw0wxO88BttBejW9bpOn-huZc47e7hq1G8iz4z+3CMK6t=Q@mail.gmail.com>
 <a47baec89f766bd64517eb02bec49baf625cf095.camel@dcoutts.me.uk>
 <CAHYVw0x5CTOmQDLp3+89muQ+vXgmcmgo=gCHs8kjBHOMb=5Ksw@mail.gmail.com>
Message-ID: <2EC32AA7-BA58-4456-AAB0-0950A7D2DC8A@richarde.dev>



> On Mar 18, 2020, at 11:52 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> After talking with several folks, feedback has been that best practices are to make sure the notice is a week before hand. 
> 
> So what I’ll do is personally reach out to those who aren’t 2fa enabled in the Haskell gh org (and haven’t commented on this thread )and ask them to enable 2fa on their GitHub account. Perhaps I should attach a 2fa options explainer ! 
> 
> I’ll look at folks responses and if everyone active has made the switch over, I’ll look to do a transition next Monday or Tuesday. 
> 

If best practices are to wait a week... shouldn't we wait a week? There's no fire here.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200319/1c66f83f/attachment.html>

From carter.schonwald at gmail.com  Thu Mar 19 14:55:29 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 19 Mar 2020 10:55:29 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <2EC32AA7-BA58-4456-AAB0-0950A7D2DC8A@richarde.dev>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
 <CAHYVw0wxO88BttBejW9bpOn-huZc47e7hq1G8iz4z+3CMK6t=Q@mail.gmail.com>
 <a47baec89f766bd64517eb02bec49baf625cf095.camel@dcoutts.me.uk>
 <CAHYVw0x5CTOmQDLp3+89muQ+vXgmcmgo=gCHs8kjBHOMb=5Ksw@mail.gmail.com>
 <2EC32AA7-BA58-4456-AAB0-0950A7D2DC8A@richarde.dev>
Message-ID: <CAHYVw0zkRKypEfPDuRxEFTwBEXQjJZqCZo98x6vvoRn+ohrDTA@mail.gmail.com>

@ Simon: you already have 2fa enabled, youre not on the list of users who
do *not* have 2fa enabled. Its just an extra login prompt the first time
you login from a new device or do anything in the "are you sure you want to
do that change".

SO enabling 2fa is largely invisible to contributors aside from the 5
minutes to setup, and the message i sent out directly to every person who
would be impacted that hasn't already replied to this email thread listed a
number of options that could choose (though i should have also included a
url, but if anyones confused i hope they ask and I can help)

@richard  indeed, this is why i also directly and individually emailed
every member/contributor of the github haskell org individually (who
doesnt have 2fa setup).  Some of them dont have an easy to track down email
address!  Basically everyone who's been active in the past two years has
responded already or indicated they'll set it up this coming weekend.  (in
1-2 cases, it helped remind that they'd forgotten to setup 2fa even though
they had planned to )



On Thu, Mar 19, 2020 at 5:44 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Mar 18, 2020, at 11:52 PM, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> After talking with several folks, feedback has been that best practices
> are to make sure the notice is a week before hand.
>
> So what I’ll do is personally reach out to those who aren’t 2fa enabled in
> the Haskell gh org (and haven’t commented on this thread )and ask them to
> enable 2fa on their GitHub account. Perhaps I should attach a 2fa options
> explainer !
>
> I’ll look at folks responses and if everyone active has made the switch
> over, I’ll look to do a transition next Monday or Tuesday.
>
>
> If best practices are to wait a week... shouldn't we wait a week? There's
> no fire here.
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200319/9d2e1582/attachment.html>

From chessai1996 at gmail.com  Sat Mar 21 18:44:07 2020
From: chessai1996 at gmail.com (chessai .)
Date: Sat, 21 Mar 2020 11:44:07 -0700
Subject: Alternative instance for Const
Message-ID: <CAD34_k+vsafOn0M8-vOvcT3vHD4LWsyc3DcL4pCp5sfEYJAX5A@mail.gmail.com>

We already have

instance Monoid m => Applicative (Const m)

we could easily add

instance Monoid m => Alternative (Const m) where
  empty = coerce mempty
  (<|>) = coerce (<>)

which trivially satisfies left/right identity and associativity.

I propose we add this instance to base.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200321/e0f1d9c6/attachment.html>

From zemyla at gmail.com  Sat Mar 21 20:22:39 2020
From: zemyla at gmail.com (Zemyla)
Date: Sat, 21 Mar 2020 15:22:39 -0500
Subject: Alternative instance for Const
In-Reply-To: <CAD34_k+vsafOn0M8-vOvcT3vHD4LWsyc3DcL4pCp5sfEYJAX5A@mail.gmail.com>
References: <CAD34_k+vsafOn0M8-vOvcT3vHD4LWsyc3DcL4pCp5sfEYJAX5A@mail.gmail.com>
Message-ID: <CAK7nUjj-e4CEoqW=nxDgW-jjRGTRZq6HUTwjdMkpg6dv6=kj2g@mail.gmail.com>

No, the Alternative instance should be based on semirings instead. The one
you propose isn't distributive.

Lacking general semirings, the best we can do at the moment is newtypes for
each semiring we have. For instance:

newtype NumConst a b = NumConst { getNumConst :: a }
  deriving (Functor)

instance Num a => Applicative (NumConst a) where
  pure = const (NumConst 1)
  (<*>) = (coerce :: (a -> a -> a) -> NumConst a (u -> v) -> NumConst a u
-> NumConst a v) (*)

instance Num a => Alternative (NumConst a) where
  empty = NumConst 0
  (<|>) = (coerce :: (a -> a -> a) -> NumConst a b -> NumConst a b ->
NumConst a b) (+)

On Sat, Mar 21, 2020, 13:44 chessai . <chessai1996 at gmail.com> wrote:

> We already have
>
> instance Monoid m => Applicative (Const m)
>
> we could easily add
>
> instance Monoid m => Alternative (Const m) where
>   empty = coerce mempty
>   (<|>) = coerce (<>)
>
> which trivially satisfies left/right identity and associativity.
>
> I propose we add this instance to base.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200321/930ef178/attachment.html>

From simon.jakobi at googlemail.com  Sat Mar 21 21:46:32 2020
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Sat, 21 Mar 2020 22:46:32 +0100
Subject: Alternative instance for Const
In-Reply-To: <CAK7nUjj-e4CEoqW=nxDgW-jjRGTRZq6HUTwjdMkpg6dv6=kj2g@mail.gmail.com>
References: <CAD34_k+vsafOn0M8-vOvcT3vHD4LWsyc3DcL4pCp5sfEYJAX5A@mail.gmail.com>
 <CAK7nUjj-e4CEoqW=nxDgW-jjRGTRZq6HUTwjdMkpg6dv6=kj2g@mail.gmail.com>
Message-ID: <CAGtp2SgohG=pPRO2CqANfBxV12BW09DuCu-Mqbe5jDEz6qAdkA@mail.gmail.com>

Hi Zemyla,

Could you clarify where the requirement for distributivity comes from?

The haddocks for Alternative don't mention it:
http://downloads.haskell.org/~ghc/8.10.1-rc1/docs/html/libraries/base-4.14.0.0/Control-Applicative.html#t:Alternative

Thanks,
Simon

Am Sa., 21. März 2020 um 21:23 Uhr schrieb Zemyla <zemyla at gmail.com>:
>
> No, the Alternative instance should be based on semirings instead. The one you propose isn't distributive.
>
> Lacking general semirings, the best we can do at the moment is newtypes for each semiring we have. For instance:
>
> newtype NumConst a b = NumConst { getNumConst :: a }
>   deriving (Functor)
>
> instance Num a => Applicative (NumConst a) where
>   pure = const (NumConst 1)
>   (<*>) = (coerce :: (a -> a -> a) -> NumConst a (u -> v) -> NumConst a u -> NumConst a v) (*)
>
> instance Num a => Alternative (NumConst a) where
>   empty = NumConst 0
>   (<|>) = (coerce :: (a -> a -> a) -> NumConst a b -> NumConst a b -> NumConst a b) (+)
>
> On Sat, Mar 21, 2020, 13:44 chessai . <chessai1996 at gmail.com> wrote:
>>
>> We already have
>>
>> instance Monoid m => Applicative (Const m)
>>
>> we could easily add
>>
>> instance Monoid m => Alternative (Const m) where
>>   empty = coerce mempty
>>   (<|>) = coerce (<>)
>>
>> which trivially satisfies left/right identity and associativity.
>>
>> I propose we add this instance to base.
>> _______________________________________________
>> 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 oleg.grenrus at iki.fi  Sat Mar 21 22:54:12 2020
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sun, 22 Mar 2020 00:54:12 +0200
Subject: Alternative instance for Const
In-Reply-To: <CAGtp2SgohG=pPRO2CqANfBxV12BW09DuCu-Mqbe5jDEz6qAdkA@mail.gmail.com>
References: <CAD34_k+vsafOn0M8-vOvcT3vHD4LWsyc3DcL4pCp5sfEYJAX5A@mail.gmail.com>
 <CAK7nUjj-e4CEoqW=nxDgW-jjRGTRZq6HUTwjdMkpg6dv6=kj2g@mail.gmail.com>
 <CAGtp2SgohG=pPRO2CqANfBxV12BW09DuCu-Mqbe5jDEz6qAdkA@mail.gmail.com>
Message-ID: <2db5f636-f1dd-fc9a-858c-ae1b6a42227a@iki.fi>

https://wiki.haskell.org/Typeclassopedia#Laws_6

On 21.3.2020 23.46, Simon Jakobi via Libraries wrote:
> Hi Zemyla,
>
> Could you clarify where the requirement for distributivity comes from?
>
> The haddocks for Alternative don't mention it:
> http://downloads.haskell.org/~ghc/8.10.1-rc1/docs/html/libraries/base-4.14.0.0/Control-Applicative.html#t:Alternative
>
> Thanks,
> Simon
>
> Am Sa., 21. März 2020 um 21:23 Uhr schrieb Zemyla <zemyla at gmail.com>:
>> No, the Alternative instance should be based on semirings instead. The one you propose isn't distributive.
>>
>> Lacking general semirings, the best we can do at the moment is newtypes for each semiring we have. For instance:
>>
>> newtype NumConst a b = NumConst { getNumConst :: a }
>>    deriving (Functor)
>>
>> instance Num a => Applicative (NumConst a) where
>>    pure = const (NumConst 1)
>>    (<*>) = (coerce :: (a -> a -> a) -> NumConst a (u -> v) -> NumConst a u -> NumConst a v) (*)
>>
>> instance Num a => Alternative (NumConst a) where
>>    empty = NumConst 0
>>    (<|>) = (coerce :: (a -> a -> a) -> NumConst a b -> NumConst a b -> NumConst a b) (+)
>>
>> On Sat, Mar 21, 2020, 13:44 chessai . <chessai1996 at gmail.com> wrote:
>>> We already have
>>>
>>> instance Monoid m => Applicative (Const m)
>>>
>>> we could easily add
>>>
>>> instance Monoid m => Alternative (Const m) where
>>>    empty = coerce mempty
>>>    (<|>) = coerce (<>)
>>>
>>> which trivially satisfies left/right identity and associativity.
>>>
>>> I propose we add this instance to base.
>>> _______________________________________________
>>> 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

From chessai1996 at gmail.com  Sat Mar 21 23:23:37 2020
From: chessai1996 at gmail.com (chessai .)
Date: Sat, 21 Mar 2020 16:23:37 -0700
Subject: Alternative instance for Const
In-Reply-To: <2db5f636-f1dd-fc9a-858c-ae1b6a42227a@iki.fi>
References: <CAD34_k+vsafOn0M8-vOvcT3vHD4LWsyc3DcL4pCp5sfEYJAX5A@mail.gmail.com>
 <CAK7nUjj-e4CEoqW=nxDgW-jjRGTRZq6HUTwjdMkpg6dv6=kj2g@mail.gmail.com>
 <CAGtp2SgohG=pPRO2CqANfBxV12BW09DuCu-Mqbe5jDEz6qAdkA@mail.gmail.com>
 <2db5f636-f1dd-fc9a-858c-ae1b6a42227a@iki.fi>
Message-ID: <CAD34_kJah4z2GoRp_9i+hVJiaBDQ_yv-GjERq75-OFRtOuwvjA@mail.gmail.com>

As far as I'm aware, distributivity is neither required nor adhered to by
many types in core libraries and beyond. Only left and right identity, and
associativity. This instance would also play well with the existing
Applicative instance.

On Sat, Mar 21, 2020, 3:54 PM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

> https://wiki.haskell.org/Typeclassopedia#Laws_6
>
> On 21.3.2020 23.46, Simon Jakobi via Libraries wrote:
> > Hi Zemyla,
> >
> > Could you clarify where the requirement for distributivity comes from?
> >
> > The haddocks for Alternative don't mention it:
> >
> http://downloads.haskell.org/~ghc/8.10.1-rc1/docs/html/libraries/base-4.14.0.0/Control-Applicative.html#t:Alternative
> >
> > Thanks,
> > Simon
> >
> > Am Sa., 21. März 2020 um 21:23 Uhr schrieb Zemyla <zemyla at gmail.com>:
> >> No, the Alternative instance should be based on semirings instead. The
> one you propose isn't distributive.
> >>
> >> Lacking general semirings, the best we can do at the moment is newtypes
> for each semiring we have. For instance:
> >>
> >> newtype NumConst a b = NumConst { getNumConst :: a }
> >>    deriving (Functor)
> >>
> >> instance Num a => Applicative (NumConst a) where
> >>    pure = const (NumConst 1)
> >>    (<*>) = (coerce :: (a -> a -> a) -> NumConst a (u -> v) -> NumConst
> a u -> NumConst a v) (*)
> >>
> >> instance Num a => Alternative (NumConst a) where
> >>    empty = NumConst 0
> >>    (<|>) = (coerce :: (a -> a -> a) -> NumConst a b -> NumConst a b ->
> NumConst a b) (+)
> >>
> >> On Sat, Mar 21, 2020, 13:44 chessai . <chessai1996 at gmail.com> wrote:
> >>> We already have
> >>>
> >>> instance Monoid m => Applicative (Const m)
> >>>
> >>> we could easily add
> >>>
> >>> instance Monoid m => Alternative (Const m) where
> >>>    empty = coerce mempty
> >>>    (<|>) = coerce (<>)
> >>>
> >>> which trivially satisfies left/right identity and associativity.
> >>>
> >>> I propose we add this instance to base.
> >>> _______________________________________________
> >>> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200321/f73ce446/attachment.html>

From andreas.abel at ifi.lmu.de  Sun Mar 22 09:27:07 2020
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Sun, 22 Mar 2020 10:27:07 +0100
Subject: Alternative instance for Const
In-Reply-To: <CAK7nUjj-e4CEoqW=nxDgW-jjRGTRZq6HUTwjdMkpg6dv6=kj2g@mail.gmail.com>
References: <CAD34_k+vsafOn0M8-vOvcT3vHD4LWsyc3DcL4pCp5sfEYJAX5A@mail.gmail.com>
 <CAK7nUjj-e4CEoqW=nxDgW-jjRGTRZq6HUTwjdMkpg6dv6=kj2g@mail.gmail.com>
Message-ID: <e5ae90ef-2f3d-a4c3-d264-5533f563188a@ifi.lmu.de>

 > No, the Alternative instance should be based on semirings instead. The
 > one you propose isn't distributive.

+1.

-1 on non-distributive default instances.

On 2020-03-21 21:22, Zemyla wrote:
> No, the Alternative instance should be based on semirings instead. The 
> one you propose isn't distributive.
> 
> Lacking general semirings, the best we can do at the moment is newtypes 
> for each semiring we have. For instance:
> 
> newtype NumConst a b = NumConst { getNumConst :: a }
>    deriving (Functor)
> 
> instance Num a => Applicative (NumConst a) where
>    pure = const (NumConst 1)
>    (<*>) = (coerce :: (a -> a -> a) -> NumConst a (u -> v) -> NumConst a 
> u -> NumConst a v) (*)
> 
> instance Num a => Alternative (NumConst a) where
>    empty = NumConst 0
>    (<|>) = (coerce :: (a -> a -> a) -> NumConst a b -> NumConst a b -> 
> NumConst a b) (+)
> 
> On Sat, Mar 21, 2020, 13:44 chessai . <chessai1996 at gmail.com 
> <mailto:chessai1996 at gmail.com>> wrote:
> 
>     We already have
> 
>     instance Monoid m => Applicative (Const m)
> 
>     we could easily add
> 
>     instance Monoid m => Alternative (Const m) where
>        empty = coerce mempty
>        (<|>) = coerce (<>)
> 
>     which trivially satisfies left/right identity and associativity.
> 
>     I propose we add this instance to base.
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto: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 zemyla at gmail.com  Sun Mar 22 18:40:07 2020
From: zemyla at gmail.com (Zemyla)
Date: Sun, 22 Mar 2020 13:40:07 -0500
Subject: Export functions on Natural in Numeric.Natural
Message-ID: <CAK7nUjiO6tgH2XXrtfbSGm+vthPTqetUi2qd3-87OGNFk3Aqbw@mail.gmail.com>

Functions in GHC.Natural like naturalToWordMaybe and minusNaturalMaybe are
extremely useful, especially when trying to write provably total functions,
and I wish they were available in a Safe module like Numeric.Natural. I
also want a total function that does the following:

-- This function turns an Integer n into a pair of
-- (fromInteger (abs n), fromInteger (signum n)).
integerToNaturalSign :: Integer -> (Natural, Int)
#if 0
-- This is the reference version, except for the fact that numeric literals
don't exist yet
-- when GHC.Natural is being defined, and fromInteger isn't actually total.
integerToNaturalSign n = case compare n 0 of
  LT -> (fromInteger (negate n), -1)
  EQ -> (0, 0)
  GT -> (fromInteger n, 1)
#elif !defined(MIN_VERSION_integer_gmp)
-- This is like the reference version, except using the newtype wrapper and
MagicHash.
integerToNaturalSign n = case compare n (intToInteger# 0#) of
  LT -> (Natural (negateInteger n), I# (-1#))
  EQ -> (Natural n, I# 0#)
  GT -> (Natural n, I# 1#)
#else
-- We take advantage of the GMP functions and constructors.
integerToNaturalSign (Jn# bn) = (bigNatToNatural bn, I# (-1#))
integerToNaturalSign (S# i#) = case isTrue# (i# <# 0#) of
  True -> (NatS# (int2Word# (negateInt# i#)), I# (-1#))
  _    -> (NatS# (int2Word# i#), I# (i# ># 0#))
integerToNaturalSign (Jp# bn) = (bigNatToNatural bn, I# 1#)
#endif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200322/51c3288d/attachment.html>

From chessai1996 at gmail.com  Sun Mar 22 22:55:22 2020
From: chessai1996 at gmail.com (chessai .)
Date: Sun, 22 Mar 2020 15:55:22 -0700
Subject: Export functions on Natural in Numeric.Natural
In-Reply-To: <CAK7nUjiO6tgH2XXrtfbSGm+vthPTqetUi2qd3-87OGNFk3Aqbw@mail.gmail.com>
References: <CAK7nUjiO6tgH2XXrtfbSGm+vthPTqetUi2qd3-87OGNFk3Aqbw@mail.gmail.com>
Message-ID: <CAD34_kK4xiodNV1C82yf6u=egE+bdxBi4pqPDbt+rN_OJvac7Q@mail.gmail.com>

Sure, I don't see why not. I think powModNatural is also safe.

Are your criteria for a function worth re-exporting from Numeric.Natural that

1. The function does not have an overloaded variant defined in base
(e.g. all the monorphic version of `fromIntegral` in GHC.Natural would
be excluded) and
2. The function is total?

Thanks

On Sun, Mar 22, 2020 at 11:40 AM Zemyla <zemyla at gmail.com> wrote:
>
> Functions in GHC.Natural like naturalToWordMaybe and minusNaturalMaybe are extremely useful, especially when trying to write provably total functions, and I wish they were available in a Safe module like Numeric.Natural. I also want a total function that does the following:
>
> -- This function turns an Integer n into a pair of
> -- (fromInteger (abs n), fromInteger (signum n)).
> integerToNaturalSign :: Integer -> (Natural, Int)
> #if 0
> -- This is the reference version, except for the fact that numeric literals don't exist yet
> -- when GHC.Natural is being defined, and fromInteger isn't actually total.
> integerToNaturalSign n = case compare n 0 of
>   LT -> (fromInteger (negate n), -1)
>   EQ -> (0, 0)
>   GT -> (fromInteger n, 1)
> #elif !defined(MIN_VERSION_integer_gmp)
> -- This is like the reference version, except using the newtype wrapper and MagicHash.
> integerToNaturalSign n = case compare n (intToInteger# 0#) of
>   LT -> (Natural (negateInteger n), I# (-1#))
>   EQ -> (Natural n, I# 0#)
>   GT -> (Natural n, I# 1#)
> #else
> -- We take advantage of the GMP functions and constructors.
> integerToNaturalSign (Jn# bn) = (bigNatToNatural bn, I# (-1#))
> integerToNaturalSign (S# i#) = case isTrue# (i# <# 0#) of
>   True -> (NatS# (int2Word# (negateInt# i#)), I# (-1#))
>   _    -> (NatS# (int2Word# i#), I# (i# ># 0#))
> integerToNaturalSign (Jp# bn) = (bigNatToNatural bn, I# 1#)
> #endif
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From zemyla at gmail.com  Mon Mar 23 01:11:26 2020
From: zemyla at gmail.com (Zemyla)
Date: Sun, 22 Mar 2020 20:11:26 -0500
Subject: Export functions on Natural in Numeric.Natural
In-Reply-To: <CAD34_kK4xiodNV1C82yf6u=egE+bdxBi4pqPDbt+rN_OJvac7Q@mail.gmail.com>
References: <CAK7nUjiO6tgH2XXrtfbSGm+vthPTqetUi2qd3-87OGNFk3Aqbw@mail.gmail.com>
 <CAD34_kK4xiodNV1C82yf6u=egE+bdxBi4pqPDbt+rN_OJvac7Q@mail.gmail.com>
Message-ID: <CAK7nUjj0FTwdbLTY7Ew+4CO9vBJXnOrrD0ScuoJKBpcKNzDdaQ@mail.gmail.com>

That pretty much sums it up.

On Sun, Mar 22, 2020, 17:55 chessai . <chessai1996 at gmail.com> wrote:

> Sure, I don't see why not. I think powModNatural is also safe.
>
> Are your criteria for a function worth re-exporting from Numeric.Natural
> that
>
> 1. The function does not have an overloaded variant defined in base
> (e.g. all the monorphic version of `fromIntegral` in GHC.Natural would
> be excluded) and
> 2. The function is total?
>
> Thanks
>
> On Sun, Mar 22, 2020 at 11:40 AM Zemyla <zemyla at gmail.com> wrote:
> >
> > Functions in GHC.Natural like naturalToWordMaybe and minusNaturalMaybe
> are extremely useful, especially when trying to write provably total
> functions, and I wish they were available in a Safe module like
> Numeric.Natural. I also want a total function that does the following:
> >
> > -- This function turns an Integer n into a pair of
> > -- (fromInteger (abs n), fromInteger (signum n)).
> > integerToNaturalSign :: Integer -> (Natural, Int)
> > #if 0
> > -- This is the reference version, except for the fact that numeric
> literals don't exist yet
> > -- when GHC.Natural is being defined, and fromInteger isn't actually
> total.
> > integerToNaturalSign n = case compare n 0 of
> >   LT -> (fromInteger (negate n), -1)
> >   EQ -> (0, 0)
> >   GT -> (fromInteger n, 1)
> > #elif !defined(MIN_VERSION_integer_gmp)
> > -- This is like the reference version, except using the newtype wrapper
> and MagicHash.
> > integerToNaturalSign n = case compare n (intToInteger# 0#) of
> >   LT -> (Natural (negateInteger n), I# (-1#))
> >   EQ -> (Natural n, I# 0#)
> >   GT -> (Natural n, I# 1#)
> > #else
> > -- We take advantage of the GMP functions and constructors.
> > integerToNaturalSign (Jn# bn) = (bigNatToNatural bn, I# (-1#))
> > integerToNaturalSign (S# i#) = case isTrue# (i# <# 0#) of
> >   True -> (NatS# (int2Word# (negateInt# i#)), I# (-1#))
> >   _    -> (NatS# (int2Word# i#), I# (i# ># 0#))
> > integerToNaturalSign (Jp# bn) = (bigNatToNatural bn, I# 1#)
> > #endif
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200322/acdd141d/attachment.html>

From chessai1996 at gmail.com  Mon Mar 23 01:16:26 2020
From: chessai1996 at gmail.com (chessai .)
Date: Sun, 22 Mar 2020 18:16:26 -0700
Subject: Export functions on Natural in Numeric.Natural
In-Reply-To: <CAK7nUjj0FTwdbLTY7Ew+4CO9vBJXnOrrD0ScuoJKBpcKNzDdaQ@mail.gmail.com>
References: <CAK7nUjiO6tgH2XXrtfbSGm+vthPTqetUi2qd3-87OGNFk3Aqbw@mail.gmail.com>
 <CAD34_kK4xiodNV1C82yf6u=egE+bdxBi4pqPDbt+rN_OJvac7Q@mail.gmail.com>
 <CAK7nUjj0FTwdbLTY7Ew+4CO9vBJXnOrrD0ScuoJKBpcKNzDdaQ@mail.gmail.com>
Message-ID: <CAD34_kLkkmCH+jNCXzXqpQNctU3GTR=nj-KLLh7X8U+x0QhYAA@mail.gmail.com>

Sounds reasonable to me. Perhaps others can weigh in.

Thanks

On Sun, Mar 22, 2020, 6:11 PM Zemyla <zemyla at gmail.com> wrote:

> That pretty much sums it up.
>
> On Sun, Mar 22, 2020, 17:55 chessai . <chessai1996 at gmail.com> wrote:
>
>> Sure, I don't see why not. I think powModNatural is also safe.
>>
>> Are your criteria for a function worth re-exporting from Numeric.Natural
>> that
>>
>> 1. The function does not have an overloaded variant defined in base
>> (e.g. all the monorphic version of `fromIntegral` in GHC.Natural would
>> be excluded) and
>> 2. The function is total?
>>
>> Thanks
>>
>> On Sun, Mar 22, 2020 at 11:40 AM Zemyla <zemyla at gmail.com> wrote:
>> >
>> > Functions in GHC.Natural like naturalToWordMaybe and minusNaturalMaybe
>> are extremely useful, especially when trying to write provably total
>> functions, and I wish they were available in a Safe module like
>> Numeric.Natural. I also want a total function that does the following:
>> >
>> > -- This function turns an Integer n into a pair of
>> > -- (fromInteger (abs n), fromInteger (signum n)).
>> > integerToNaturalSign :: Integer -> (Natural, Int)
>> > #if 0
>> > -- This is the reference version, except for the fact that numeric
>> literals don't exist yet
>> > -- when GHC.Natural is being defined, and fromInteger isn't actually
>> total.
>> > integerToNaturalSign n = case compare n 0 of
>> >   LT -> (fromInteger (negate n), -1)
>> >   EQ -> (0, 0)
>> >   GT -> (fromInteger n, 1)
>> > #elif !defined(MIN_VERSION_integer_gmp)
>> > -- This is like the reference version, except using the newtype wrapper
>> and MagicHash.
>> > integerToNaturalSign n = case compare n (intToInteger# 0#) of
>> >   LT -> (Natural (negateInteger n), I# (-1#))
>> >   EQ -> (Natural n, I# 0#)
>> >   GT -> (Natural n, I# 1#)
>> > #else
>> > -- We take advantage of the GMP functions and constructors.
>> > integerToNaturalSign (Jn# bn) = (bigNatToNatural bn, I# (-1#))
>> > integerToNaturalSign (S# i#) = case isTrue# (i# <# 0#) of
>> >   True -> (NatS# (int2Word# (negateInt# i#)), I# (-1#))
>> >   _    -> (NatS# (int2Word# i#), I# (i# ># 0#))
>> > integerToNaturalSign (Jp# bn) = (bigNatToNatural bn, I# 1#)
>> > #endif
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200322/a6858acf/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 25 16:47:55 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 25 Mar 2020 12:47:55 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
Message-ID: <CAHYVw0xXJtopprh7fSiGDT6NcmD7E2MkYF+shfDgsgDdYk99Lw@mail.gmail.com>

Duncan, David, please figure out 2fa tools that work for you  and enable
them,


https://github.com/tadfisher/pass-otp

https://github.com/solokeys/solo

https://github.com/herrjemand/awesome-webauthn#hardware-authenticators

https://1password.com/

https://keepass.info/download.html


if you are having trouble figuring out tools you're comfortable using,
please share with us those constraints we can help you!

im here to help (and i'm delaying enabling another day or two to provide
help to some active contributors who are having their own difficulties
setitng up this stuff)

On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan at dcoutts.me.uk> wrote:

> On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> > hey everyone, because so much important stuff for the community, it
> > makes sense to add 2fa required for the org, are there any good
> > reasons to either wait to do this, or not do it? Feedback welcome!
>
> I think I might get cut off.
>
> Is it not still the case that github's 2fa needs a program running on a
> mobile phone, or an SMS-capable mobile phone? Is there any support for
> normal tools running on a normal Linux machine?
>
> (I think last time I tried to use the SMS route, it refused to send SMS
> messages to my landline, despite the fact that I can receive them)
>
>
> Duncan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200325/ca11d330/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 25 19:46:49 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 25 Mar 2020 15:46:49 -0400
Subject: intent to enable 2fa requirement for github.com/haskell org
In-Reply-To: <CAG6_cxYj=Eb2DcJ7FOO+DSSBLcKpwNxQ3yNnq1XHQhcry4LAQQ@mail.gmail.com>
References: <CAHYVw0zsWThsqOWEpzXDE05om-ypAw+9gWks19QZ0+ej5pgofw@mail.gmail.com>
 <ab85e639b18a6421ab2d97fb7f83997e20333a32.camel@dcoutts.me.uk>
 <CAHYVw0xXJtopprh7fSiGDT6NcmD7E2MkYF+shfDgsgDdYk99Lw@mail.gmail.com>
 <CAG6_cxYj=Eb2DcJ7FOO+DSSBLcKpwNxQ3yNnq1XHQhcry4LAQQ@mail.gmail.com>
Message-ID: <CAHYVw0xoxELo3=FkgjQpa1Mx4pJRftXxoJXTkpaTfDrxRiHung@mail.gmail.com>

Yeah, there’s def an incredible diversity of tools that are great in this
space.  And there’s at this point decent tools for almost every platform
constraint imaginable.

On Wed, Mar 25, 2020 at 1:30 PM Giorgio Marinelli <giorgio at marinel.li>
wrote:

> I use the following 2fa tools. They offer also import/export
> functionalities.
>
> - andOTP (Android) https://github.com/andOTP/andOTP
> - OTPClient (Linux) https://github.com/paolostivanin/OTPClient
>
> Regards,
>
>
> Giorgio
>
> On Wed, 25 Mar 2020 at 17:48, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> >
> > Duncan, David, please figure out 2fa tools that work for you  and enable
> them,
> >
> >
> > https://github.com/tadfisher/pass-otp
> >
> > https://github.com/solokeys/solo
> >
> > https://github.com/herrjemand/awesome-webauthn#hardware-authenticators
> >
> > https://1password.com/
> >
> > https://keepass.info/download.html
> >
> >
> > if you are having trouble figuring out tools you're comfortable using,
> please share with us those constraints we can help you!
> >
> > im here to help (and i'm delaying enabling another day or two to provide
> help to some active contributors who are having their own difficulties
> setitng up this stuff)
> >
> > On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan at dcoutts.me.uk>
> wrote:
> >>
> >> On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> >> > hey everyone, because so much important stuff for the community, it
> >> > makes sense to add 2fa required for the org, are there any good
> >> > reasons to either wait to do this, or not do it? Feedback welcome!
> >>
> >> I think I might get cut off.
> >>
> >> Is it not still the case that github's 2fa needs a program running on a
> >> mobile phone, or an SMS-capable mobile phone? Is there any support for
> >> normal tools running on a normal Linux machine?
> >>
> >> (I think last time I tried to use the SMS route, it refused to send SMS
> >> messages to my landline, despite the fact that I can receive them)
> >>
> >>
> >> Duncan
> >>
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200325/34d61e93/attachment.html>

From grey at quietmisdreavus.net  Mon Mar 30 16:21:26 2020
From: grey at quietmisdreavus.net (Grey Mitchell)
Date: Mon, 30 Mar 2020 10:21:26 -0600
Subject: =?UTF-8?Q?Adding_new_contructors_to_IOMode_to_support_"don't_overwrite_i?=
 =?UTF-8?Q?f_already_exists"_behavior?=
In-Reply-To: <038a1a94-74e2-44fe-aff6-3722c98f1295@www.fastmail.com>
References: <038a1a94-74e2-44fe-aff6-3722c98f1295@www.fastmail.com>
Message-ID: <25b5eeed-22c5-4746-a284-0c492a5c1e1f@www.fastmail.com>

The current behavior for System.IO.openFile will either truncate an existing
file (with WriteMode) or append new content to the end (with AppendMode).
However, there's another behavior that's available from the underlying API:
signal an error when the file already exists. I poked around at the code and i
think that with a couple extra variants of IOMode, this behavior could be added
with a relatively small patch.

I have a branch pushed where i added this behavior:
https://gitlab.haskell.org/QuietMisdreavus/ghc/-/commit/1ff18d4d3fc63f42c371f4046ab07405299c6755

I'm a relative newcomer to contributing to GHC or the base library, so if i'm
missing something in my patch please let me know. Specifically, i would like to
know is there's a place i can add a test for this behavior. I'm also open to
changing the names of the new IOModes - this was just something i wrote in to
get something working.

Looking forward to working with maintainers to get this added!

Thanks,
Grey Mitchell (@QuietMisdreavus)

From carter.schonwald at gmail.com  Tue Mar 31 21:51:34 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 31 Mar 2020 17:51:34 -0400
Subject: Adding new contructors to IOMode to support "don't overwrite if
 already exists" behavior
In-Reply-To: <25b5eeed-22c5-4746-a284-0c492a5c1e1f@www.fastmail.com>
References: <038a1a94-74e2-44fe-aff6-3722c98f1295@www.fastmail.com>
 <25b5eeed-22c5-4746-a284-0c492a5c1e1f@www.fastmail.com>
Message-ID: <CAHYVw0zrmzdSTBqr5J-GBPgw=XHVpqbQth1nV46A8TDO2qkszA@mail.gmail.com>

At least naively, this seems like a really good idea.

1) do folks who have more experience across the range of supported
platforms have any opinions about these additional semantics ?

2) are these names suitably descriptive / unambiguous and or otherwise
widely used / discoverable ?

On Mon, Mar 30, 2020 at 12:22 PM Grey Mitchell <grey at quietmisdreavus.net>
wrote:

> The current behavior for System.IO.openFile will either truncate an
> existing
> file (with WriteMode) or append new content to the end (with AppendMode).
> However, there's another behavior that's available from the underlying API:
> signal an error when the file already exists. I poked around at the code
> and i
> think that with a couple extra variants of IOMode, this behavior could be
> added
> with a relatively small patch.
>
> I have a branch pushed where i added this behavior:
>
> https://gitlab.haskell.org/QuietMisdreavus/ghc/-/commit/1ff18d4d3fc63f42c371f4046ab07405299c6755
>
> I'm a relative newcomer to contributing to GHC or the base library, so if
> i'm
> missing something in my patch please let me know. Specifically, i would
> like to
> know is there's a place i can add a test for this behavior. I'm also open
> to
> changing the names of the new IOModes - this was just something i wrote in
> to
> get something working.
>
> Looking forward to working with maintainers to get this added!
>
> Thanks,
> Grey Mitchell (@QuietMisdreavus)
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200331/4d6431de/attachment.html>

From carter.schonwald at gmail.com  Tue Mar 31 22:15:24 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 31 Mar 2020 18:15:24 -0400
Subject: Adding new contructors to IOMode to support "don't overwrite if
 already exists" behavior
In-Reply-To: <CAHYVw0zrmzdSTBqr5J-GBPgw=XHVpqbQth1nV46A8TDO2qkszA@mail.gmail.com>
References: <038a1a94-74e2-44fe-aff6-3722c98f1295@www.fastmail.com>
 <25b5eeed-22c5-4746-a284-0c492a5c1e1f@www.fastmail.com>
 <CAHYVw0zrmzdSTBqr5J-GBPgw=XHVpqbQth1nV46A8TDO2qkszA@mail.gmail.com>
Message-ID: <CAHYVw0x_cr49gPQH16vkz7AdRCbymYKPqN1bK9zF6ErBZNCs_A@mail.gmail.com>

One really important question is what modes are actually promised by actual
file systems on every posix or otherwise supported platforms .  Table
stakes is code should work well on every tier 1 platform and tier 2 as well

And it’s been pointed out to me that this is part of the Haskell report so
whatever final design is done needs to be excellent

Meta aside : on and off I sometimes wonder what the world would be like if
file systems weren’t stuck in posix minima tar pits (heck an Mvcc with
transactions file system would rock).  But that’s unrelated to improving
the world we have. Do either way this at least starts a discussion about
what we can do better today !

Pardon the slow reply, I think everyone everywhere is having a very strange
start to spring.

Be well and look forward to improving bits and pieces of how we deal with
files on computers ;)

-Carter

On Tue, Mar 31, 2020 at 5:51 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> At least naively, this seems like a really good idea.
>
> 1) do folks who have more experience across the range of supported
> platforms have any opinions about these additional semantics ?
>
> 2) are these names suitably descriptive / unambiguous and or otherwise
> widely used / discoverable ?
>
> On Mon, Mar 30, 2020 at 12:22 PM Grey Mitchell <grey at quietmisdreavus.net>
> wrote:
>
>> The current behavior for System.IO.openFile will either truncate an
>> existing
>> file (with WriteMode) or append new content to the end (with AppendMode).
>> However, there's another behavior that's available from the underlying
>> API:
>> signal an error when the file already exists. I poked around at the code
>> and i
>> think that with a couple extra variants of IOMode, this behavior could be
>> added
>> with a relatively small patch.
>>
>> I have a branch pushed where i added this behavior:
>>
>> https://gitlab.haskell.org/QuietMisdreavus/ghc/-/commit/1ff18d4d3fc63f42c371f4046ab07405299c6755
>>
>> I'm a relative newcomer to contributing to GHC or the base library, so if
>> i'm
>> missing something in my patch please let me know. Specifically, i would
>> like to
>> know is there's a place i can add a test for this behavior. I'm also open
>> to
>> changing the names of the new IOModes - this was just something i wrote
>> in to
>> get something working.
>>
>> Looking forward to working with maintainers to get this added!
>>
>> Thanks,
>> Grey Mitchell (@QuietMisdreavus)
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200331/d379f113/attachment.html>

From grey at quietmisdreavus.net  Tue Mar 31 23:28:43 2020
From: grey at quietmisdreavus.net (Grey Mitchell)
Date: Tue, 31 Mar 2020 17:28:43 -0600
Subject: =?UTF-8?Q?Re:_Adding_new_contructors_to_IOMode_to_support_"don't_overwri?=
 =?UTF-8?Q?te_if_already_exists"_behavior?=
In-Reply-To: <CAHYVw0x_cr49gPQH16vkz7AdRCbymYKPqN1bK9zF6ErBZNCs_A@mail.gmail.com>
References: <038a1a94-74e2-44fe-aff6-3722c98f1295@www.fastmail.com>
 <25b5eeed-22c5-4746-a284-0c492a5c1e1f@www.fastmail.com>
 <CAHYVw0zrmzdSTBqr5J-GBPgw=XHVpqbQth1nV46A8TDO2qkszA@mail.gmail.com>
 <CAHYVw0x_cr49gPQH16vkz7AdRCbymYKPqN1bK9zF6ErBZNCs_A@mail.gmail.com>
Message-ID: <3b770034-b0bb-4ee3-a5b4-bd1c66af6099@www.fastmail.com>

Re: Platform support: I have access to Windows, Linux, and Mac machines, so i can run a quick test if need be. (My current development environment is on a Mac, so i'd need to set up a fresh environment on my Windows and Linux machines.) My assumption is the the EXCL flag being enabled by these modes is part of the basic support for the POSIX open() call - even the MSVC C standard library includes it as part of its emulated open(). It would of course be important to verify this by running the code.

Re: Names: I want to reiterate that the names in my branch were sketches. I did a quick survey of a handful of programming languages just now to see is there was any existing consensus. Rust and .NET call the behavior "create new" in their enumerations. The docs for Python and Ruby call the flag "exclusive create" or "exclusive access", reflecting the name of the underlying C flag. This seems to tell me that my initial suggestion of "no overwrite" doesn't really match up; i'd like to offer another suggestion of WriteCreateNewMode and ReadWriteCreateNewMode.

No worries about the slow reply! I've been there, so it's totally understandable.

-grey

On Tue, Mar 31, 2020, at 4:15 PM, Carter Schonwald wrote:
> One really important question is what modes are actually promised by actual file systems on every posix or otherwise supported platforms . Table stakes is code should work well on every tier 1 platform and tier 2 as well 
> 
> And it’s been pointed out to me that this is part of the Haskell report so whatever final design is done needs to be excellent 
> 
> Meta aside : on and off I sometimes wonder what the world would be like if file systems weren’t stuck in posix minima tar pits (heck an Mvcc with transactions file system would rock). But that’s unrelated to improving the world we have. Do either way this at least starts a discussion about what we can do better today !
> 
> Pardon the slow reply, I think everyone everywhere is having a very strange start to spring. 
> 
> Be well and look forward to improving bits and pieces of how we deal with files on computers ;) 
> 
> -Carter 
> 
> On Tue, Mar 31, 2020 at 5:51 PM Carter Schonwald <carter.schonwald at gmail.com> wrote:
>> At least naively, this seems like a really good idea. 
>> 
>> 1) do folks who have more experience across the range of supported platforms have any opinions about these additional semantics ?
>> 
>> 2) are these names suitably descriptive / unambiguous and or otherwise widely used / discoverable ? 
>> 
>> On Mon, Mar 30, 2020 at 12:22 PM Grey Mitchell <grey at quietmisdreavus.net> wrote:
>>> The current behavior for System.IO.openFile will either truncate an existing
>>>  file (with WriteMode) or append new content to the end (with AppendMode).
>>>  However, there's another behavior that's available from the underlying API:
>>>  signal an error when the file already exists. I poked around at the code and i
>>>  think that with a couple extra variants of IOMode, this behavior could be added
>>>  with a relatively small patch.
>>> 
>>>  I have a branch pushed where i added this behavior:
>>> https://gitlab.haskell.org/QuietMisdreavus/ghc/-/commit/1ff18d4d3fc63f42c371f4046ab07405299c6755
>>> 
>>>  I'm a relative newcomer to contributing to GHC or the base library, so if i'm
>>>  missing something in my patch please let me know. Specifically, i would like to
>>>  know is there's a place i can add a test for this behavior. I'm also open to
>>>  changing the names of the new IOModes - this was just something i wrote in to
>>>  get something working.
>>> 
>>>  Looking forward to working with maintainers to get this added!
>>> 
>>>  Thanks,
>>>  Grey Mitchell (@QuietMisdreavus)
>>>  _______________________________________________
>>>  Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Thanks,
Grey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200331/6cd881da/attachment.html>