From brandon at codedmart.com  Sat Feb  1 00:29:57 2020
From: brandon at codedmart.com (Brandon Martin)
Date: Fri, 31 Jan 2020 16:29:57 -0800
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
Message-ID: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>

I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:

Not in scope: type constructor or class ‘HsType’

Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c

HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.

Thanks

--
Brandon Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200131/dc32107e/attachment.html>

From simon.jakobi at googlemail.com  Sat Feb  1 00:55:19 2020
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Sat, 1 Feb 2020 01:55:19 +0100
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
Message-ID: <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>

Are you using the same dependency set (including GHC version) that you
used on Linux too?

Why did you enable allow-newer?

Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin
<brandon at codedmart.com>:
>
> I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
>
> Not in scope: type constructor or class ‘HsType’
>
> Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
>
> HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.
>
> Thanks
>
> --
> Brandon Martin
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From brandon at codedmart.com  Sat Feb  1 00:58:12 2020
From: brandon at codedmart.com (Brandon Martin)
Date: Fri, 31 Jan 2020 16:58:12 -0800
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
Message-ID: <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>

Yes I am. I put allow newer in both because stack complained about dependencies, and suggested it. I just put it in as a quick test to see if I could build it. Cabal didn't complain about dependencies, but got the same error. 

--
Brandon Martin

On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:
> Are you using the same dependency set (including GHC version) that you
> used on Linux too?
> 
> Why did you enable allow-newer?
> 
> Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin
> <brandon at codedmart.com>:
> >
> > I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
> >
> > Not in scope: type constructor or class ‘HsType’
> >
> > Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
> >
> > HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.
> >
> > Thanks
> >
> > --
> > Brandon Martin
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>

From blaze at ruddy.ru  Sat Feb  1 01:03:56 2020
From: blaze at ruddy.ru (Andrey Sverdlichenko)
Date: Fri, 31 Jan 2020 20:03:56 -0500
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
Message-ID: <CALujEfgLJ=hgjkwZYYgi9-YH_S4T1rLUomXKOW+jcVhRoks+aQ@mail.gmail.com>

What's your ghc version? It looks like you are trying to build a new
package with the older compiler.

On Fri, Jan 31, 2020 at 7:30 PM Brandon Martin <brandon at codedmart.com> wrote:
>
> I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
>
> Not in scope: type constructor or class ‘HsType’
>
> Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
>
> HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.
>
> Thanks
>
> --
> Brandon Martin
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From brandon at codedmart.com  Sat Feb  1 01:08:44 2020
From: brandon at codedmart.com (Brandon Martin)
Date: Fri, 31 Jan 2020 17:08:44 -0800
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <CALujEfgLJ=hgjkwZYYgi9-YH_S4T1rLUomXKOW+jcVhRoks+aQ@mail.gmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CALujEfgLJ=hgjkwZYYgi9-YH_S4T1rLUomXKOW+jcVhRoks+aQ@mail.gmail.com>
Message-ID: <9d7f20e6-6faf-4168-be32-b3658740b8f3@www.fastmail.com>

With stack:

➜  haskell-dbus git:(master) ✗ stack exec ghc -- --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5

System ghc and cabal:

➜  haskell-dbus git:(master) ✗ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5

Same versions on my Linux machine as well.

--
Brandon Martin

On Fri, Jan 31, 2020, at 5:03 PM, Andrey Sverdlichenko wrote:
> What's your ghc version? It looks like you are trying to build a new
> package with the older compiler.
> 
> On Fri, Jan 31, 2020 at 7:30 PM Brandon Martin <brandon at codedmart.com> wrote:
> >
> > I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
> >
> > Not in scope: type constructor or class ‘HsType’
> >
> > Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
> >
> > HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.
> >
> > Thanks
> >
> > --
> > Brandon Martin
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From simon.jakobi at googlemail.com  Sat Feb  1 01:12:37 2020
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Sat, 1 Feb 2020 02:12:37 +0100
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
Message-ID: <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>

I think the error suggests that the C pre-processor doesn't work as
expected. Look at the source around the error locations:

https://github.com/rblaze/haskell-dbus/blob/43b1382ce93f08272fd6fda253d977f604214b2e/lib/DBus/Internal/Types.hs#L452-L481

"HsType" is a variable name used in the CPP definition.

Am Sa., 1. Feb. 2020 um 01:58 Uhr schrieb Brandon Martin
<brandon at codedmart.com>:
>
> Yes I am. I put allow newer in both because stack complained about dependencies, and suggested it. I just put it in as a quick test to see if I could build it. Cabal didn't complain about dependencies, but got the same error.
>
> --
> Brandon Martin
>
> On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:
> > Are you using the same dependency set (including GHC version) that you
> > used on Linux too?
> >
> > Why did you enable allow-newer?
> >
> > Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin
> > <brandon at codedmart.com>:
> > >
> > > I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
> > >
> > > Not in scope: type constructor or class ‘HsType’
> > >
> > > Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
> > >
> > > HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.
> > >
> > > Thanks
> > >
> > > --
> > > Brandon Martin
> > >
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > To (un)subscribe, modify options or view archives go to:
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > Only members subscribed via the mailman list are allowed to post.
> >

From brandon at codedmart.com  Sat Feb  1 01:16:11 2020
From: brandon at codedmart.com (Brandon Martin)
Date: Fri, 31 Jan 2020 17:16:11 -0800
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
Message-ID: <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>

Hmm... maybe I am missing a package in FreeBSD then? Is that the possible suggestion?

--
Brandon Martin

On Fri, Jan 31, 2020, at 5:12 PM, Simon Jakobi wrote:
> I think the error suggests that the C pre-processor doesn't work as
> expected. Look at the source around the error locations:
> 
> https://github.com/rblaze/haskell-dbus/blob/43b1382ce93f08272fd6fda253d977f604214b2e/lib/DBus/Internal/Types.hs#L452-L481
> 
> "HsType" is a variable name used in the CPP definition.
> 
> Am Sa., 1. Feb. 2020 um 01:58 Uhr schrieb Brandon Martin
> <brandon at codedmart.com>:
> >
> > Yes I am. I put allow newer in both because stack complained about dependencies, and suggested it. I just put it in as a quick test to see if I could build it. Cabal didn't complain about dependencies, but got the same error.
> >
> > --
> > Brandon Martin
> >
> > On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:
> > > Are you using the same dependency set (including GHC version) that you
> > > used on Linux too?
> > >
> > > Why did you enable allow-newer?
> > >
> > > Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin
> > > <brandon at codedmart.com>:
> > > >
> > > > I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
> > > >
> > > > Not in scope: type constructor or class ‘HsType’
> > > >
> > > > Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
> > > >
> > > > HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.
> > > >
> > > > Thanks
> > > >
> > > > --
> > > > Brandon Martin
> > > >
> > > > _______________________________________________
> > > > Haskell-Cafe mailing list
> > > > To (un)subscribe, modify options or view archives go to:
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > > Only members subscribed via the mailman list are allowed to post.
> > >
>

From simon.jakobi at googlemail.com  Sat Feb  1 01:30:19 2020
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Sat, 1 Feb 2020 02:30:19 +0100
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
Message-ID: <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>

Maybe. Though it seems to me that the pre-processor isn't missing, but
it's doing the wrong thing…

I'd suggest to open an issue at
https://gitlab.haskell.org/ghc/ghc/issues – there should be people who
can tell more exactly what's going wrong here.

Am Sa., 1. Feb. 2020 um 02:16 Uhr schrieb Brandon Martin
<brandon at codedmart.com>:
>
> Hmm... maybe I am missing a package in FreeBSD then? Is that the possible suggestion?
>
> --
> Brandon Martin
>
> On Fri, Jan 31, 2020, at 5:12 PM, Simon Jakobi wrote:
> > I think the error suggests that the C pre-processor doesn't work as
> > expected. Look at the source around the error locations:
> >
> > https://github.com/rblaze/haskell-dbus/blob/43b1382ce93f08272fd6fda253d977f604214b2e/lib/DBus/Internal/Types.hs#L452-L481
> >
> > "HsType" is a variable name used in the CPP definition.
> >
> > Am Sa., 1. Feb. 2020 um 01:58 Uhr schrieb Brandon Martin
> > <brandon at codedmart.com>:
> > >
> > > Yes I am. I put allow newer in both because stack complained about dependencies, and suggested it. I just put it in as a quick test to see if I could build it. Cabal didn't complain about dependencies, but got the same error.
> > >
> > > --
> > > Brandon Martin
> > >
> > > On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:
> > > > Are you using the same dependency set (including GHC version) that you
> > > > used on Linux too?
> > > >
> > > > Why did you enable allow-newer?
> > > >
> > > > Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin
> > > > <brandon at codedmart.com>:
> > > > >
> > > > > I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
> > > > >
> > > > > Not in scope: type constructor or class ‘HsType’
> > > > >
> > > > > Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
> > > > >
> > > > > HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.
> > > > >
> > > > > Thanks
> > > > >
> > > > > --
> > > > > Brandon Martin
> > > > >
> > > > > _______________________________________________
> > > > > Haskell-Cafe mailing list
> > > > > To (un)subscribe, modify options or view archives go to:
> > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > > > Only members subscribed via the mailman list are allowed to post.
> > > >
> >

From carter.schonwald at gmail.com  Sat Feb  1 04:19:54 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 31 Jan 2020 23:19:54 -0500
Subject: [Haskell-cafe] Ann: vector 0.12.1.1 release!
Message-ID: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>

https://hackage.haskell.org/package/vector-0.12.1.1

it has A LOT of bug fixes, a few little improvements, enjoy!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200131/bec244f8/attachment.html>

From a.pelenitsyn at gmail.com  Sat Feb  1 04:23:54 2020
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Fri, 31 Jan 2020 23:23:54 -0500
Subject: [Haskell-cafe] Ann: vector 0.12.1.1 release!
In-Reply-To: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>
References: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>
Message-ID: <CAPKAvQUUCKN9CoBYgWdaacEZruDuaZB39-erq=b+DVSH=VFrwQ@mail.gmail.com>

Hey Carter,

Thanks a lot for your work!

Is it possible to fix the documentation of Hackage:
https://hackage.haskell.org/package/vector-0.12.1.1/docs/Data-Vector-Unboxed.html
gives "Not Found" as it does for 0.12.1.0, while it works well for previous
releases.

--
Best Regards,
Artem


On Fri, 31 Jan 2020 at 23:20, Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> https://hackage.haskell.org/package/vector-0.12.1.1
>
> it has A LOT of bug fixes, a few little improvements, enjoy!
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200131/ccb7f547/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  1 04:53:18 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 31 Jan 2020 23:53:18 -0500
Subject: [Haskell-cafe] Ann: vector 0.12.1.1 release!
In-Reply-To: <CAPKAvQUUCKN9CoBYgWdaacEZruDuaZB39-erq=b+DVSH=VFrwQ@mail.gmail.com>
References: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>
 <CAPKAvQUUCKN9CoBYgWdaacEZruDuaZB39-erq=b+DVSH=VFrwQ@mail.gmail.com>
Message-ID: <CAHYVw0wAXJAztLCZ-MCgudDYO8fdKbqEVuiM1uOhk+s2cBgKSA@mail.gmail.com>

it was a few great contributors in the mix

i put an unbuildable constraint on 0.12.1.0 after i realized that the deps
spec for the test suite was incorrect for older ghc versions,

if the doc builder doesn't fire up in the next few hours i'll do my own
upload of the docs, but the doc builder should be fine :)

On Fri, Jan 31, 2020 at 11:24 PM Artem Pelenitsyn <a.pelenitsyn at gmail.com>
wrote:

> Hey Carter,
>
> Thanks a lot for your work!
>
> Is it possible to fix the documentation of Hackage:
>
> https://hackage.haskell.org/package/vector-0.12.1.1/docs/Data-Vector-Unboxed.html
> gives "Not Found" as it does for 0.12.1.0, while it works well for
> previous releases.
>
> --
> Best Regards,
> Artem
>
>
> On Fri, 31 Jan 2020 at 23:20, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> https://hackage.haskell.org/package/vector-0.12.1.1
>>
>> it has A LOT of bug fixes, a few little improvements, enjoy!
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200131/fd88a146/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  1 04:54:18 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 31 Jan 2020 23:54:18 -0500
Subject: [Haskell-cafe] Ann: vector 0.12.1.1 release!
In-Reply-To: <CAHYVw0wAXJAztLCZ-MCgudDYO8fdKbqEVuiM1uOhk+s2cBgKSA@mail.gmail.com>
References: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>
 <CAPKAvQUUCKN9CoBYgWdaacEZruDuaZB39-erq=b+DVSH=VFrwQ@mail.gmail.com>
 <CAHYVw0wAXJAztLCZ-MCgudDYO8fdKbqEVuiM1uOhk+s2cBgKSA@mail.gmail.com>
Message-ID: <CAHYVw0w-Gyqzos3r+FSoZKhwgrEZWk-1mVuZi5mb-OuQLiuivA@mail.gmail.com>

*and to be clear: some of the bug fixes  and bugs were only discovered in
the past two weeks in the course of preparing this release, and I would
like to genuinely thank all the folks who helped out. (see the change log
for 1-2 of the great ones :) )

On Fri, Jan 31, 2020 at 11:53 PM Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> it was a few great contributors in the mix
>
> i put an unbuildable constraint on 0.12.1.0 after i realized that the deps
> spec for the test suite was incorrect for older ghc versions,
>
> if the doc builder doesn't fire up in the next few hours i'll do my own
> upload of the docs, but the doc builder should be fine :)
>
> On Fri, Jan 31, 2020 at 11:24 PM Artem Pelenitsyn <a.pelenitsyn at gmail.com>
> wrote:
>
>> Hey Carter,
>>
>> Thanks a lot for your work!
>>
>> Is it possible to fix the documentation of Hackage:
>>
>> https://hackage.haskell.org/package/vector-0.12.1.1/docs/Data-Vector-Unboxed.html
>> gives "Not Found" as it does for 0.12.1.0, while it works well for
>> previous releases.
>>
>> --
>> Best Regards,
>> Artem
>>
>>
>> On Fri, 31 Jan 2020 at 23:20, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> https://hackage.haskell.org/package/vector-0.12.1.1
>>>
>>> it has A LOT of bug fixes, a few little improvements, enjoy!
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200131/94aa75c8/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  1 04:54:50 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 31 Jan 2020 23:54:50 -0500
Subject: [Haskell-cafe] Ann: vector 0.12.1.1 release!
In-Reply-To: <CAHYVw0w-Gyqzos3r+FSoZKhwgrEZWk-1mVuZi5mb-OuQLiuivA@mail.gmail.com>
References: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>
 <CAPKAvQUUCKN9CoBYgWdaacEZruDuaZB39-erq=b+DVSH=VFrwQ@mail.gmail.com>
 <CAHYVw0wAXJAztLCZ-MCgudDYO8fdKbqEVuiM1uOhk+s2cBgKSA@mail.gmail.com>
 <CAHYVw0w-Gyqzos3r+FSoZKhwgrEZWk-1mVuZi5mb-OuQLiuivA@mail.gmail.com>
Message-ID: <CAHYVw0z++=UZSr=-s=2JF34TEhf+ZPoXwOXgNQumcxJOe9JHmg@mail.gmail.com>

also looks like the docbuilder did its job just as I replied :)

On Fri, Jan 31, 2020 at 11:54 PM Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> *and to be clear: some of the bug fixes  and bugs were only discovered in
> the past two weeks in the course of preparing this release, and I would
> like to genuinely thank all the folks who helped out. (see the change log
> for 1-2 of the great ones :) )
>
> On Fri, Jan 31, 2020 at 11:53 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> it was a few great contributors in the mix
>>
>> i put an unbuildable constraint on 0.12.1.0 after i realized that the
>> deps spec for the test suite was incorrect for older ghc versions,
>>
>> if the doc builder doesn't fire up in the next few hours i'll do my own
>> upload of the docs, but the doc builder should be fine :)
>>
>> On Fri, Jan 31, 2020 at 11:24 PM Artem Pelenitsyn <a.pelenitsyn at gmail.com>
>> wrote:
>>
>>> Hey Carter,
>>>
>>> Thanks a lot for your work!
>>>
>>> Is it possible to fix the documentation of Hackage:
>>>
>>> https://hackage.haskell.org/package/vector-0.12.1.1/docs/Data-Vector-Unboxed.html
>>> gives "Not Found" as it does for 0.12.1.0, while it works well for
>>> previous releases.
>>>
>>> --
>>> Best Regards,
>>> Artem
>>>
>>>
>>> On Fri, 31 Jan 2020 at 23:20, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> https://hackage.haskell.org/package/vector-0.12.1.1
>>>>
>>>> it has A LOT of bug fixes, a few little improvements, enjoy!
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200131/d7a08568/attachment.html>

From arrowd at freebsd.org  Sat Feb  1 07:57:10 2020
From: arrowd at freebsd.org (Gleb Popov)
Date: Sat, 1 Feb 2020 11:57:10 +0400
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
Message-ID: <CALH631nEYYv5r1-v-mN_Xj=PvsyPvetoNx2iXRSU9r-BYdFZ1Q@mail.gmail.com>

On Sat, Feb 1, 2020 at 5:31 AM Simon Jakobi via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Maybe. Though it seems to me that the pre-processor isn't missing, but
> it's doing the wrong thing…
>
> I'd suggest to open an issue at
> https://gitlab.haskell.org/ghc/ghc/issues – there should be people who
> can tell more exactly what's going wrong here.
>

FreeBSD uses Clang as C/C++ compiler. While its preprocessor should be 100%
compatible with GCC's one, it might explain why the problem appears.


> Am Sa., 1. Feb. 2020 um 02:16 Uhr schrieb Brandon Martin
> <brandon at codedmart.com>:
> >
> > Hmm... maybe I am missing a package in FreeBSD then? Is that the
> possible suggestion?
> >
> > --
> > Brandon Martin
> >
> > On Fri, Jan 31, 2020, at 5:12 PM, Simon Jakobi wrote:
> > > I think the error suggests that the C pre-processor doesn't work as
> > > expected. Look at the source around the error locations:
> > >
> > >
> https://github.com/rblaze/haskell-dbus/blob/43b1382ce93f08272fd6fda253d977f604214b2e/lib/DBus/Internal/Types.hs#L452-L481
> > >
> > > "HsType" is a variable name used in the CPP definition.
> > >
> > > Am Sa., 1. Feb. 2020 um 01:58 Uhr schrieb Brandon Martin
> > > <brandon at codedmart.com>:
> > > >
> > > > Yes I am. I put allow newer in both because stack complained about
> dependencies, and suggested it. I just put it in as a quick test to see if
> I could build it. Cabal didn't complain about dependencies, but got the
> same error.
> > > >
> > > > --
> > > > Brandon Martin
> > > >
> > > > On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:
> > > > > Are you using the same dependency set (including GHC version) that
> you
> > > > > used on Linux too?
> > > > >
> > > > > Why did you enable allow-newer?
> > > > >
> > > > > Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin
> > > > > <brandon at codedmart.com>:
> > > > > >
> > > > > > I am trying to build haskell-dbus on FreeBSD 12.1. I have tried
> with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
> > > > > >
> > > > > > Not in scope: type constructor or class ‘HsType’
> > > > > >
> > > > > > Full error:
> https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
> > > > > >
> > > > > > HsType is part of ghc unless I am missing something. I am new to
> using FreeBSD as I usually use Linux. This package builds fine for me on
> Linux.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > --
> > > > > > Brandon Martin
> > > > > >
> > > > > > _______________________________________________
> > > > > > Haskell-Cafe mailing list
> > > > > > To (un)subscribe, modify options or view archives go to:
> > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > > > > Only members subscribed via the mailman list are allowed to post.
> > > > >
> > >
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/48493d1b/attachment.html>

From zemyla at gmail.com  Sat Feb  1 08:09:35 2020
From: zemyla at gmail.com (Zemyla)
Date: Sat, 1 Feb 2020 02:09:35 -0600
Subject: [Haskell-cafe] Ann: vector 0.12.1.1 release!
In-Reply-To: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>
References: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>
Message-ID: <CAK7nUjhOEPhqRg0G+vD9SBx7MtZ_A4BiyJRj3bR=uPJeT5Y6ZA@mail.gmail.com>

Is there a changelog?

On Fri, Jan 31, 2020, 22:20 Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> https://hackage.haskell.org/package/vector-0.12.1.1
>
> it has A LOT of bug fixes, a few little improvements, enjoy!
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/ab09fb6c/attachment.html>

From arrowd at freebsd.org  Sat Feb  1 08:26:32 2020
From: arrowd at freebsd.org (Gleb Popov)
Date: Sat, 1 Feb 2020 12:26:32 +0400
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
Message-ID: <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>

On Sat, Feb 1, 2020 at 5:31 AM Simon Jakobi via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Maybe. Though it seems to me that the pre-processor isn't missing, but
> it's doing the wrong thing…
>
> I'd suggest to open an issue at
> https://gitlab.haskell.org/ghc/ghc/issues – there should be people who
> can tell more exactly what's going wrong here.
>

Yep, the problem is with Clang's preprocessor. Running it manually results
in a bunch of

    warning: missing terminating ' character [-Winvalid-pp-token]

messages.

Stumbling upon a ' character makes cpp stop preprocessing current macro.
This is the case for IsValue instance, which contain typeOf' method.

Not sure if this should be reported to the package developer, GHC devs or
Clang devs.


> Am Sa., 1. Feb. 2020 um 02:16 Uhr schrieb Brandon Martin
> <brandon at codedmart.com>:
> >
> > Hmm... maybe I am missing a package in FreeBSD then? Is that the
> possible suggestion?
> >
> > --
> > Brandon Martin
> >
> > On Fri, Jan 31, 2020, at 5:12 PM, Simon Jakobi wrote:
> > > I think the error suggests that the C pre-processor doesn't work as
> > > expected. Look at the source around the error locations:
> > >
> > >
> https://github.com/rblaze/haskell-dbus/blob/43b1382ce93f08272fd6fda253d977f604214b2e/lib/DBus/Internal/Types.hs#L452-L481
> > >
> > > "HsType" is a variable name used in the CPP definition.
> > >
> > > Am Sa., 1. Feb. 2020 um 01:58 Uhr schrieb Brandon Martin
> > > <brandon at codedmart.com>:
> > > >
> > > > Yes I am. I put allow newer in both because stack complained about
> dependencies, and suggested it. I just put it in as a quick test to see if
> I could build it. Cabal didn't complain about dependencies, but got the
> same error.
> > > >
> > > > --
> > > > Brandon Martin
> > > >
> > > > On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:
> > > > > Are you using the same dependency set (including GHC version) that
> you
> > > > > used on Linux too?
> > > > >
> > > > > Why did you enable allow-newer?
> > > > >
> > > > > Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin
> > > > > <brandon at codedmart.com>:
> > > > > >
> > > > > > I am trying to build haskell-dbus on FreeBSD 12.1. I have tried
> with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:
> > > > > >
> > > > > > Not in scope: type constructor or class ‘HsType’
> > > > > >
> > > > > > Full error:
> https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c
> > > > > >
> > > > > > HsType is part of ghc unless I am missing something. I am new to
> using FreeBSD as I usually use Linux. This package builds fine for me on
> Linux.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > --
> > > > > > Brandon Martin
> > > > > >
> > > > > > _______________________________________________
> > > > > > Haskell-Cafe mailing list
> > > > > > To (un)subscribe, modify options or view archives go to:
> > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > > > > Only members subscribed via the mailman list are allowed to post.
> > > > >
> > >
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/3d8a1927/attachment-0001.html>

From ietf-dane at dukhovni.org  Sat Feb  1 09:01:26 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 1 Feb 2020 04:01:26 -0500
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
 <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>
Message-ID: <20200201090126.GF49778@straasha.imrryr.org>

On Sat, Feb 01, 2020 at 12:26:32PM +0400, Gleb Popov wrote:

> Yep, the problem is with Clang's preprocessor. Running it manually results
> in a bunch of
> 
>     warning: missing terminating ' character [-Winvalid-pp-token]
> 
> messages.

I don't think it is just clang, the macros are not not valid
C-preprocessor input.

    $ for cpp in gcc{7,8,8} clang{37,39,60,70}; do
        printf "--- CPP: %s\n" "$cpp"
        printf "#define foo a' = b\nfoo\n" |
            $cpp -Werror -E - 2>&1
        printf "EXIT: $?\n"
      done | egrep -v '^# [0-9]|^$'
    --- CPP: gcc7
    <stdin>:1:14: error: missing terminating ' character [-Werror]
    a' = b
    cc1: all warnings being treated as errors
    EXIT: 1
    --- CPP: gcc8
    <stdin>:1:14: error: missing terminating ' character [-Werror]
    a' = b
    cc1: all warnings being treated as errors
    EXIT: 1
    --- CPP: gcc8
    <stdin>:1:14: error: missing terminating ' character [-Werror]
    a' = b
    cc1: all warnings being treated as errors
    EXIT: 1
    --- CPP: clang37
    <stdin>:1:14: error: missing terminating ' character
    [-Werror,-Winvalid-pp-token]
    #define foo a' = b
                 ^
    a' = b
    1 error generated.
    EXIT: 1
    --- CPP: clang39
    <stdin>:1:14: error: missing terminating ' character
    [-Werror,-Winvalid-pp-token]
    #define foo a' = b
                 ^
    a' = b
    1 error generated.
    EXIT: 1
    --- CPP: clang60
    <stdin>:1:14: error: missing terminating ' character
    [-Werror,-Winvalid-pp-token]
    #define foo a' = b
                 ^
    a' = b
    1 error generated.
    EXIT: 1
    --- CPP: clang70
    <stdin>:1:14: error: missing terminating ' character
    [-Werror,-Winvalid-pp-token]
    #define foo a' = b
                 ^
    a' = b
    1 error generated.
    EXIT: 1

> This is the case for IsValue instance, which contain typeOf' method.
> 
> Not sure if this should be reported to the package developer, GHC devs or
> Clang devs.

The package developer.  Neither GHC nor Clang are at-fault for invalid
CPP macro syntax.

-- 
    Viktor.

From merijn at inconsistent.nl  Sat Feb  1 10:36:19 2020
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Sat, 1 Feb 2020 11:36:19 +0100
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <20200201090126.GF49778@straasha.imrryr.org>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
 <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>
 <20200201090126.GF49778@straasha.imrryr.org>
Message-ID: <1AB359CC-88D7-46A1-9BAC-4A7C996D421C@inconsistent.nl>


> On 1 Feb 2020, at 10:01, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> The package developer.  Neither GHC nor Clang are at-fault for invalid
> CPP macro syntax.

This isn't the package developers fault. Standard Haskell just cannot be properly preprocessed by an ISO C preprocessor. As the definition of valid tokens just aren't compatible.

GHC's use of the CPP has long (maybe since forever?) been incompatible with CPP as standardised in the ISO C spec, and its relies on the -traditional flag to make GCC use it's pre-ISO C implementations. This flag isn't necessarily portable across C compilers and I recall this breaking things in the past.

cpphs should work as a workaround alternative C preprocessor if your C compiler doesn't support the "right" wrong CPP configuration.

Cheers,
Merijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/ab3c38af/attachment.sig>

From ietf-dane at dukhovni.org  Sat Feb  1 10:56:06 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 1 Feb 2020 05:56:06 -0500
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <1AB359CC-88D7-46A1-9BAC-4A7C996D421C@inconsistent.nl>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
 <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>
 <20200201090126.GF49778@straasha.imrryr.org>
 <1AB359CC-88D7-46A1-9BAC-4A7C996D421C@inconsistent.nl>
Message-ID: <20200201105606.GG49778@straasha.imrryr.org>

On Sat, Feb 01, 2020 at 11:36:19AM +0100, Merijn Verstraaten wrote:

> > On 1 Feb 2020, at 10:01, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> > 
> > The package developer.  Neither GHC nor Clang are at-fault for invalid
> > CPP macro syntax.
> 
> This isn't the package developers fault. Standard Haskell just cannot
> be properly preprocessed by an ISO C preprocessor. As the definition
> of valid tokens just aren't compatible.

Well, my take was the package developer using "CPP" is expected to
produce CPP-compatible input.  But if Haskell is expected to provide a
more liberal dialect of CPP, then indeed perhaps the issue is with the
Haskell build using Clang's CPP.

> GHC's use of the CPP has long (maybe since forever?) been incompatible
> with CPP as standardised in the ISO C spec, and its relies on the
> -traditional flag to make GCC use it's pre-ISO C implementations. This
> flag isn't necessarily portable across C compilers and I recall this
> breaking things in the past.

Indeed the -traditional flag shows the difference, only GCC's "cpp"
tolerates the C-incompatible tokens, Clang does not.

    $ for cpp in gcc{7,8,9} clang{37,39,60,70}; do printf "--- CPP: %s\n" "$cpp"; printf "#define foo a' = b\nfoo\n" | $cpp -traditional -Werror -E - 2>&1; printf "EXIT: $?\n"; done | egrep -v '^# [0-9]|^$'
    --- CPP: gcc7
    a' = b
    EXIT: 0
    --- CPP: gcc8
    a' = b
    EXIT: 0
    --- CPP: gcc9
    a' = b
    EXIT: 0
    --- CPP: clang37
    <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token]
    #define foo a' = b
                 ^
    a' = b
    1 error generated.
    EXIT: 1
    --- CPP: clang39
    <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token]
    #define foo a' = b
                 ^
    a' = b
    1 error generated.
    EXIT: 1
    --- CPP: clang60
    <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token]
    #define foo a' = b
                 ^
    a' = b
    1 error generated.
    EXIT: 1
    --- CPP: clang70
    <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token]
    #define foo a' = b
                 ^
    a' = b
    1 error generated.
    EXIT: 1

My own build of GHC for FreeBSD has settings:

    [("GCC extra via C opts", " -fwrapv -fno-builtin"),
     ("C compiler command", "gcc"),
     ("C compiler flags", ""),
     ("C compiler link flags", " -fuse-ld=lld"),
     ("C compiler supports -no-pie", "YES"),
     ("Haskell CPP command","gcc"),
     ("Haskell CPP flags","-E -undef -traditional"),
     ...
    ]

It seems that the ports system elects clang, leading to the reported
issue.  I see that FreeBSD ports also include:

    hs-cpphs-1.20.8_7   Liberalised re-implementation of cpp, the C pre-processor

Which means that either hs-cpphs needs to be a pre-requisite (built by
the boostrap GHC compiler?), a co-requisite (assuming GHC itself does
not break with clang's CPP), or the configuration needs be tweaked to
use "gcc" as the Haskell CPP preprocessor, even when clang is the
compiler.

-- 
    Viktor.

From konn.jinro at gmail.com  Sat Feb  1 11:59:05 2020
From: konn.jinro at gmail.com (=?utf-8?B?55+z5LqV5aSn5rW3?=)
Date: Sat, 1 Feb 2020 20:59:05 +0900
Subject: [Haskell-cafe] Looking-up a TyCon of a type exposed from public
 module but defined in hidden module
Message-ID: <E0F71474-49D1-4C68-B50B-4E1069925056@gmail.com>

Hi cafe,

I'm currently writing GHC Type-Checker Plugin [ghc-typelits-presburger], which enhances type-inference involving type-level naturals using Presburger arithmetic.

To process constraints properly, I need an access to TyCons of `TrueSym0`,
`FalseSym0`, `GTSym0`, etc. from `singletons` package.
These types are exposed by public modules, e.g. Data.Singletons.Prelude, but
it seems that they are originally defined in private module `Data.Singletons.Prelude.Instances`.

I first tried, to retrieve the `TyCon` for `TrueSym0`, the following:

```
  insts <- lookupModule (mkModuleName "Data.Singletons.Prelude.Instances") (fsLit "singletons")
  singTrueSym0 <- tcLookupTyCon =<< lookupOrig insts (mkTcOcc "TrueSym0")
```

But this results in the following compile-time error:

```
ghc: panic! (the 'impossible' happened)
  (GHC version 8.6.5 for x86_64-apple-darwin):
       Unable to resolve module looked up by plugin:
  Data.Singletons.Prelude.Instances

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
```

Then, I tried to lookup `TrueSym0` from exposed module, say Data.Singletons.Prelude:

```
  prel <- lookupModule (mkModuleName "Data.Singletons.Prelude") (fsLit "singletons")
  singTrueSym0 <- tcLookupTyCon =<< lookupOrig prel (mkTcOcc "TrueSym0")
```

But this resulted in the following error:

```
• Can't find interface-file declaration for type constructor or class singletons-2.5.1:Data.Singletons.Prelude.TrueSym0
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error
• In the type signature: ...
```

Is there any way, in GHC API, to lookup symbols exported from public module but originally defined in hidden module?

Thanks,

[ghc-typelits-presburger]: https://github.com/konn/ghc-typelits-presburger

-- Hiromi ISHII
konn.jinro at gmail.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/8dd83c07/attachment.sig>

From carter.schonwald at gmail.com  Sat Feb  1 13:34:25 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2020 08:34:25 -0500
Subject: [Haskell-cafe] Ann: vector 0.12.1.1 release!
In-Reply-To: <CAK7nUjhOEPhqRg0G+vD9SBx7MtZ_A4BiyJRj3bR=uPJeT5Y6ZA@mail.gmail.com>
References: <CAHYVw0zKk9PSiiXV_MmXxwAw3sLkX5X8Wsxo2dFJ+8z4bVA0kg@mail.gmail.com>
 <CAK7nUjhOEPhqRg0G+vD9SBx7MtZ_A4BiyJRj3bR=uPJeT5Y6ZA@mail.gmail.com>
Message-ID: <CAHYVw0x0dKPsXE0Q3poYaDf3svBT7GctytAgZnj0WeW_jn4D6A@mail.gmail.com>

Yup !

For those who prefer email over urls

Changes in version 0.12.1.1

   - add semigrioups dep to test suite so CI actually runs again on GHC < 8

Changes in version 0.12.1.0

   - Fix integer overflows in specializations of Bundle/Stream enumFromTo
   on Integral types
   - Fix possibility of OutOfMemory with take and very large arguments.
   - Fix slice function causing segfault and not checking the bounds
   properly.
   - updated specialization rule for EnumFromTo on Float and Double to make
   sure it always matches the version in GHC Base (which changed as of 8.6)
   Thanks to Aleksey Khudyakov @Shimuuar for this fix.
   - fast rejection short circuiting in eqBy operations
   - the O2 test suite now has reasonable memory usage on every GHC
   version, special thanks to Alexey Kuleshevich (@lehins).
   - The Mutable type family is now injective on GHC 8.0 or later.
   - Using empty Storable vectors no longer results in division-by-zero
   errors.
   - The Data instances for Vectortypes now have well defined
   implementations for toConstr, gunfold, and dataTypeOf.
   - New function: partitionWith.
   - Add Unbox instances for Identity, Const, Down, Dual, Sum, Product, Min
   , Max, First, Last, WrappedMonoid, Arg, Any, All, Alt, and Compose.
   - Add NFData1 instances for applicable Vector types
   -

On Sat, Feb 1, 2020 at 3:09 AM Zemyla <zemyla at gmail.com> wrote:

> Is there a changelog?
>
> On Fri, Jan 31, 2020, 22:20 Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> https://hackage.haskell.org/package/vector-0.12.1.1
>>
>> it has A LOT of bug fixes, a few little improvements, enjoy!
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/16f68d93/attachment.html>

From ben.franksen at online.de  Sat Feb  1 14:44:20 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Sat, 1 Feb 2020 15:44:20 +0100
Subject: [Haskell-cafe] Haskell positions available at Luminous
	Computing.
In-Reply-To: <44E5E9D0-8A26-4CA9-8A93-643FB3B3E76A@gmail.com>
References: <44E5E9D0-8A26-4CA9-8A93-643FB3B3E76A@gmail.com>
Message-ID: <r142s4$2icn$1@ciao.gmane.io>

Am 31.01.20 um 01:19 schrieb David Banas:
> https://www.luminouscomputing.com/

Quoting from that page:

"""
AI should be deployed to every product we interact with on a daily basis.
"""

Am I the only one how is horrified when they read something like this?

Greetings
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 4211 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/205080d9/attachment.key>

From ben.franksen at online.de  Sat Feb  1 15:18:52 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Sat, 1 Feb 2020 16:18:52 +0100
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <1AB359CC-88D7-46A1-9BAC-4A7C996D421C@inconsistent.nl>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
 <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>
 <20200201090126.GF49778@straasha.imrryr.org>
 <1AB359CC-88D7-46A1-9BAC-4A7C996D421C@inconsistent.nl>
Message-ID: <r144ss$vnj$1@ciao.gmane.io>

Am 01.02.20 um 11:36 schrieb Merijn Verstraaten:
> 
>> On 1 Feb 2020, at 10:01, Viktor Dukhovni <ietf-dane at dukhovni.org>
>> wrote:
>> 
>> The package developer.  Neither GHC nor Clang are at-fault for
>> invalid CPP macro syntax.
> 
> This isn't the package developers fault. Standard Haskell just cannot
> be properly preprocessed by an ISO C preprocessor. As the definition
> of valid tokens just aren't compatible.
> 
> GHC's use of the CPP has long (maybe since forever?) been
> incompatible with CPP as standardised in the ISO C spec, and its
> relies on the -traditional flag to make GCC use it's pre-ISO C
> implementations. This flag isn't necessarily portable across C
> compilers and I recall this breaking things in the past.

This situation strikes me as being precarious. It means we rely on the
gcc developers to retain the -traditional flag (with its current
semantics). My personal experience makes me think that such reliance is
ill-advised: breaking compatibility with anything other than C or C++
source code is not regarded as a problem and bug reports to that effect
are rejected as invalid.

Cheers
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 4211 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/6ca7f29a/attachment.key>

From allbery.b at gmail.com  Sat Feb  1 15:30:21 2020
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 1 Feb 2020 10:30:21 -0500
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <r144ss$vnj$1@ciao.gmane.io>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
 <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>
 <20200201090126.GF49778@straasha.imrryr.org>
 <1AB359CC-88D7-46A1-9BAC-4A7C996D421C@inconsistent.nl>
 <r144ss$vnj$1@ciao.gmane.io>
Message-ID: <CAKFCL4V0YD9-YqW-BnLzjPhb4Ko-Q5mgkQzr4_fkKUH9xL7UwA@mail.gmail.com>

I've been complaining about that for years. Every so often there's
discussion of a non-GPLed alternative preprocessor, but the questions
apparently become fairly hairy quickly, so the current mess is just
accepted. :(

On Sat, Feb 1, 2020 at 10:19 AM Ben Franksen <ben.franksen at online.de> wrote:

> Am 01.02.20 um 11:36 schrieb Merijn Verstraaten:
> >
> >> On 1 Feb 2020, at 10:01, Viktor Dukhovni <ietf-dane at dukhovni.org>
> >> wrote:
> >>
> >> The package developer.  Neither GHC nor Clang are at-fault for
> >> invalid CPP macro syntax.
> >
> > This isn't the package developers fault. Standard Haskell just cannot
> > be properly preprocessed by an ISO C preprocessor. As the definition
> > of valid tokens just aren't compatible.
> >
> > GHC's use of the CPP has long (maybe since forever?) been
> > incompatible with CPP as standardised in the ISO C spec, and its
> > relies on the -traditional flag to make GCC use it's pre-ISO C
> > implementations. This flag isn't necessarily portable across C
> > compilers and I recall this breaking things in the past.
>
> This situation strikes me as being precarious. It means we rely on the
> gcc developers to retain the -traditional flag (with its current
> semantics). My personal experience makes me think that such reliance is
> ill-advised: breaking compatibility with anything other than C or C++
> source code is not regarded as a problem and bug reports to that effect
> are rejected as invalid.
>
> Cheers
> Ben
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/aefeb992/attachment.html>

From alan.zimm at gmail.com  Sat Feb  1 16:39:54 2020
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sat, 1 Feb 2020 16:39:54 +0000
Subject: [Haskell-cafe] Haskell Language Server admin
Message-ID: <CANma=H8-=5_bwxRm82mHzdCR8DySR=N=zPR7B2sGqa3EMRsEmA@mail.gmail.com>

For those of you who are not yet aware of it, the teams involved in
haskell-ide-engine and ghcide got together last weekend in Bristol[1], and
decided to join efforts, and to coordinate this in a new project, which we
provisionally called 'ide', assuming it would always be in a haskell
context.

It turns out this was not such a wise decision, and after a very quick,
very unscientific poll on github, publicized on twitter only, we have
decided to instead call the project something meaningful, and will be
renaming it to 'haskell-language-server' instead, which makes it clear what
the project actually is.

The informal poll can be seen at [2]

Alan

[1]
https://neilmitchell.blogspot.com/2020/01/one-haskell-ide-to-rule-them-all.html
[2] https://github.com/haskell/ide/issues/29#issuecomment-580747082
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/35835594/attachment.html>

From ghosh.debasish at gmail.com  Sat Feb  1 18:54:26 2020
From: ghosh.debasish at gmail.com (Debasish Ghosh)
Date: Sun, 2 Feb 2020 00:24:26 +0530
Subject: [Haskell-cafe] Seeking help to generalize this ..
Message-ID: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>

Hi -

How can I generalize the following pattern to an arbitrary list of
functions ?

compose :: (Monad m) => (Foo -> m Foo) -> (Foo -> m Foo) -> (Foo -> m Foo)
-> Foo -> m Foo
compose f1 f2 f3 acc = do
  a <- f1 acc
  b <- f2 a
  f3 b

Any help please ..
regards.

-- 
Debasish Ghosh
http://manning.com/ghosh2
http://manning.com/ghosh

Twttr: @debasishg
Blog: http://debasishg.blogspot.com
Code: http://github.com/debasishg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200202/2a0561ae/attachment.html>

From lysxia at gmail.com  Sat Feb  1 18:58:41 2020
From: lysxia at gmail.com (Li-yao Xia)
Date: Sat, 1 Feb 2020 13:58:41 -0500
Subject: [Haskell-cafe] Seeking help to generalize this ..
In-Reply-To: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
References: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
Message-ID: <a42f2ef8-abd6-a62d-9b95-a3d41ebbfa71@gmail.com>

Hi Debasish,

You can also write


    (f1 >=> f2 >=> f3) acc

or

    f1 acc >>= f2 >>= f3

or

    foldr (>=>) [f1, f2, f3] pure acc


Regards,
Li-yao

On 2/1/20 1:54 PM, Debasish Ghosh wrote:
> Hi -
> 
> How can I generalize the following pattern to an arbitrary list of 
> functions ?
> 
> compose :: (Monad m) => (Foo -> m Foo) -> (Foo -> m Foo) -> (Foo -> m 
> Foo) -> Foo -> m Foo
> compose f1 f2 f3 acc = do
>    a <- f1 acc
>    b <- f2 a
>    f3 b
> 
> Any help please ..
> regards.
> 
> -- 
> Debasish Ghosh
> http://manning.com/ghosh2
> http://manning.com/ghosh
> 
> Twttr: @debasishg
> Blog: http://debasishg.blogspot.com
> Code: http://github.com/debasishg
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
> 

From paston.cooper at gmail.com  Sat Feb  1 19:04:00 2020
From: paston.cooper at gmail.com (Justin Paston-Cooper)
Date: Sat, 1 Feb 2020 20:04:00 +0100
Subject: [Haskell-cafe] Seeking help to generalize this ..
In-Reply-To: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
References: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
Message-ID: <CAEndGgTurC1a_sx7015qEgyg9VR+i7Q6jv3jw7dfe3=iDMu9hQ@mail.gmail.com>

Hello,

I suggest taking a quick look at the function ‘fold’ in Data.Foldable, and
also Data.Functor.Compose. That should be good start for composing any list
of such functions.

Cheers,

J.

On Sat, 1 Feb 2020 at 19:55, Debasish Ghosh <ghosh.debasish at gmail.com>
wrote:

> Hi -
>
> How can I generalize the following pattern to an arbitrary list of
> functions ?
>
> compose :: (Monad m) => (Foo -> m Foo) -> (Foo -> m Foo) -> (Foo -> m Foo)
> -> Foo -> m Foo
> compose f1 f2 f3 acc = do
>   a <- f1 acc
>   b <- f2 a
>   f3 b
>
> Any help please ..
> regards.
>
> --
> Debasish Ghosh
> http://manning.com/ghosh2
> http://manning.com/ghosh
>
> Twttr: @debasishg
> Blog: http://debasishg.blogspot.com
> Code: http://github.com/debasishg
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/aacad132/attachment.html>

From jack at jackkelly.name  Sat Feb  1 22:05:49 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Sun, 02 Feb 2020 08:05:49 +1000
Subject: [Haskell-cafe] Seeking help to generalize this ..
In-Reply-To: <CAEndGgTurC1a_sx7015qEgyg9VR+i7Q6jv3jw7dfe3=iDMu9hQ@mail.gmail.com>
 (Justin Paston-Cooper's message of "Sat, 1 Feb 2020 20:04:00 +0100")
References: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
 <CAEndGgTurC1a_sx7015qEgyg9VR+i7Q6jv3jw7dfe3=iDMu9hQ@mail.gmail.com>
Message-ID: <87blqi3qv6.fsf@jackkelly.name>

Related:

In Data.Monoid there is the 'Endo' newtype, which wraps functions of
type 'a -> a'. Is there an 'EndoM' variant, or is that something that's
usually created by putting other pieces together? Below is a sketch of
what I mean:

-- Maybe this is known by another name?
newtype EndoM f a = EndoM { appEndoM :: a -> f a }

-- Bind typeclass is from package semigroupoids.
-- It means "Monad sans 'return'".
-- Maybe use Monad f => here instead if getting the Bind instances is
-- too annoying? (e.g., Writing orphan instances).
instance Bind f => Semigroup (EndoM f a) where
  EndoM f <> EndoM g = EndoM $ f ->- g

-- Bind is not a superclass of Monad, so we get this awkward set of
-- required constraints here.
instance (Bind f, Monad f) => Monoid (EndoM f a) where
  mempty = EndoM pure

-- Jack

Justin Paston-Cooper <paston.cooper at gmail.com> writes:

> Hello,
>
> I suggest taking a quick look at the function ‘fold’ in Data.Foldable, and
> also Data.Functor.Compose. That should be good start for composing any list
> of such functions.
>
> Cheers,
>
> J.
>
> On Sat, 1 Feb 2020 at 19:55, Debasish Ghosh <ghosh.debasish at gmail.com>
> wrote:
>
>> Hi -
>>
>> How can I generalize the following pattern to an arbitrary list of
>> functions ?
>>
>> compose :: (Monad m) => (Foo -> m Foo) -> (Foo -> m Foo) -> (Foo -> m Foo)
>> -> Foo -> m Foo
>> compose f1 f2 f3 acc = do
>>   a <- f1 acc
>>   b <- f2 a
>>   f3 b
>>
>> Any help please ..
>> regards.
>>
>> --
>> Debasish Ghosh
>> http://manning.com/ghosh2
>> http://manning.com/ghosh
>>
>> Twttr: @debasishg
>> Blog: http://debasishg.blogspot.com
>> Code: http://github.com/debasishg
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From jack at jackkelly.name  Sat Feb  1 22:09:39 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Sun, 02 Feb 2020 08:09:39 +1000
Subject: [Haskell-cafe] Haskell positions available at Luminous
	Computing.
In-Reply-To: <r142s4$2icn$1@ciao.gmane.io> (Ben Franksen's message of "Sat, 1
 Feb 2020 15:44:20 +0100")
References: <44E5E9D0-8A26-4CA9-8A93-643FB3B3E76A@gmail.com>
 <r142s4$2icn$1@ciao.gmane.io>
Message-ID: <877e163qos.fsf@jackkelly.name>

Ben Franksen <ben.franksen at online.de> writes:

> Am 31.01.20 um 01:19 schrieb David Banas:
>> https://www.luminouscomputing.com/
> Quoting from that page:
> """
> AI should be deployed to every product we interact with on a daily basis.
> """
> Am I the only one how is horrified when they read something like this?

Beware he who thinks he has found the universal hammer.

-- Jack

From krystal.maughan at gmail.com  Sat Feb  1 22:13:32 2020
From: krystal.maughan at gmail.com (Krystal Maughan)
Date: Sat, 1 Feb 2020 17:13:32 -0500
Subject: [Haskell-cafe] Haskell positions available at Luminous
	Computing.
In-Reply-To: <877e163qos.fsf@jackkelly.name>
References: <44E5E9D0-8A26-4CA9-8A93-643FB3B3E76A@gmail.com>
 <r142s4$2icn$1@ciao.gmane.io> <877e163qos.fsf@jackkelly.name>
Message-ID: <CAOrb2G7mOkKdAcsH4z+czK-SqhbhF_Sw+ehmLK37-CpiNAkZRA@mail.gmail.com>

Of course not. Algorithmic Bias is still a hot topic of research in AI; we
definitely haven't figured that out yet.
AI is definitely *not* for "all the things".

Best,
Krystal

On Sat, 1 Feb 2020 at 17:10, Jack Kelly <jack at jackkelly.name> wrote:

> Ben Franksen <ben.franksen at online.de> writes:
>
> > Am 31.01.20 um 01:19 schrieb David Banas:
> >> https://www.luminouscomputing.com/
> > Quoting from that page:
> > """
> > AI should be deployed to every product we interact with on a daily basis.
> > """
> > Am I the only one how is horrified when they read something like this?
>
> Beware he who thinks he has found the universal hammer.
>
> -- Jack
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/74f7a8ed/attachment.html>

From juan.casanova at ed.ac.uk  Sat Feb  1 22:11:53 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Sat, 01 Feb 2020 22:11:53 +0000
Subject: [Haskell-cafe] Seeking help to generalize this ..
In-Reply-To: <87blqi3qv6.fsf@jackkelly.name>
References: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
 <CAEndGgTurC1a_sx7015qEgyg9VR+i7Q6jv3jw7dfe3=iDMu9hQ@mail.gmail.com>
 <87blqi3qv6.fsf@jackkelly.name>
Message-ID: <20200201221153.61755y1rbaf84uk0@www.staffmail.ed.ac.uk>

> Related:
>
> In Data.Monoid there is the 'Endo' newtype, which wraps functions of
> type 'a -> a'. Is there an 'EndoM' variant, or is that something that's
> usually created by putting other pieces together? Below is a sketch of
> what I mean:
>
> -- Maybe this is known by another name?
> newtype EndoM f a = EndoM { appEndoM :: a -> f a }
>
> -- Bind typeclass is from package semigroupoids.
> -- It means "Monad sans 'return'".
> -- Maybe use Monad f => here instead if getting the Bind instances is
> -- too annoying? (e.g., Writing orphan instances).
> instance Bind f => Semigroup (EndoM f a) where
>   EndoM f <> EndoM g = EndoM $ f ->- g
>
> -- Bind is not a superclass of Monad, so we get this awkward set of
> -- required constraints here.
> instance (Bind f, Monad f) => Monoid (EndoM f a) where
>   mempty = EndoM pure
>
> -- Jack
>

Not undervaluing this post, but to be clear to the OP, all of that  
really isn't adding any capabilities, just reifying the ones that  
others exposed. (You can use foldMap instead of foldr). This could be  
useful if you want to do higher-level stuff with it later on, but for  
the purposes of the original post I think it really is overkill, isn't  
it?

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From ben.franksen at online.de  Sat Feb  1 22:58:49 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Sat, 1 Feb 2020 23:58:49 +0100
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <CAKFCL4V0YD9-YqW-BnLzjPhb4Ko-Q5mgkQzr4_fkKUH9xL7UwA@mail.gmail.com>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
 <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>
 <20200201090126.GF49778@straasha.imrryr.org>
 <1AB359CC-88D7-46A1-9BAC-4A7C996D421C@inconsistent.nl>
 <r144ss$vnj$1@ciao.gmane.io>
 <CAKFCL4V0YD9-YqW-BnLzjPhb4Ko-Q5mgkQzr4_fkKUH9xL7UwA@mail.gmail.com>
Message-ID: <r14vr9$1n3i$1@ciao.gmane.io>

Am 01.02.20 um 16:30 schrieb Brandon Allbery:
> I've been complaining about that for years. Every so often there's
> discussion of a non-GPLed alternative preprocessor, but the questions
> apparently become fairly hairy quickly, so the current mess is just
> accepted. :(

I find it strangely inconsistent that using cpphs is found to be
problematic because of its GPL license, while using the equally GPL
licensed gcc C preprocessor is not. Can anyone shed light on this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 4211 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/70fbd7a7/attachment.key>

From jo at durchholz.org  Sat Feb  1 23:11:27 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 2 Feb 2020 00:11:27 +0100
Subject: [Haskell-cafe] Haskell positions available at Luminous
	Computing.
In-Reply-To: <CAOrb2G7mOkKdAcsH4z+czK-SqhbhF_Sw+ehmLK37-CpiNAkZRA@mail.gmail.com>
References: <44E5E9D0-8A26-4CA9-8A93-643FB3B3E76A@gmail.com>
 <r142s4$2icn$1@ciao.gmane.io> <877e163qos.fsf@jackkelly.name>
 <CAOrb2G7mOkKdAcsH4z+czK-SqhbhF_Sw+ehmLK37-CpiNAkZRA@mail.gmail.com>
Message-ID: <2ce44cf8-87ef-5802-5ab6-bc4b742e8273@durchholz.org>

Well, to be fair, that webpage has quite a handful of red flags.
Too vague, the budget doesn't quite add up for the things you plan to do 
(or for the investor names you drop), far too many investors (keeping 
them happy must be like herding cats), no roadmap, no "we achieved this 
and plan to achieve that in the next two years", 100% unrealistic ideas 
about entering competition (photonics or no, you'll need to build 
nanoscale chips, and with your current budget you have 0% chance that 
this will work - leaves one wondering how serious that part is, and by 
attribution, how serious the rest of the page is).

I might be interested if I were at the beginning of my career, and were 
able to take risks because there's time to switch to something boring 
with a good income.

Of course I might be totally wrong :-)

But paint me a sceptic here.

Am 01.02.20 um 23:13 schrieb Krystal Maughan:
> Of course not. Algorithmic Bias is still a hot topic of research in AI; 
> we definitely haven't figured that out yet.
> AI is definitely *not* for "all the things".
> 
> Best,
> Krystal
> 
> On Sat, 1 Feb 2020 at 17:10, Jack Kelly <jack at jackkelly.name 
> <mailto:jack at jackkelly.name>> wrote:
> 
>     Ben Franksen <ben.franksen at online.de
>     <mailto:ben.franksen at online.de>> writes:
> 
>      > Am 31.01.20 um 01:19 schrieb David Banas:
>      >> https://www.luminouscomputing.com/
>      > Quoting from that page:
>      > """
>      > AI should be deployed to every product we interact with on a
>     daily basis.
>      > """
>      > Am I the only one how is horrified when they read something like
>     this?
> 
>     Beware he who thinks he has found the universal hammer.

From carter.schonwald at gmail.com  Sat Feb  1 23:18:41 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2020 18:18:41 -0500
Subject: [Haskell-cafe] Haskell positions available at Luminous
	Computing.
In-Reply-To: <2ce44cf8-87ef-5802-5ab6-bc4b742e8273@durchholz.org>
References: <44E5E9D0-8A26-4CA9-8A93-643FB3B3E76A@gmail.com>
 <r142s4$2icn$1@ciao.gmane.io> <877e163qos.fsf@jackkelly.name>
 <CAOrb2G7mOkKdAcsH4z+czK-SqhbhF_Sw+ehmLK37-CpiNAkZRA@mail.gmail.com>
 <2ce44cf8-87ef-5802-5ab6-bc4b742e8273@durchholz.org>
Message-ID: <CAHYVw0xyfB7emDr+qRWxN+Ye9bU2uEnxEgRSTMZ7c=OYSFqh7w@mail.gmail.com>

googling seems to suggest its
http://faculty.ee.princeton.edu/prucnal/?q=research/photonic-spiking-neural-networks


On Sat, Feb 1, 2020 at 6:12 PM Joachim Durchholz <jo at durchholz.org> wrote:

> Well, to be fair, that webpage has quite a handful of red flags.
> Too vague, the budget doesn't quite add up for the things you plan to do
> (or for the investor names you drop), far too many investors (keeping
> them happy must be like herding cats), no roadmap, no "we achieved this
> and plan to achieve that in the next two years", 100% unrealistic ideas
> about entering competition (photonics or no, you'll need to build
> nanoscale chips, and with your current budget you have 0% chance that
> this will work - leaves one wondering how serious that part is, and by
> attribution, how serious the rest of the page is).
>
> I might be interested if I were at the beginning of my career, and were
> able to take risks because there's time to switch to something boring
> with a good income.
>
> Of course I might be totally wrong :-)
>
> But paint me a sceptic here.
>
> Am 01.02.20 um 23:13 schrieb Krystal Maughan:
> > Of course not. Algorithmic Bias is still a hot topic of research in AI;
> > we definitely haven't figured that out yet.
> > AI is definitely *not* for "all the things".
> >
> > Best,
> > Krystal
> >
> > On Sat, 1 Feb 2020 at 17:10, Jack Kelly <jack at jackkelly.name
> > <mailto:jack at jackkelly.name>> wrote:
> >
> >     Ben Franksen <ben.franksen at online.de
> >     <mailto:ben.franksen at online.de>> writes:
> >
> >      > Am 31.01.20 um 01:19 schrieb David Banas:
> >      >> https://www.luminouscomputing.com/
> >      > Quoting from that page:
> >      > """
> >      > AI should be deployed to every product we interact with on a
> >     daily basis.
> >      > """
> >      > Am I the only one how is horrified when they read something like
> >     this?
> >
> >     Beware he who thinks he has found the universal hammer.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200201/15fa4580/attachment.html>

From carter.schonwald at gmail.com  Sun Feb  2 05:19:48 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 2 Feb 2020 00:19:48 -0500
Subject: [Haskell-cafe] Error trying to build haskell-dbus on FreeBSD
In-Reply-To: <r14vr9$1n3i$1@ciao.gmane.io>
References: <3015c7d1-e49e-445c-a15d-67fbc029250d@www.fastmail.com>
 <CAGtp2SiqX_vCuMYTjvQS0fxU2YpExvtKcCfrv_sDrOHbue52GQ@mail.gmail.com>
 <817e5f82-9a4a-4fb5-944c-d83551ee92a9@www.fastmail.com>
 <CAGtp2Sg-bzDS6m-Pdp9kbZBwUSxZoRcPJ3Uwi+p-b93xoGrjgQ@mail.gmail.com>
 <1e262df3-18e1-4971-96a2-5265a2e91b92@www.fastmail.com>
 <CAGtp2Si7QYSDNF9ETCqTFdrbCRagkQGfTBnNkSWXGdm_JF+P8A@mail.gmail.com>
 <CALH631=pwNev6TUwq9T=auS+cKSxWYeEAp8LpA1QeSEtUVaHog@mail.gmail.com>
 <20200201090126.GF49778@straasha.imrryr.org>
 <1AB359CC-88D7-46A1-9BAC-4A7C996D421C@inconsistent.nl>
 <r144ss$vnj$1@ciao.gmane.io>
 <CAKFCL4V0YD9-YqW-BnLzjPhb4Ko-Q5mgkQzr4_fkKUH9xL7UwA@mail.gmail.com>
 <r14vr9$1n3i$1@ciao.gmane.io>
Message-ID: <CAHYVw0x29yGgMXdXy2FTy8scPomd9EkePLqyf2KyMDG7QS88NA@mail.gmail.com>

Comingling of c and Haskell code of incompatible licenses is way harder to
do by accident than Haskell and Haskell.

Every arms length subsystem volunteers have to maintain is more complexity
to juggle.

Solution : let someone get angry enough that they volunteer to fix it and
encourage them.

If it’s frustrating, help fix it.

On Sat, Feb 1, 2020 at 5:59 PM Ben Franksen <ben.franksen at online.de> wrote:

> Am 01.02.20 um 16:30 schrieb Brandon Allbery:
> > I've been complaining about that for years. Every so often there's
> > discussion of a non-GPLed alternative preprocessor, but the questions
> > apparently become fairly hairy quickly, so the current mess is just
> > accepted. :(
>
> I find it strangely inconsistent that using cpphs is found to be
> problematic because of its GPL license, while using the equally GPL
> licensed gcc C preprocessor is not. Can anyone shed light on this?
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200202/8cfbd5b7/attachment-0001.html>

From juan.casanova at ed.ac.uk  Sun Feb  2 20:27:40 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Sun, 02 Feb 2020 20:27:40 +0000
Subject: [Haskell-cafe] ListT version leveraging Traversable
Message-ID: <20200202202740.186859jo92fxhucc@www.staffmail.ed.ac.uk>

Hello haskell-cafe,

I am going to be stating a series of things about the way I understand  
some things right now (both theoretical ideas and the general  
consensus on the Haskell community about some topics). Please feel  
free to point out to any of these assumptions if you think it is flawed.

1. ListT is deprecated as a Monad Transformer because for some monads  
it is not a proper transformer.
2. (1) translates literally into the fact that the MonadTrans instace  
for ListT is unlawful for some monads.
3. The fundamental concept of List as a monad is non-determinism, it  
is the notion of doing operations on non-deterministic results and  
generating new non-deterministic results.
4. A "correct" ListT transformer would therefore: 4.1. Be lawful. 4.2.  
Represent the notion of non-deterministic results tied within the  
monad they are transforming. 4.3. Be such that when applied to the  
Identity monad it returns the original List monad.
5. There is no canonical and accepted by the community alternative to  
ListT which fulfills both points in (4).
6. But there is no proof that (5) is a theoretically necessary thing.

I am putting this this way because what I am going to claim now is  
that I have found one such transformer, that satisfies both points in  
(4). Therefore, it is very likely that some of my assumptions are  
flawed.

Note that I make no claim that my transformer is unique up to  
isomorphism. It just seems that what I did does the job, but maybe  
there are other *fundamentally distinct* ways to fulfill the two  
points in (4)? Is that maybe the reason why there is no canonical  
version of ListT? But then why haven't I seen any of those versions,  
including the one I will present? (By the way, I already see different  
versions, but which correspond to the same idea just traversing lists  
in different orders. Permutations of it, so to speak).

So, onto what I've done. I am going to be using an example to explain  
why I think what I did fulfills (4.2). This is not a proof, but I feel  
that (4.2) is not a formal statement anyway (is there a formal way to  
express this?).

The basic problem I see with implementing ListT correctly is that the  
non-determinism produces non-deterministic monadic results, and  
because we wish to keep the non-determinism only to the results and  
not to the transformed monad itself, there is a need to choose what  
monadic results we keep.

But then, I think, we have a "canonical" way of doing a collection of  
monadic results: Traversals. And what a wonderful thing that lists are  
the most natural version of Traversable. Therefore, what I did is to  
use traverse (and concat, which relies on Foldable which is a  
superclass of Traversable) to collect the monadic results and produce  
something that fulfills the type signature that ListT should have.

Here's the code. The only really interesting bit is bind:

data TravListT m a = TravListT {runTravListT :: m [a]}

instance Functor m => Functor (TravListT m) where
	fmap f (TravListT m) = TravListT (fmap (fmap f) m)

instance Applicative m => Applicative (TravListT m) where
	pure x = TravListT (pure (pure x))
	(TravListT fs) <*> (TravListT xs) = TravListT (getCompose ((Compose  
fs) <*> Compose xs))

instance Monad m => Monad (TravListT m) where
	return = pure
	(TravListT ma) >>= f = TravListT (ma >>= (\l -> (concat <$> (traverse  
(runTravListT . f) l))))

instance MonadTrans TravListT where
	lift m = TravListT (return <$> m)


I also (believe) I have proof that TravListT is a lawful MonadTrans,  
but I have skipped that here since this is already long enough. If you  
want to talk about that, we can.

This allows me to do the things I would expect of a ListT, such as  
having a stateful list [1,3,7,11], applying a stateful operation  
wrapped around a Maybe monad that non-deterministically multiplies and  
sums each result with the current state with a special case, and  
increases the state by 1, and produce the stateful, non-deterministic  
result of doing all of that:

let mposns = return [1,3,7,11] :: StateT a Maybe [Int]
let tmposns = TravListT mposns
let f = \n -> TravListT (StateT (\s -> if (s == n) then Nothing else  
(Just ([s * n,s + n],s+1))))

let rr = tmposns >>= f

runStateT (runTravListT rr) 100
Just ([100,101,303,104,714,109,1133,114],104)

runStateT (runTravListT rr) 1
Nothing



So I guess my overall question is: why is this not a more standard  
thing? Are any of my assumptions wrong? Is there something wrong with  
this monad transformer? Is this really a new idea (I'd be surprised)?


Thanks and sorry for the long email,
Juan Casanova.

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From rae at richarde.dev  Sun Feb  2 21:41:47 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Sun, 2 Feb 2020 21:41:47 +0000
Subject: [Haskell-cafe] Looking-up a TyCon of a type exposed from public
 module but defined in hidden module
In-Reply-To: <E0F71474-49D1-4C68-B50B-4E1069925056@gmail.com>
References: <E0F71474-49D1-4C68-B50B-4E1069925056@gmail.com>
Message-ID: <13C2AD8B-30C0-4717-A534-ECD3986865E6@richarde.dev>

I don't know the "official" way to do this, but `Module` is a very simple type. You could always build it yourself, using the unit ID from another `singletons` module and just change the module name to suit your needs.

Richard

> On Feb 1, 2020, at 11:59 AM, 石井大海 <konn.jinro at gmail.com> wrote:
> 
> Hi cafe,
> 
> I'm currently writing GHC Type-Checker Plugin [ghc-typelits-presburger], which enhances type-inference involving type-level naturals using Presburger arithmetic.
> 
> To process constraints properly, I need an access to TyCons of `TrueSym0`,
> `FalseSym0`, `GTSym0`, etc. from `singletons` package.
> These types are exposed by public modules, e.g. Data.Singletons.Prelude, but
> it seems that they are originally defined in private module `Data.Singletons.Prelude.Instances`.
> 
> I first tried, to retrieve the `TyCon` for `TrueSym0`, the following:
> 
> ```
>  insts <- lookupModule (mkModuleName "Data.Singletons.Prelude.Instances") (fsLit "singletons")
>  singTrueSym0 <- tcLookupTyCon =<< lookupOrig insts (mkTcOcc "TrueSym0")
> ```
> 
> But this results in the following compile-time error:
> 
> ```
> ghc: panic! (the 'impossible' happened)
>  (GHC version 8.6.5 for x86_64-apple-darwin):
>       Unable to resolve module looked up by plugin:
>  Data.Singletons.Prelude.Instances
> 
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> ```
> 
> Then, I tried to lookup `TrueSym0` from exposed module, say Data.Singletons.Prelude:
> 
> ```
>  prel <- lookupModule (mkModuleName "Data.Singletons.Prelude") (fsLit "singletons")
>  singTrueSym0 <- tcLookupTyCon =<< lookupOrig prel (mkTcOcc "TrueSym0")
> ```
> 
> But this resulted in the following error:
> 
> ```
> • Can't find interface-file declaration for type constructor or class singletons-2.5.1:Data.Singletons.Prelude.TrueSym0
>    Probable cause: bug in .hi-boot file, or inconsistent .hi file
>    Use -ddump-if-trace to get an idea of which file caused the error
> • In the type signature: ...
> ```
> 
> Is there any way, in GHC API, to lookup symbols exported from public module but originally defined in hidden module?
> 
> Thanks,
> 
> [ghc-typelits-presburger]: https://github.com/konn/ghc-typelits-presburger
> 
> -- Hiromi ISHII
> konn.jinro at gmail.com
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


From lysxia at gmail.com  Sun Feb  2 23:25:52 2020
From: lysxia at gmail.com (Li-yao Xia)
Date: Sun, 2 Feb 2020 18:25:52 -0500
Subject: [Haskell-cafe] ListT version leveraging Traversable
In-Reply-To: <20200202202740.186859jo92fxhucc@www.staffmail.ed.ac.uk>
References: <20200202202740.186859jo92fxhucc@www.staffmail.ed.ac.uk>
Message-ID: <54d7f31c-d0a2-5f90-8e24-2badf5025586@gmail.com>

Hi Juan,

Unfortunately, TravListT is actually equivalent to the deprecated ListT 
as found in transformers (just using traverse instead of mapM, but it's 
really the same thing). The problem is not (only) the MonadTrans 
instance, but the Monad instance: (>>=) is not associative for arbitrary 
underlying monads.

Moreover, (>>=) is not compatible with (<*>) (i.e., this law is not 
satisfied: (<*>) = ap, or equivalently, f <*> g = (f >>= \i -> i <$> 
g)). (Coincidentally, transformers's ListT has the exact same issue.)

To propose a new alternative solution, a good starting point to make 
more concrete claims would be to compare it with existing ones (the 
three I know of: list-t, logict, and something using ContT). What 
functions are possible/easier than before to write? How easy is it to 
convert between the different formulations?

Regards,
Li-yao

On 2/2/20 3:27 PM, Juan Casanova wrote:
> Hello haskell-cafe,
> 
> I am going to be stating a series of things about the way I understand 
> some things right now (both theoretical ideas and the general consensus 
> on the Haskell community about some topics). Please feel free to point 
> out to any of these assumptions if you think it is flawed.
> 
> 1. ListT is deprecated as a Monad Transformer because for some monads it 
> is not a proper transformer.
> 2. (1) translates literally into the fact that the MonadTrans instace 
> for ListT is unlawful for some monads.
> 3. The fundamental concept of List as a monad is non-determinism, it is 
> the notion of doing operations on non-deterministic results and 
> generating new non-deterministic results.
> 4. A "correct" ListT transformer would therefore: 4.1. Be lawful. 4.2. 
> Represent the notion of non-deterministic results tied within the monad 
> they are transforming. 4.3. Be such that when applied to the Identity 
> monad it returns the original List monad.
> 5. There is no canonical and accepted by the community alternative to 
> ListT which fulfills both points in (4).
> 6. But there is no proof that (5) is a theoretically necessary thing.
> 
> I am putting this this way because what I am going to claim now is that 
> I have found one such transformer, that satisfies both points in (4). 
> Therefore, it is very likely that some of my assumptions are flawed.
> 
> Note that I make no claim that my transformer is unique up to 
> isomorphism. It just seems that what I did does the job, but maybe there 
> are other *fundamentally distinct* ways to fulfill the two points in 
> (4)? Is that maybe the reason why there is no canonical version of 
> ListT? But then why haven't I seen any of those versions, including the 
> one I will present? (By the way, I already see different versions, but 
> which correspond to the same idea just traversing lists in different 
> orders. Permutations of it, so to speak).
> 
> So, onto what I've done. I am going to be using an example to explain 
> why I think what I did fulfills (4.2). This is not a proof, but I feel 
> that (4.2) is not a formal statement anyway (is there a formal way to 
> express this?).
> 
> The basic problem I see with implementing ListT correctly is that the 
> non-determinism produces non-deterministic monadic results, and because 
> we wish to keep the non-determinism only to the results and not to the 
> transformed monad itself, there is a need to choose what monadic results 
> we keep.
> 
> But then, I think, we have a "canonical" way of doing a collection of 
> monadic results: Traversals. And what a wonderful thing that lists are 
> the most natural version of Traversable. Therefore, what I did is to use 
> traverse (and concat, which relies on Foldable which is a superclass of 
> Traversable) to collect the monadic results and produce something that 
> fulfills the type signature that ListT should have.
> 
> Here's the code. The only really interesting bit is bind:
> 
> data TravListT m a = TravListT {runTravListT :: m [a]}
> 
> instance Functor m => Functor (TravListT m) where
>      fmap f (TravListT m) = TravListT (fmap (fmap f) m)
> 
> instance Applicative m => Applicative (TravListT m) where
>      pure x = TravListT (pure (pure x))
>      (TravListT fs) <*> (TravListT xs) = TravListT (getCompose ((Compose 
> fs) <*> Compose xs))
> 
> instance Monad m => Monad (TravListT m) where
>      return = pure
>      (TravListT ma) >>= f = TravListT (ma >>= (\l -> (concat <$> 
> (traverse (runTravListT . f) l))))
> 
> instance MonadTrans TravListT where
>      lift m = TravListT (return <$> m)
> 
> 
> I also (believe) I have proof that TravListT is a lawful MonadTrans, but 
> I have skipped that here since this is already long enough. If you want 
> to talk about that, we can.
> 
> This allows me to do the things I would expect of a ListT, such as 
> having a stateful list [1,3,7,11], applying a stateful operation wrapped 
> around a Maybe monad that non-deterministically multiplies and sums each 
> result with the current state with a special case, and increases the 
> state by 1, and produce the stateful, non-deterministic result of doing 
> all of that:
> 
> let mposns = return [1,3,7,11] :: StateT a Maybe [Int]
> let tmposns = TravListT mposns
> let f = \n -> TravListT (StateT (\s -> if (s == n) then Nothing else 
> (Just ([s * n,s + n],s+1))))
> 
> let rr = tmposns >>= f
> 
> runStateT (runTravListT rr) 100
> Just ([100,101,303,104,714,109,1133,114],104)
> 
> runStateT (runTravListT rr) 1
> Nothing
> 
> 
> 
> So I guess my overall question is: why is this not a more standard 
> thing? Are any of my assumptions wrong? Is there something wrong with 
> this monad transformer? Is this really a new idea (I'd be surprised)?
> 
> 
> Thanks and sorry for the long email,
> Juan Casanova.
> 

From ghosh.debasish at gmail.com  Mon Feb  3 06:27:46 2020
From: ghosh.debasish at gmail.com (Debasish Ghosh)
Date: Mon, 3 Feb 2020 11:57:46 +0530
Subject: [Haskell-cafe] Seeking help to generalize this ..
In-Reply-To: <20200201221153.61755y1rbaf84uk0@www.staffmail.ed.ac.uk>
References: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
 <CAEndGgTurC1a_sx7015qEgyg9VR+i7Q6jv3jw7dfe3=iDMu9hQ@mail.gmail.com>
 <87blqi3qv6.fsf@jackkelly.name>
 <20200201221153.61755y1rbaf84uk0@www.staffmail.ed.ac.uk>
Message-ID: <CAE7GCT4mczNySD=A8p+iYtZh005zOj=NK2ee7DUBJVkdfbmeHQ@mail.gmail.com>

Thanks for all the suggestions ..

On Sun, Feb 2, 2020 at 4:20 AM Juan Casanova <juan.casanova at ed.ac.uk> wrote:

> > Related:
> >
> > In Data.Monoid there is the 'Endo' newtype, which wraps functions of
> > type 'a -> a'. Is there an 'EndoM' variant, or is that something that's
> > usually created by putting other pieces together? Below is a sketch of
> > what I mean:
> >
> > -- Maybe this is known by another name?
> > newtype EndoM f a = EndoM { appEndoM :: a -> f a }
> >
> > -- Bind typeclass is from package semigroupoids.
> > -- It means "Monad sans 'return'".
> > -- Maybe use Monad f => here instead if getting the Bind instances is
> > -- too annoying? (e.g., Writing orphan instances).
> > instance Bind f => Semigroup (EndoM f a) where
> >   EndoM f <> EndoM g = EndoM $ f ->- g
> >
> > -- Bind is not a superclass of Monad, so we get this awkward set of
> > -- required constraints here.
> > instance (Bind f, Monad f) => Monoid (EndoM f a) where
> >   mempty = EndoM pure
> >
> > -- Jack
> >
>
> Not undervaluing this post, but to be clear to the OP, all of that
> really isn't adding any capabilities, just reifying the ones that
> others exposed. (You can use foldMap instead of foldr). This could be
> useful if you want to do higher-level stuff with it later on, but for
> the purposes of the original post I think it really is overkill, isn't
> it?
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Debasish Ghosh
http://manning.com/ghosh2
http://manning.com/ghosh

Twttr: @debasishg
Blog: http://debasishg.blogspot.com
Code: http://github.com/debasishg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200203/0c216e49/attachment.html>

From olf at aatal-apotheke.de  Mon Feb  3 21:03:18 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Mon, 3 Feb 2020 22:03:18 +0100
Subject: [Haskell-cafe] ListT version leveraging Traversable
Message-ID: <FC05D667-9D8B-4967-8791-D03E1E4E0DA6@aatal-apotheke.de>

Dear Juan, 

Traversables indeed are intimately connected with monad transformers:
Two monads are known to commute if one monad (say t) yields a functor on the Kleisli category of the other monad (say m). 
If you write down what this means for fmap, you get the following type signature:

(a -> m b) -> t a -> m (t b)

which is the type of mapM and traverse. So does every Traversable monad t yield a monad transformer? Not quite. A functor has to obey the law fmap f.fmap g = fmap (f.g) and this is not given simply by the existence of traverse, you need:

traverse f <=< traverse g = traverse (f <=< g).

As Li-yao Xia pointed out, it is fairly easy to find a counterexample to <*> = ap for TravListT. But you could of course define <*> = ap and the problem is gone. However, a lawful monad satisfies 

join . join = join . fmap join

and there is a counterexample for TravListT: 

type M a = TravListT [] a   -- [] is not commutative

x :: M Int
x = TravListT ([[1,2],[3,4]])

-- ((join.join) xxx) /= ((join.fmap join) xxx)
xxx :: M (M (M Int))
xxx = let xx = [[x, x],[x]] in TravListT [[TravListT xx,TravListT (reverse xx)]]

I have not attempted to make this counterexample minimal, so please forgive the long term. 
Your claim (3) that [] is the monad of non-determinism is at least not entirely true. Lists modulo ordering and multiplicity are a model of non-determinism. In other words, if Data.Set was a monad then this was your model of non-determinism. Indeed, we have 

((sort.runTravListT.join.join) xxx) == ((sort.runTravListT.join.fmap join) xxx)

so the counterexample is only a counterexample because the ordering matters for equality. If you're modelling non-determinism, you may safely use the deprecated ListT knowing that the monad laws are violated only due to ordering and multiplicity. 

Olaf

From tom.schrijvers at kuleuven.be  Tue Feb  4 10:58:38 2020
From: tom.schrijvers at kuleuven.be (Tom Schrijvers)
Date: Tue, 4 Feb 2020 10:58:38 +0000
Subject: [Haskell-cafe] CfP: Haskell Symposium 2020
Message-ID: <0D140773-4915-42DF-B131-A95C9E3A3073@kuleuven.be>


================================================================================
 ACM SIGPLAN                                              CALL FOR SUBMISSIONS

                          Haskell Symposium 2020

                              New Jersey, United States
                            27--28 August, 2020

              http://www.haskell.org/haskell-symposium/2020/

================================================================================

The ACM SIGPLAN Haskell Symposium 2020 will be co-located with the 2020
International Conference on Functional Programming (ICFP).

Like last year, we will be using a lightweight double-blind reviewing process.
See further information below.

The Haskell Symposium presents original research on Haskell,
discusses practical experience and future development of the language, and
promotes other forms of declarative programming.

Topics of interest include:

  * Language design, with a focus on possible extensions and modifications of
    Haskell as well as critical discussions of the status quo;

  * Theory, such as formal semantics of the present language or future
    extensions, type systems, effects, metatheory, and foundations for
    program analysis and transformation;

  * Implementations, including program analysis and transformation,
    static and dynamic compilation for sequential, parallel, and distributed
    architectures, memory management, as well as foreign function and
    component interfaces;

  * Libraries, that demonstrate new ideas or techniques for functional
    programming in Haskell;

  * Tools, such as profilers, tracers, debuggers, preprocessors,
    and testing tools;

  * Applications, to scientific and symbolic computing, databases, multimedia,
    telecommunication, the web, and so forth;

  * Functional Pearls, being elegant and instructive programming examples;

  * Experience Reports, to document general practice and experience in
    education, industry, or other contexts;

  * System Demonstrations, based on running software rather than novel
    research results.

Regular papers should explain their research contributions in both general and
technical terms, identifying what has been accomplished, explaining why it is
significant, and relating it to previous work, and to other languages where
appropriate.

Experience reports and functional pearls need not necessarily report original
academic research results. For example, they may instead report reusable
programming idioms, elegant ways to approach a problem, or practical experience
that will be useful to other users, implementers, or researchers. The key
criterion for such a paper is that it makes a contribution from which other
Haskellers can benefit. It is not enough simply to describe a standard solution
to a standard programming problem, or report on experience where you used
Haskell in the standard way and achieved the result you were expecting.

System demonstrations should summarize the system capabilities that would be
demonstrated. The proposals will be judged on whether the ensuing session is
likely to be important and interesting to the Haskell community at large,
whether on grounds academic or industrial, theoretical or practical, technical,
social or artistic. Please contact the program chair with any questions about
the relevance of a proposal.


Submission Details
==================

Early and Regular Track
-----------------------

The Haskell Symposium uses a two-track submission process so that some papers
can gain early feedback. Strong papers submitted to the early track are
accepted outright, and the others will be given their reviews and invited to
resubmit to the regular track. Papers accepted via the early and regular
tracks are considered of equal value and will not be distinguished in the
proceedings. Although all papers may be submitted to the early track, authors
of functional pearls and experience reports are particularly encouraged to use
this mechanism. The success of these papers depends heavily on the way they
are presented, and submitting early will give the program committee a chance
to provide feedback and help draw out the key ideas.

Formatting
----------

Submitted papers should be in portable document format (PDF), formatted using
the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with
the `sigplan` sub-format for ACM proceedings. For details, see:

  http://www.sigplan.org/Resources/Author/#acmart-format

It is recommended to use the `review` option when submitting a paper; this option
enables line numbers for easy reference in reviews.

Functional pearls, experience reports, and demo proposals should be
labelled clearly as such.

Lightweight Double-blind Reviewing
----------------------------------

Haskell Symposium 2020 will use a lightweight double-blind reviewing process.
To facilitate this, submitted papers must adhere to two rules:

 1. Author names and institutions must be omitted, and
 2. References to authors’ own related work should be in the third person
    (e.g., not “We build on our previous work …” but rather “We build on the work of …”).

The purpose of this process is to help the reviewers come to an initial
judgment about the paper without bias, not to make it impossible for them to
discover the authors if they were to try. Nothing should be done in the name
of anonymity that weakens the submission or makes the job of reviewing the
paper more difficult (e.g., important background references should not be
omitted or anonymized). In addition, authors should feel free to disseminate
their ideas or draft versions of their paper as they normally would. For
instance, authors may post drafts of their papers on the web or give talks on
their research ideas.

A reviewer will learn the identity of the author(s) of a paper after a review
is submitted.

Page Limits
-----------

The length of submissions should not exceed the following limits:

Regular paper:      12 pages
Functional pearl:   12 pages
Experience report:   6 pages
Demo proposal:       2 pages

There is no requirement that all pages are used. For example, a
functional pearl may be much shorter than 12 pages. In all cases,
the list of references is not counted against these page limits.

Deadlines
---------

Early track:
  Submission deadline:    20 March 2020     (Fri)
  Notification:           24 April 2020     (Fri)

Regular track and demos:
  Submission deadline:    15 May  2020      (Fri)
  Notification:           26 June 2020      (Fri)

Deadlines are valid anywhere on Earth.

Submission
----------

Submissions must adhere to SIGPLAN's republication policy
(http://sigplan.org/Resources/Policies/Republication/), and authors
should be aware of ACM's policies on plagiarism
(https://www.acm.org/publications/policies/plagiarism).
Program Committee members are allowed to submit papers, but their papers will
be held to a higher standard.

The paper submission deadline and length limitations are firm.
There will be no extensions, and papers violating the length
limitations will be summarily rejected.

Papers should be submitted through HotCRP at:

  https://haskell20.hotcrp.com/

Improved versions of a paper may be submitted at any point before the
submission deadline using the same web interface.

Supplementary material: Authors have the option to attach supplementary
material to a submission, on the understanding that reviewers may choose not
to look at it. This supplementary material should not be submitted as part of
the main document; instead, it should be uploaded as a separate PDF document
or tarball.

Supplementary material should be uploaded at submission time, not by providing
a URL in the paper that points to an external repository.

Authors are free to upload both anonymized and non-anonymized supplementary
material. Anonymized supplementary material will be visible to reviewers
immediately; non-anonymized supplementary material will be revealed to
reviewers only after they have submitted their review of the paper and learned
the identity of the author(s).

Resubmitted Papers: Authors who submit a revised version of a paper that has
previously been rejected by another conference have the option to attach an
annotated copy of the reviews of their previous submission(s), explaining how
they have addressed these previous reviews in the present submission. If a
reviewer identifies him/herself as a reviewer of this previous submission and
wishes to see how his/her comments have been addressed, the principal editor
will communicate to this reviewer the annotated copy of his/her previous
review. Otherwise, no reviewer will read the annotated copies of the previous
reviews.

Travel Support
==============

Student attendees with accepted papers can apply for a SIGPLAN PAC grant to
help cover travel expenses. PAC also offers other support, such as for
child-care expenses during the meeting or for travel costs for companions of
SIGPLAN members with physical disabilities, as well as for travel from
locations outside of North America and Europe. For details on the PAC program,
see its web page (http://pac.sigplan.org).

Proceedings
===========

Accepted papers will be included in the ACM Digital Library. Their authors
will be required to choose one of the following options:
- Author retains copyright of the work and grants ACM a non-exclusive
  permission-to-publish license (and, optionally, licenses the work with a
  Creative Commons license);
- Author retains copyright of the work and grants ACM an exclusive
  permssion-to-publish license;
- Author transfers copyright of the work to ACM.
For more information, please see ACM Copyright Policy
(http://www.acm.org/publications/policies/copyright-policy) and ACM Author
Rights (http://authors.acm.org/main.html).

Accepted proposals for system demonstrations will be posted on the
symposium website but not formally published in the proceedings.

Publication date: The official publication date of accepted papers is
the date the proceedings are made available in the ACM Digital
Library. This date may be up to two weeks prior to the first day of the
conference. The official publication date affects the deadline for any
patent filings related to published work.

Artifacts
=========

Authors of accepted papers are encouraged to make auxiliary material (artifacts
like source code, test data, etc.) available with their paper. They can opt to
have these artifacts published alongside their paper in the ACM Digital Library
(copyright of artifacts remains with the authors).

If an accepted paper's artifacts are made permanently available for retrieval in a
publicly accessible archival repository like the ACM Digital Library, that paper
qualifies for an Artifacts Available badge
(https://www.acm.org/publications/policies/artifact-review-badging#available).
Applications for such a badge can be made after paper acceptance and will be
reviewed by the PC chair.

Program Committee
=================

Arthur Azevedo de Amorim Carnegie Mellon University
Manuel Chakravarty Tweag I/O / IOHK
Jan Christiansen Flensburg University of Applied Sciences
Youyou Cong Tokyo Institute of Technology
Pierre-Evariste Dagand CNRS
Anton Ekblad Chalmers University of Technology
Jurriaan Hage Universiteit Utrecht
Graham Hutton University of Nottingham
José Pedro Magalhães Standard Chartered
Clare Martin Oxford Brookes University
Andrey Mokhov Jane Street
Shin-Cheng Mu Academia Sinica
Nikolaos Papaspyrou National Technical University of Athens
Simon Peyton Jones Microsoft Research Cambridge
Norman Ramsey Tufts University
Exequiel Rivas INRIA
Tom Schrijvers (chair) KU Leuven
Martin Sulzmann Karlsruhe University of Applied Sciences

If you have questions, please contact the chair at: tom.schrijvers at kuleuven.be<mailto:tom.schrijvers at kuleuven.be>

================================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200204/fc5fc901/attachment.html>

From olf at aatal-apotheke.de  Tue Feb  4 15:33:59 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Tue, 4 Feb 2020 16:33:59 +0100 (CET)
Subject: [Haskell-cafe] ANN:: provenience-0.1.0.0
Message-ID: <156494926.539416.1580830439247@webmail.strato.de>

Dear Haskellers, 

I just uploaded the first release of provenience to hackage [1]. 
The provenience package contains a monad transformer that lets you automatically track intermediate values and data dependencies in a computation. The philosophy behind it is that computation is done on one machine, while review of the algorithm is done by a third party. We make only minimal assumptions about the third party. Typically, we target static html as documentation format. 

The resulting data flow graph can be exported as various document formats via Pandoc. If desired, a machine-readable representation of each node is recorded as well. At my company we use provenience to generate invoices paired with Excel files out of the same Haskell application. 

The provenience Package will be presented at BOB conference [2] in Berlin end of this month. 

Regards,
Olaf

[1] https://hackage.haskell.org/package/provenience-0.1.0.0
[2] https://bobkonf.de/2020/klinke.html

From juan.casanova at ed.ac.uk  Tue Feb  4 18:58:33 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Tue, 04 Feb 2020 18:58:33 +0000
Subject: [Haskell-cafe] ListT version leveraging Traversable
In-Reply-To: <FC05D667-9D8B-4967-8791-D03E1E4E0DA6@aatal-apotheke.de>
References: <FC05D667-9D8B-4967-8791-D03E1E4E0DA6@aatal-apotheke.de>
Message-ID: <20200204185833.208314femkpi9m9w@www.staffmail.ed.ac.uk>

Quoting Olaf Klinke <olf at aatal-apotheke.de> on Mon, 3 Feb 2020 22:03:18 +0100:

> so the counterexample is only a counterexample because the ordering  
> matters for equality. If you're modelling non-determinism, you may  
> safely use the deprecated ListT knowing that the monad laws are  
> violated only due to ordering and multiplicity.

I think this is a great summary of where my confusion was and my  
conclusion on this topic. Thanks very much to both for the explanations.

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From tom at zwizwa.be  Wed Feb  5 12:56:39 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 07:56:39 -0500
Subject: [Haskell-cafe] sharing
Message-ID: <20200205125639.haitiz24nvlgpk2i@core.i>

Hi,

Is there currently a consensus on what is the best way to embed a pure
dataflow language while keeping control over value sharing?

I have a stream processing language that has a monadic interface (a ->
b -> m c) to track variable sharing so it can compile down to C or
Verilog, but I would like to create an expression interface layer on
top (s a -> s b -> s c) that still allows me to recover the underlying
monad representation to implement sharing.  I got used to writing in
monadic form but I really can't sell this to EEs...

Other than a TH or syntax frontend, unsafe tricks, or Conal's
compiling to categories which requires a plugin (I believe), is there
another way?

Cheers,

Tom

From carter.schonwald at gmail.com  Wed Feb  5 13:17:21 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 5 Feb 2020 08:17:21 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <20200205125639.haitiz24nvlgpk2i@core.i>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
Message-ID: <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>

Applicative do notation ?

Doesn’t recent ghc also have source plugins ? I’m admittedly unfamiliar
with those ?

Have you looked at how stuff like the ivory/tower edsl libraries do their
embedding?

Do you have enough examples for them to treat getting started as a “use
your cookbook” and then go from there ?

On Wed, Feb 5, 2020 at 7:57 AM Tom Schouten <tom at zwizwa.be> wrote:

> Hi,
>
> Is there currently a consensus on what is the best way to embed a pure
> dataflow language while keeping control over value sharing?
>
> I have a stream processing language that has a monadic interface (a ->
> b -> m c) to track variable sharing so it can compile down to C or
> Verilog, but I would like to create an expression interface layer on
> top (s a -> s b -> s c) that still allows me to recover the underlying
> monad representation to implement sharing.  I got used to writing in
> monadic form but I really can't sell this to EEs...
>
> Other than a TH or syntax frontend, unsafe tricks, or Conal's
> compiling to categories which requires a plugin (I believe), is there
> another way?
>
> Cheers,
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200205/f5ad0c95/attachment.html>

From tom at zwizwa.be  Wed Feb  5 13:59:58 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 08:59:58 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
Message-ID: <522a7c88-3fc6-2905-2766-1a4d89aca182@zwizwa.be>


On 2/5/20 8:17 AM, Carter Schonwald wrote:
> Applicative do notation ?

Probably not. See below.


>
> Doesn’t recent ghc also have source plugins ? I’m admittedly 
> unfamiliar with those ?
>
> Have you looked at how stuff like the ivory/tower edsl libraries do 
> their embedding?
>
I'm unaware of these. Thanks for the pointer.


> Do you have enough examples for them to treat getting started as a 
> “use your cookbook” and then go from there ?

Haskell is already a stretch. Doing things like this:

a <- (b `and`) =<< not c

Is just never going to work.

Keeping it in ANF:

nc <- not c

a <- b `and` nc

Is easier to explain, but it is very hard to justify why you can only 
put the result of a single operation in a variable, and why sometimes it 
is "let" and other times it is that arrow.

Basically I'm asking people to give up expressions while they work just 
fine in C or Verilog. It's a step down. I really don't blame them.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200205/61687f5b/attachment.html>

From tom at zwizwa.be  Wed Feb  5 15:37:10 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 10:37:10 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
Message-ID: <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>


On 2/5/20 8:17 AM, Carter Schonwald wrote:
>
> Have you looked at how stuff like the ivory/tower edsl libraries do 
> their embedding?
>
That is a nice project! Thanks for pointing it out.

For Ivory, the embedding is monadic so not any different in that 
respect, and this is also much more expressive than what I need.


I guess I don't know what exactly I don't know...

I'm doing something quite straightforward. Basically I know that the 
language I'm embedding only has pure functions mapping pairs of 
sequences to pairs of sequences with the restriction that the mapping is 
causal when you look at individual elements in a stream, but I dont' 
think this fact is even observable after abstracting to streams.

Keeping track of the sharing information necessary to be able to compile 
it to an external target introduces an effect.  But this is the _only_ 
effect, and it is an implementation detail that makes me loose all the 
nice properties of pure functions.  That just feels wrong.  I'm sure I'm 
missing something.

I believe the core issue is that I'm not understanding something quite 
fundamental. Why is it so hard to recover sharing information if the 
thing that is embedded is pure? I suspect the answer is something 
something referential transparency but how exactly?


This is what I sort of understand:

- Compiling to categories fixes the problem completely using a big gun: 
abstracting over function abstraction and application. It's great, but 
can't be done in Haskell as is.  This is probably the cleanest solution. 
I suspect this also has the answer to my question above but I don't 
quite see it.

- There is another Functional HDL that solves this using some unsafe 
reference trick to keep track of the sharing. I believe it is CλaSH but 
I'm not sure. I believe you can get away with this because the semantics 
is pure so in practice doesn't cause any inconsistencies, but it really 
doesn't sound like something I would do without some kind of proof that 
it is actually ok. If it is ok, it would probably make sense to abstract 
this in a library. Maybe someone has done that already?

- You can try to recover sharing later by doing common subexpression 
elimination. This works but has complexity issues and doesn't scale to 
large systems.

- Maybe it is possible to hide the compiler using existential types. I 
tried something along these lines but I couldn't figure it out so I 
don't know if it's just lack of insight or just impossible. Probably the 
latter.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200205/a7570885/attachment.html>

From carter.schonwald at gmail.com  Wed Feb  5 15:39:23 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 5 Feb 2020 10:39:23 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>
Message-ID: <CAHYVw0wwiHwdkmMkcU=v09b6iON4HXrHq-1dzPCmX92nwfNTZw@mail.gmail.com>

Try using clash, its its own thing, and overanalysis might be more
challenging than just trying it out

On Wed, Feb 5, 2020 at 10:37 AM Tom Schouten <tom at zwizwa.be> wrote:

>
> On 2/5/20 8:17 AM, Carter Schonwald wrote:
>
>
> Have you looked at how stuff like the ivory/tower edsl libraries do their
> embedding?
>
> That is a nice project! Thanks for pointing it out.
>
> For Ivory, the embedding is monadic so not any different in that respect,
> and this is also much more expressive than what I need.
>
>
> I guess I don't know what exactly I don't know...
>
> I'm doing something quite straightforward. Basically I know that the
> language I'm embedding only has pure functions mapping pairs of sequences
> to pairs of sequences with the restriction that the mapping is causal when
> you look at individual elements in a stream, but I dont' think this fact is
> even observable after abstracting to streams.
>
> Keeping track of the sharing information necessary to be able to compile
> it to an external target introduces an effect.  But this is the _only_
> effect, and it is an implementation detail that makes me loose all the nice
> properties of pure functions.  That just feels wrong.  I'm sure I'm missing
> something.
>
> I believe the core issue is that I'm not understanding something quite
> fundamental. Why is it so hard to recover sharing information if the thing
> that is embedded is pure? I suspect the answer is something something
> referential transparency but how exactly?
>
>
> This is what I sort of understand:
>
> - Compiling to categories fixes the problem completely using a big gun:
> abstracting over function abstraction and application. It's great, but
> can't be done in Haskell as is.  This is probably the cleanest solution. I
> suspect this also has the answer to my question above but I don't quite see
> it.
>
> - There is another Functional HDL that solves this using some unsafe
> reference trick to keep track of the sharing. I believe it is CλaSH but I'm
> not sure. I believe you can get away with this because the semantics is
> pure so in practice doesn't cause any inconsistencies, but it really
> doesn't sound like something I would do without some kind of proof that it
> is actually ok. If it is ok, it would probably make sense to abstract this
> in a library. Maybe someone has done that already?
>
> - You can try to recover sharing later by doing common subexpression
> elimination. This works but has complexity issues and doesn't scale to
> large systems.
>
> - Maybe it is possible to hide the compiler using existential types. I
> tried something along these lines but I couldn't figure it out so I don't
> know if it's just lack of insight or just impossible. Probably the latter.
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200205/6c83822f/attachment.html>

From tom at zwizwa.be  Wed Feb  5 16:02:30 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 11:02:30 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <C5AF710D-6588-4F88-8736-46321A978E11@gmail.com>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <522a7c88-3fc6-2905-2766-1a4d89aca182@zwizwa.be>
 <C5AF710D-6588-4F88-8736-46321A978E11@gmail.com>
Message-ID: <061536f2-eac1-dd67-c67e-c436a6f0743e@zwizwa.be>

(Reply from Sebastiaan Joosten)

I've tried something similar before but ran into a lot of cases where 
verbose intermediate type annotations where necessary to resolve 
double-wrapping ambiguities because the monad is abstract in my case:

xor :: DSL m r => r S -> r S -> m (r S))

Where r is representation wrapper, m is the associated 
compiler/interpreter, and S is a phantom tag.



On 2/5/20 10:05 AM, Sebastiaan Joosten wrote:
> Hi Tom,
>
> It wasn't entirely clear to me what you're looking for, so I'm 
> probably way off here
>
>> On 5 Feb 2020, at 08:59, Tom Schouten <tom at zwizwa.be 
>> <mailto:tom at zwizwa.be>> wrote:
>>
>> asking people to give up expressions while they work just fine in C 
>> or Verilog
>
> If all you care about is writing hardware expressions, how about 
> providing a handful of self-lifting operators? Below is an example of 
> what I mean (you'd replace the list applicative with your own 
> applicative). I'm freely combining pureed and unpureed Booleans in the 
> 'test' example, which would presumably be what your EE's write (I've 
> only given them a single self-lifting operator, so they're still stuck 
> writing pretty boring code). Does this help?
>
> Best,
> Sebastiaan
>
> PS: I'm not replying to haskell-cafe only because my mails bounce 
> there due to a technical issue that's entirely on my side, feel free 
> to add this back onto the haskell-cafe thread
>
> {-# LANGUAGE FlexibleInstances, FlexibleContexts, 
> MultiParamTypeClasses #-}
> class Pureable a b where
> maybePure :: a -> b
> instance Pureable a [a] where
> maybePure = pure
> instance Pureable [a] [a] where
> maybePure = id
> (.&&) :: (Pureable a [Bool], Pureable b [Bool])
> => a -> b -> [Bool]
> a .&& b = (&&) <$> maybePure a <*> maybePure b
> test :: [Bool] -> [Bool]
> test x = (True .&& x) .&& (False .&& x)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200205/dbcf7fc6/attachment.html>

From tom at zwizwa.be  Wed Feb  5 17:40:23 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 12:40:23 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <CAHYVw0wwiHwdkmMkcU=v09b6iON4HXrHq-1dzPCmX92nwfNTZw@mail.gmail.com>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>
 <CAHYVw0wwiHwdkmMkcU=v09b6iON4HXrHq-1dzPCmX92nwfNTZw@mail.gmail.com>
Message-ID: <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>

On 2/5/20 10:39 AM, Carter Schonwald wrote:
> Try using clash, its its own thing, and overanalysis might be more 
> challenging than just trying it out
>
Fair point.


>     - There is another Functional HDL that solves this using some
>     unsafe reference trick to keep track of the sharing. I believe it
>     is CλaSH but I'm not sure. I believe you can get away with this
>     because the semantics is pure so in practice doesn't cause any
>     inconsistencies, but it really doesn't sound like something I
>     would do without some kind of proof that it is actually ok. If it
>     is ok, it would probably make sense to abstract this in a library.
>     Maybe someone has done that already?
>
I was able to recover some information from my notes. I ran into this a 
while ago, then decided to keep the implementation simple and just use 
Monads:

A survey in Andy Gill's presentation on observable sharing:

http://www.ittc.ku.edu/~andygill/talks/20090903-hask.pdf

Just checked the Clash website and there is a link to Christiaan Baaij's 
master thesis, which has a description of the sharing problem in Appendix C:

https://essay.utwente.nl/59482/1/scriptie_C_Baaij.pdf


I think there is probably a use for a generic library that can do this 
kind of sharing recovery. Still I'm not quite happy with the "can be 
unsafe in some cases" remarks and would like to learn more. However 
there might be a tradeoff to use this as a simplified interface to 
something that is implemented in a safe monadic style under the hood.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200205/401ef440/attachment.html>

From erkokl at gmail.com  Wed Feb  5 17:53:37 2020
From: erkokl at gmail.com (Levent Erkok)
Date: Wed, 5 Feb 2020 09:53:37 -0800
Subject: [Haskell-cafe] sharing
In-Reply-To: <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>
 <CAHYVw0wwiHwdkmMkcU=v09b6iON4HXrHq-1dzPCmX92nwfNTZw@mail.gmail.com>
 <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>
Message-ID: <30D9DCBB-2808-465E-A7BC-F084D35F136D@gmail.com>

The SBV library (https://hackage.haskell.org/package/sbv <https://hackage.haskell.org/package/sbv>) uses the ideas in Andy Gill’s Observable sharing paper (http://www.ittc.ku.edu/~andygill/papers/reifyGraph.pdf <http://www.ittc.ku.edu/~andygill/papers/reifyGraph.pdf>) to safely observe sharing. Expressions remain pure, so long as “observation” of the sharing is done in the IO monad.

In my experience, this works really well and closely captures the application model: You want your users to program as if in a pure language, but the various backends (For SBV, this means C-compilation, SMTLib translation, Test-case generation etc.) already happens in a monadic framework, so it all works out rather nicely.

SBV doesn’t use Andy’s data-reify package (https://hackage.haskell.org/package/data-reify <https://hackage.haskell.org/package/data-reify>), but that’s mostly historic. I’d definitely give that package a try. But if it doesn’t work for you for whatever reason (maybe the API doesn’t quite fit), Andy’s paper is extremely well written and you can easily use his ideas to roll your own.

-Levent.

> On Feb 5, 2020, at 9:40 AM, Tom Schouten <tom at zwizwa.be> wrote:
> 
> On 2/5/20 10:39 AM, Carter Schonwald wrote:
>> Try using clash, its its own thing, and overanalysis might be more challenging than just trying it out 
>> 
> Fair point.
> 
> 
> 
>> - There is another Functional HDL that solves this using some unsafe reference trick to keep track of the sharing. I believe it is CλaSH but I'm not sure. I believe you can get away with this because the semantics is pure so in practice doesn't cause any inconsistencies, but it really doesn't sound like something I would do without some kind of proof that it is actually ok. If it is ok, it would probably make sense to abstract this in a library. Maybe someone has done that already?
>> 
> I was able to recover some information from my notes. I ran into this a while ago, then decided to keep the implementation simple and just use Monads:
> 
> A survey in Andy Gill's presentation on observable sharing:
> 
> http://www.ittc.ku.edu/~andygill/talks/20090903-hask.pdf <http://www.ittc.ku.edu/~andygill/talks/20090903-hask.pdf>
> Just checked the Clash website and there is a link to Christiaan Baaij's master thesis, which has a description of the sharing problem in Appendix C:
> 
> https://essay.utwente.nl/59482/1/scriptie_C_Baaij.pdf <https://essay.utwente.nl/59482/1/scriptie_C_Baaij.pdf>
> 
> I think there is probably a use for a generic library that can do this kind of sharing recovery. Still I'm not quite happy with the "can be unsafe in some cases" remarks and would like to learn more. However there might be a tradeoff to use this as a simplified interface to something that is implemented in a safe monadic style under the hood.
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200205/fdfbc25a/attachment.html>

From 78emil at gmail.com  Wed Feb  5 18:18:50 2020
From: 78emil at gmail.com (Emil Axelsson)
Date: Wed, 5 Feb 2020 18:18:50 +0000
Subject: [Haskell-cafe] sharing
In-Reply-To: <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>
 <CAHYVw0wwiHwdkmMkcU=v09b6iON4HXrHq-1dzPCmX92nwfNTZw@mail.gmail.com>
 <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>
Message-ID: <d9e31e22-c97a-d845-2e3a-2dd909b02ff4@gmail.com>

Den 2020-02-05 kl. 17:40, skrev Tom Schouten:
> I think there is probably a use for a generic library that can do this 
> kind of sharing recovery. Still I'm not quite happy with the "can be 
> unsafe in some cases" remarks and would like to learn more. However 
> there might be a tradeoff to use this as a simplified interface to 
> something that is implemented in a safe monadic style under the hood.

Here's the generic library that Kansas Lava uses for sharing recovery:

https://hackage.haskell.org/package/data-reify

The original Observable Sharing paper explains in more detail the 
properties of observable sharing:

https://www.researchgate.net/profile/David_Sands3/publication/225679607_Observable_Sharing_for_Functional_Circuit_Description/links/0a85e530b7beb39a9c000000.pdf

Basically, the worst thing that can happen is that you get less sharing 
(and maybe in some cases even more) than you expect because of whether 
or not GHC decides to inline something. Also, beware that overloaded 
definitions may not be shared due to the extra dictionary argument.

In practice, I've had very few surprises with observable sharing. But of 
course, the risk of unexpected duplication is not ideal when we're 
talking hardware :-)

/ Emil



From monkleyon at gmail.com  Wed Feb  5 21:29:50 2020
From: monkleyon at gmail.com (MarLinn)
Date: Wed, 5 Feb 2020 22:29:50 +0100
Subject: [Haskell-cafe] sharing
In-Reply-To: <061536f2-eac1-dd67-c67e-c436a6f0743e@zwizwa.be>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <522a7c88-3fc6-2905-2766-1a4d89aca182@zwizwa.be>
 <C5AF710D-6588-4F88-8736-46321A978E11@gmail.com>
 <061536f2-eac1-dd67-c67e-c436a6f0743e@zwizwa.be>
Message-ID: <12f0b582-719c-9b2f-d699-d8a547ac6634@gmail.com>

> I've tried something similar before but ran into a lot of cases where 
> verbose intermediate type annotations where necessary to resolve 
> double-wrapping ambiguities because the monad is abstract in my case:
>
> xor :: DSL m r => r S -> r S -> m (r S)

Do I understand correctly that the actual content of the streams is not 
important, so S is isomorphic to ()? Or are the contents abstracted away 
into a more complex type? If it's the former, I fail to see why the 
monadic interface is even necessary.

More broadly, could you provide a bigger example of what you're going 
for? I have a rough idea of what the goal is, but a more specific 
example might help.

I also feel like there might be a way to adapt Sebastiaan's idea still. 
But if there isn't yet, there is also a pry-bar lying around: 
RebindableSyntax. All of pure, return, (<*>), fmap, and (>>=) can be 
overwritten, and will be used in (applicative) do notation.

Cheers,
MarLinn


From carter.schonwald at gmail.com  Wed Feb  5 22:06:34 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 5 Feb 2020 17:06:34 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>
 <CAHYVw0wwiHwdkmMkcU=v09b6iON4HXrHq-1dzPCmX92nwfNTZw@mail.gmail.com>
 <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>
Message-ID: <CAHYVw0xUgKSAV4fAjRrPEhh7-P7zETiXgt0xL0BBhvROGrYTXA@mail.gmail.com>

it looks like bluespec open sourced their tool chain (though its build
system is a tad confusing when i tried to build it on my mac )
https://github.com/B-Lang-org/bsc

the clash build setup process looks positively relaxing by comparison :)
On Wed, Feb 5, 2020 at 12:40 PM Tom Schouten <tom at zwizwa.be> wrote:

> On 2/5/20 10:39 AM, Carter Schonwald wrote:
>
> Try using clash, its its own thing, and overanalysis might be more
> challenging than just trying it out
>
> Fair point.
>
>
> - There is another Functional HDL that solves this using some unsafe
>> reference trick to keep track of the sharing. I believe it is CλaSH but I'm
>> not sure. I believe you can get away with this because the semantics is
>> pure so in practice doesn't cause any inconsistencies, but it really
>> doesn't sound like something I would do without some kind of proof that it
>> is actually ok. If it is ok, it would probably make sense to abstract this
>> in a library. Maybe someone has done that already?
>>
> I was able to recover some information from my notes. I ran into this a
> while ago, then decided to keep the implementation simple and just use
> Monads:
>
> A survey in Andy Gill's presentation on observable sharing:
>
> http://www.ittc.ku.edu/~andygill/talks/20090903-hask.pdf
>
> Just checked the Clash website and there is a link to Christiaan Baaij's
> master thesis, which has a description of the sharing problem in Appendix C:
>
> https://essay.utwente.nl/59482/1/scriptie_C_Baaij.pdf
>
>
> I think there is probably a use for a generic library that can do this
> kind of sharing recovery. Still I'm not quite happy with the "can be unsafe
> in some cases" remarks and would like to learn more. However there might be
> a tradeoff to use this as a simplified interface to something that is
> implemented in a safe monadic style under the hood.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200205/45dfc461/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Feb  5 22:35:21 2020
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 5 Feb 2020 22:35:21 +0000
Subject: [Haskell-cafe] sharing
In-Reply-To: <20200205125639.haitiz24nvlgpk2i@core.i>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
Message-ID: <20200205223521.GB11859@weber>

On Wed, Feb 05, 2020 at 07:56:39AM -0500, Tom Schouten wrote:
> Is there currently a consensus on what is the best way to embed a pure
> dataflow language while keeping control over value sharing?

Have you looked into how Edward Kmett's AD package does observable
sharing?  Observable sharing is particularly important for reverse
mode AD.

-- For this form of reverse-mode AD we use 'System.Mem.StableName.StableName' to recover
-- sharing information from the tape to avoid combinatorial explosion, and thus
-- run asymptotically faster than it could without such sharing information, but the use
-- of side-effects contained herein is benign.

https://github.com/ekmett/ad/blob/c3d9599030f7e4793896013c69ab6b19ce403906/src/Numeric/AD/Internal/Kahn.hs

Tom

From tom at zwizwa.be  Thu Feb  6 01:07:10 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 20:07:10 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <12f0b582-719c-9b2f-d699-d8a547ac6634@gmail.com>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <522a7c88-3fc6-2905-2766-1a4d89aca182@zwizwa.be>
 <C5AF710D-6588-4F88-8736-46321A978E11@gmail.com>
 <061536f2-eac1-dd67-c67e-c436a6f0743e@zwizwa.be>
 <12f0b582-719c-9b2f-d699-d8a547ac6634@gmail.com>
Message-ID: <aeb85d7e-9a7f-dbe1-29bd-014e20965c9e@zwizwa.be>

On 2/5/20 4:29 PM, MarLinn wrote:
>> I've tried something similar before but ran into a lot of cases where 
>> verbose intermediate type annotations where necessary to resolve 
>> double-wrapping ambiguities because the monad is abstract in my case:
>>
>> xor :: DSL m r => r S -> r S -> m (r S)
>
> Do I understand correctly that the actual content of the streams is 
> not important, so S is isomorphic to ()? Or are the contents 
> abstracted away into a more complex type? If it's the former, I fail 
> to see why the monadic interface is even necessary.

Currently S is a fixed type representing the scalar value of the signal 
type. Not very important, but there will be more than one (think float, 
int, complex float, matrix, ...).

The eventual goal is to create a number of primitives that are fairly 
independent of substrate (code for CPU or DSP, Parallel logic, bitserial 
logic, time-sliced programmable datapath, ...), but before all of that 
I'm trying to get the composition mechanism right first, then later 
extend with some base types and encode bit size in types etc.

This is mostly from the Tagless-Final papers and examples.  I like that 
approach and it makes it straightforward for me to change the language 
later.


>
> More broadly, could you provide a bigger example of what you're going 
> for? I have a rough idea of what the goal is, but a more specific 
> example might help.
>
I can point to the code. This needs a lot of work, but here is the main 
class:

https://github.com/zwizwa/asm_tools/blob/master/asm-tools-seq/Language/Seq.hs

You can interpret a program written in Seq as a stateful sequential 
logic circuit where the m hides all the registers, or as an operator on 
streams.


And here are two instances: compiler and interpreter:

https://github.com/zwizwa/asm_tools/blob/master/asm-tools-seq/Language/Seq/Term.hs

https://github.com/zwizwa/asm_tools/blob/master/asm-tools-seq/Language/Seq/Emu.hs

Logic library:

https://github.com/zwizwa/asm_tools/blob/master/asm-tools-seq/Language/Seq/Lib.hs

A circuit for a small CPU:

https://github.com/zwizwa/asm_tools/blob/master/asm-tools-seq/Language/Seq/CPU.hs


> I also feel like there might be a way to adapt Sebastiaan's idea 
> still. But if there isn't yet, there is also a pry-bar lying around: 
> RebindableSyntax. All of pure, return, (<*>), fmap, and (>>=) can be 
> overwritten, and will be used in (applicative) do notation.

Thanks I was unaware of that.



From tom at zwizwa.be  Thu Feb  6 01:09:22 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 20:09:22 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <20200205223521.GB11859@weber>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <20200205223521.GB11859@weber>
Message-ID: <3c4150c4-12b2-78a0-d265-70a971a81007@zwizwa.be>

On 2/5/20 5:35 PM, Tom Ellis wrote:
> On Wed, Feb 05, 2020 at 07:56:39AM -0500, Tom Schouten wrote:
>> Is there currently a consensus on what is the best way to embed a pure
>> dataflow language while keeping control over value sharing?
> Have you looked into how Edward Kmett's AD package does observable
> sharing?  Observable sharing is particularly important for reverse
> mode AD.
>
> -- For this form of reverse-mode AD we use 'System.Mem.StableName.StableName' to recover
> -- sharing information from the tape to avoid combinatorial explosion, and thus
> -- run asymptotically faster than it could without such sharing information, but the use
> -- of side-effects contained herein is benign.
>
> https://github.com/ekmett/ad/blob/c3d9599030f7e4793896013c69ab6b19ce403906/src/Numeric/AD/Internal/Kahn.hs

No, and thanks!

Getting many great responses. Will have to chew on this for a bit.




From tom at zwizwa.be  Thu Feb  6 01:15:58 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 20:15:58 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <d9e31e22-c97a-d845-2e3a-2dd909b02ff4@gmail.com>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>
 <CAHYVw0wwiHwdkmMkcU=v09b6iON4HXrHq-1dzPCmX92nwfNTZw@mail.gmail.com>
 <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>
 <d9e31e22-c97a-d845-2e3a-2dd909b02ff4@gmail.com>
Message-ID: <edd77db3-a183-f758-eddf-2aa072d4054f@zwizwa.be>

On 2/5/20 1:18 PM, Emil Axelsson wrote:
> Den 2020-02-05 kl. 17:40, skrev Tom Schouten:
>> I think there is probably a use for a generic library that can do 
>> this kind of sharing recovery. Still I'm not quite happy with the 
>> "can be unsafe in some cases" remarks and would like to learn more. 
>> However there might be a tradeoff to use this as a simplified 
>> interface to something that is implemented in a safe monadic style 
>> under the hood.
>
> Here's the generic library that Kansas Lava uses for sharing recovery:
>
> https://hackage.haskell.org/package/data-reify
>
> The original Observable Sharing paper explains in more detail the 
> properties of observable sharing:
>
> https://www.researchgate.net/profile/David_Sands3/publication/225679607_Observable_Sharing_for_Functional_Circuit_Description/links/0a85e530b7beb39a9c000000.pdf 
>
>
> Basically, the worst thing that can happen is that you get less 
> sharing (and maybe in some cases even more) than you expect because of 
> whether or not GHC decides to inline something. Also, beware that 
> overloaded definitions may not be shared due to the extra dictionary 
> argument.
>
> In practice, I've had very few surprises with observable sharing. But 
> of course, the risk of unexpected duplication is not ideal when we're 
> talking hardware :-)
>
> / Emil
>
Thanks

That unpredictable nature doesn't sit well with me :)



>
>


From tom at zwizwa.be  Thu Feb  6 01:16:49 2020
From: tom at zwizwa.be (Tom Schouten)
Date: Wed, 5 Feb 2020 20:16:49 -0500
Subject: [Haskell-cafe] sharing
In-Reply-To: <30D9DCBB-2808-465E-A7BC-F084D35F136D@gmail.com>
References: <20200205125639.haitiz24nvlgpk2i@core.i>
 <CAHYVw0ztgdHX-x-bWfrB96HDbFy+s3VOOb8QZkzkTpde-fTfrQ@mail.gmail.com>
 <e616231d-5e7d-5825-6d17-fc65db855d8b@zwizwa.be>
 <CAHYVw0wwiHwdkmMkcU=v09b6iON4HXrHq-1dzPCmX92nwfNTZw@mail.gmail.com>
 <d3b0f624-bbff-5e95-0ed8-3745a808e132@zwizwa.be>
 <30D9DCBB-2808-465E-A7BC-F084D35F136D@gmail.com>
Message-ID: <37637a76-f2b9-aa32-92dc-26baf4569df3@zwizwa.be>

On 2/5/20 12:53 PM, Levent Erkok wrote:
> The SBV library (https://hackage.haskell.org/package/sbv) uses the 
> ideas in Andy Gill’s Observable sharing paper 
> (http://www.ittc.ku.edu/~andygill/papers/reifyGraph.pdf) to safely 
> observe sharing. Expressions remain pure, so long as “observation” of 
> the sharing is done in the IO monad.
>
> In my experience, this works really well and closely captures the 
> application model: You want your users to program as if in a pure 
> language, but the various backends (For SBV, this means C-compilation, 
> SMTLib translation, Test-case generation etc.) already happens in a 
> monadic framework, so it all works out rather nicely.
>
This would probably fit my case also.


> SBV doesn’t use Andy’s data-reify package 
> (https://hackage.haskell.org/package/data-reify), but that’s mostly 
> historic. I’d definitely give that package a try. But if it doesn’t 
> work for you for whatever reason (maybe the API doesn’t quite fit), 
> Andy’s paper is extremely well written and you can easily use his 
> ideas to roll your own.

Thanks for the pointers!






From frederic-emmanuel.picca at synchrotron-soleil.fr  Thu Feb  6 15:30:15 2020
From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel)
Date: Thu, 6 Feb 2020 15:30:15 +0000
Subject: [Haskell-cafe] MonadThrow and Either instance
Message-ID: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>

Hello,

I try to parse a config file and extract a (Path Abs Dir) from these files

So I have a parser as defined in config-ini

So I need a function with this signature

pathAbsDir :: Text -> Either String (Path Abs Dir)
pathAbsDir t = do
  d <- try $ parseAbsDir (unpack . uncomment $ t)
  case d of
    Right v -> Right v
    Left e  -> Left (show e)

since I am using parseAbsDir wi this signature

parseAbsDir :: MonadThrow m => FilePath -> m (Path Abs Dir) 

I would like to know how to write the patAbsDir method

for now I have this error message

src/Hkl/Binoculars/Config.hs:82:8-49: error:
    • Couldn't match type ‘[Char]’ with ‘GHC.Exception.SomeException’
        arising from a use of ‘try’
    • In a stmt of a 'do' block:
        d <- try $ parseAbsDir (unpack . uncomment $ t)
      In the expression:
        do d <- try $ parseAbsDir (unpack . uncomment $ t)
           case d of
             Right v -> Right v
             Left e -> Left (show e)
      In an equation for ‘pathAbsDir’:
          pathAbsDir t
            = do d <- try $ parseAbsDir (unpack . uncomment $ t)
                 case d of
                   Right v -> Right v
                   Left e -> Left (show e)
   |
82 |   d <- try $ parseAbsDir (unpack . uncomment $ t)
   |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


I understand that the MonadThrow instance of Either is for Either Exception a

But I want (Either String a).


Cheers


Frederic

From irfon at ambienautica.com  Thu Feb  6 22:30:58 2020
From: irfon at ambienautica.com (Irfon-Kim Ahmad)
Date: Thu, 6 Feb 2020 17:30:58 -0500
Subject: [Haskell-cafe] Programming Language World Championships
In-Reply-To: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
References: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
Message-ID: <d21ccbfb-77e6-3878-502a-bcc194768685@ambienautica.com>

Okay, this is a small series of polls being unscientifically conducted 
by an individual user on Mastodon for fun, but still, Haskell is 
currently being ground into the dirt by Bash scripting, and I may lose 
all of my faith in humanity:

https://mastodon.social/@fribbledom/103610609652779434


From ky3 at atamo.com  Thu Feb  6 23:07:58 2020
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Fri, 7 Feb 2020 06:07:58 +0700
Subject: [Haskell-cafe] Programming Language World Championships
In-Reply-To: <d21ccbfb-77e6-3878-502a-bcc194768685@ambienautica.com>
References: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
 <d21ccbfb-77e6-3878-502a-bcc194768685@ambienautica.com>
Message-ID: <CAPY+ZdTbFOgDP=0AjvZpsBxZ3+dTBjSNDYb7qp3vTYeGTqaddQ@mail.gmail.com>

This being as you say, a series of polls unscientifically conducted, is
surely a success worthy enough to be avoided?

On Fri, Feb 7, 2020 at 5:31 AM Irfon-Kim Ahmad <irfon at ambienautica.com>
wrote:

> Okay, this is a small series of polls being unscientifically conducted
> by an individual user on Mastodon for fun, but still, Haskell is
> currently being ground into the dirt by Bash scripting, and I may lose
> all of my faith in humanity:
>
> https://mastodon.social/@fribbledom/103610609652779434
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-- 
-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200207/930c55a5/attachment.html>

From a.pelenitsyn at gmail.com  Thu Feb  6 23:17:21 2020
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Thu, 6 Feb 2020 18:17:21 -0500
Subject: [Haskell-cafe] Programming Language World Championships
In-Reply-To: <d21ccbfb-77e6-3878-502a-bcc194768685@ambienautica.com>
References: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
 <d21ccbfb-77e6-3878-502a-bcc194768685@ambienautica.com>
Message-ID: <CAPKAvQXtXf56OUEs_86E1tYDya_wOM0J5wapjBrDj4sZO42s3A@mail.gmail.com>

Hey,

No matter what I do, the Vot button on that post is inactive, and,
therefore, I can't vote. I tried to register & (even!) follow the author of
the poll.

--
Best, Artem

On Thu, 6 Feb 2020 at 17:31, Irfon-Kim Ahmad <irfon at ambienautica.com> wrote:

> Okay, this is a small series of polls being unscientifically conducted
> by an individual user on Mastodon for fun, but still, Haskell is
> currently being ground into the dirt by Bash scripting, and I may lose
> all of my faith in humanity:
>
> https://mastodon.social/@fribbledom/103610609652779434
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200206/29040e1f/attachment.html>

From krystal.maughan at gmail.com  Thu Feb  6 23:29:20 2020
From: krystal.maughan at gmail.com (Krystal Maughan)
Date: Thu, 6 Feb 2020 18:29:20 -0500
Subject: [Haskell-cafe] Programming Language World Championships
In-Reply-To: <CAPKAvQXtXf56OUEs_86E1tYDya_wOM0J5wapjBrDj4sZO42s3A@mail.gmail.com>
References: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
 <d21ccbfb-77e6-3878-502a-bcc194768685@ambienautica.com>
 <CAPKAvQXtXf56OUEs_86E1tYDya_wOM0J5wapjBrDj4sZO42s3A@mail.gmail.com>
Message-ID: <CAOrb2G4vaKce3Nduzi4Dr6QE+m9Te+SA61fSvveTTrPSvqF9EQ@mail.gmail.com>

World Championships? I thought Haskell was #1 in the Galaxy.
Galactic Language #1.




On Thu, 6 Feb 2020 at 18:17, Artem Pelenitsyn <a.pelenitsyn at gmail.com>
wrote:

> Hey,
>
> No matter what I do, the Vot button on that post is inactive, and,
> therefore, I can't vote. I tried to register & (even!) follow the author of
> the poll.
>
> --
> Best, Artem
>
> On Thu, 6 Feb 2020 at 17:31, Irfon-Kim Ahmad <irfon at ambienautica.com>
> wrote:
>
>> Okay, this is a small series of polls being unscientifically conducted
>> by an individual user on Mastodon for fun, but still, Haskell is
>> currently being ground into the dirt by Bash scripting, and I may lose
>> all of my faith in humanity:
>>
>> https://mastodon.social/@fribbledom/103610609652779434
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200206/a99554c2/attachment.html>

From ietf-dane at dukhovni.org  Fri Feb  7 01:49:35 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 6 Feb 2020 20:49:35 -0500
Subject: [Haskell-cafe] MonadThrow and Either instance
In-Reply-To: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
References: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
Message-ID: <20200207014935.GF49778@straasha.imrryr.org>

On Thu, Feb 06, 2020 at 03:30:15PM +0000, PICCA Frederic-Emmanuel wrote:

> So I need a function with this signature
> 
> pathAbsDir :: Text -> Either String (Path Abs Dir)
> pathAbsDir t = do
>   d <- try $ parseAbsDir (unpack . uncomment $ t)
>   case d of
>     Right v -> Right v
>     Left e  -> Left (show e)
> 
> since I am using parseAbsDir wi this signature
> 
> parseAbsDir :: MonadThrow m => FilePath -> m (Path Abs Dir) 
> 
> I would like to know how to write the patAbsDir method

Try (no pun intended):

    import Control.Monad.Catch.Pure (runCatch)
    import Data.Text (Text, unpack)
    import Path (Path, Abs, Dir, parseAbsDir)

    pathAbsDir :: Text -> Either String (Path Abs Dir)
    pathAbsDir t = do
        let d = runCatch $ parseAbsDir (unpack t)
        case d of
            Right v -> Right v
            Left e  -> Left $ show e

-- 
    Viktor.

From frederic-emmanuel.picca at synchrotron-soleil.fr  Fri Feb  7 06:19:07 2020
From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel)
Date: Fri, 7 Feb 2020 06:19:07 +0000
Subject: [Haskell-cafe] MonadThrow and Either instance
In-Reply-To: <20200207014935.GF49778@straasha.imrryr.org>
References: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>,
 <20200207014935.GF49778@straasha.imrryr.org>
Message-ID: <A2A20EC3B8560D408356CAC2FC148E53018BDD2C28@SUN-DAG3.synchrotron-soleil.fr>

Thans a lot Viktor, it works

I did not know about  runCatch.

I should try these kind of runXXX on hoogle.

have a nice day

Frederic

From ietf-dane at dukhovni.org  Fri Feb  7 10:27:08 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 7 Feb 2020 05:27:08 -0500
Subject: [Haskell-cafe] MonadThrow and Either instance
In-Reply-To: <A2A20EC3B8560D408356CAC2FC148E53018BDD2C28@SUN-DAG3.synchrotron-soleil.fr>
References: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
 <20200207014935.GF49778@straasha.imrryr.org>
 <A2A20EC3B8560D408356CAC2FC148E53018BDD2C28@SUN-DAG3.synchrotron-soleil.fr>
Message-ID: <2677A064-72AF-42F3-8D3F-646EC1841236@dukhovni.org>

> On Feb 7, 2020, at 1:19 AM, PICCA Frederic-Emmanuel <frederic-emmanuel.picca at synchrotron-soleil.fr> wrote:
> 
> I did not know about  runCatch.
> I should try these kind of runXXX on hoogle.


FWIW, I did not find it on Hoogle.  Rather I looked at the
documentation of MonadCatch, noting the only instance that
wrapped a generic Monad that didn't already have MonadCatch
was 'CatchT m a'.

That led naturally to 'Catch = CatchT identity' and
'runCatch'.

Finding it through ad-hoc searches would have been much
harder...

-- 
	Viktor.


From strake888 at gmail.com  Fri Feb  7 17:55:37 2020
From: strake888 at gmail.com (Matthew Farkas-Dyck)
Date: Fri, 7 Feb 2020 09:55:37 -0800
Subject: [Haskell-cafe] Seeking help to generalize this ..
In-Reply-To: <87blqi3qv6.fsf@jackkelly.name>
References: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
 <CAEndGgTurC1a_sx7015qEgyg9VR+i7Q6jv3jw7dfe3=iDMu9hQ@mail.gmail.com>
 <87blqi3qv6.fsf@jackkelly.name>
Message-ID: <CAL3m8eAAFUZcZ_NdkPrGwagzN2NrNo8HLhi+-A7T39nnSXPtxQ@mail.gmail.com>

On 2/1/20, Jack Kelly <jack at jackkelly.name> wrote:
> In Data.Monoid there is the 'Endo' newtype, which wraps functions of
> type 'a -> a'. Is there an 'EndoM' variant, or is that something that's
> usually created by putting other pieces together? Below is a sketch of
> what I mean:
>
> -- Maybe this is known by another name?
> newtype EndoM f a = EndoM { appEndoM :: a -> f a }

I define a general `Endo` type in the category package, here:
http://hackage.haskell.org/package/category-0.2.5.0/docs/Data-Morphism-Endo.html

Thus one can use `Endo (Kleisli m)`.

From ghosh.debasish at gmail.com  Fri Feb  7 18:17:52 2020
From: ghosh.debasish at gmail.com (Debasish Ghosh)
Date: Fri, 7 Feb 2020 23:47:52 +0530
Subject: [Haskell-cafe] Seeking help to generalize this ..
In-Reply-To: <CAL3m8eAAFUZcZ_NdkPrGwagzN2NrNo8HLhi+-A7T39nnSXPtxQ@mail.gmail.com>
References: <CAE7GCT7MhwuZk112K4dc-zMaP5HXJKrTviJcbA4+tff1XCp8gg@mail.gmail.com>
 <CAEndGgTurC1a_sx7015qEgyg9VR+i7Q6jv3jw7dfe3=iDMu9hQ@mail.gmail.com>
 <87blqi3qv6.fsf@jackkelly.name>
 <CAL3m8eAAFUZcZ_NdkPrGwagzN2NrNo8HLhi+-A7T39nnSXPtxQ@mail.gmail.com>
Message-ID: <CAE7GCT7Y7u6eGYrzF91bCpfSLwe59q8sm8jreBmCr-jB33tiJg@mail.gmail.com>

I finally ended up defining a combinator

flattenAndCompose :: (Category cat) => [cat a a] -> cat a a
flattenAndCompose = foldr (>>>) id

that can be used both for function composition and Kleislis since both (->)
and Kleisli are instances of Category. I will take a look at Endo - thanks
for the pointer ..

regards.



On Fri, Feb 7, 2020 at 11:26 PM Matthew Farkas-Dyck <strake888 at gmail.com>
wrote:

> On 2/1/20, Jack Kelly <jack at jackkelly.name> wrote:
> > In Data.Monoid there is the 'Endo' newtype, which wraps functions of
> > type 'a -> a'. Is there an 'EndoM' variant, or is that something that's
> > usually created by putting other pieces together? Below is a sketch of
> > what I mean:
> >
> > -- Maybe this is known by another name?
> > newtype EndoM f a = EndoM { appEndoM :: a -> f a }
>
> I define a general `Endo` type in the category package, here:
>
> http://hackage.haskell.org/package/category-0.2.5.0/docs/Data-Morphism-Endo.html
>
> Thus one can use `Endo (Kleisli m)`.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Debasish Ghosh
http://manning.com/ghosh2
http://manning.com/ghosh

Twttr: @debasishg
Blog: http://debasishg.blogspot.com
Code: http://github.com/debasishg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200207/503d5ca1/attachment.html>

From tdammers at gmail.com  Sat Feb  8 13:03:12 2020
From: tdammers at gmail.com (Tobias Dammers)
Date: Sat, 8 Feb 2020 14:03:12 +0100
Subject: [Haskell-cafe] Programming Language World Championships
In-Reply-To: <CAOrb2G4vaKce3Nduzi4Dr6QE+m9Te+SA61fSvveTTrPSvqF9EQ@mail.gmail.com>
References: <A2A20EC3B8560D408356CAC2FC148E53018BDD29D7@SUN-DAG3.synchrotron-soleil.fr>
 <d21ccbfb-77e6-3878-502a-bcc194768685@ambienautica.com>
 <CAPKAvQXtXf56OUEs_86E1tYDya_wOM0J5wapjBrDj4sZO42s3A@mail.gmail.com>
 <CAOrb2G4vaKce3Nduzi4Dr6QE+m9Te+SA61fSvveTTrPSvqF9EQ@mail.gmail.com>
Message-ID: <CAK_X-eNSrJn94aJ=BJEYka4J-7Wwomsbrbd7jDXjXzHx+iKpYg@mail.gmail.com>

The fact that PHP is not only still a thing, but actually enjoys massive
popularity, should be enough to destroy any and all faith in humanity
already. You don't need unscientific surveys to help with that.

On Fri, Feb 7, 2020, 00:31 Krystal Maughan <krystal.maughan at gmail.com>
wrote:

> World Championships? I thought Haskell was #1 in the Galaxy.
> Galactic Language #1.
>
>
>
>
> On Thu, 6 Feb 2020 at 18:17, Artem Pelenitsyn <a.pelenitsyn at gmail.com>
> wrote:
>
>> Hey,
>>
>> No matter what I do, the Vot button on that post is inactive, and,
>> therefore, I can't vote. I tried to register & (even!) follow the author of
>> the poll.
>>
>> --
>> Best, Artem
>>
>> On Thu, 6 Feb 2020 at 17:31, Irfon-Kim Ahmad <irfon at ambienautica.com>
>> wrote:
>>
>>> Okay, this is a small series of polls being unscientifically conducted
>>> by an individual user on Mastodon for fun, but still, Haskell is
>>> currently being ground into the dirt by Bash scripting, and I may lose
>>> all of my faith in humanity:
>>>
>>> https://mastodon.social/@fribbledom/103610609652779434
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200208/4ff79d43/attachment.html>

From mjt464 at gmail.com  Sat Feb  8 23:20:27 2020
From: mjt464 at gmail.com (mike thomas)
Date: Sun, 9 Feb 2020 09:20:27 +1000
Subject: [Haskell-cafe] OpenBSD stack executable
Message-ID: <CAFh3CN3X43d6d5F4cBfCSSk45OY_eSXO9RXDOUL3B1FBLAmNWg@mail.gmail.com>

Hi there.

I want to use stack on OpenBSD 6.6.

In the absence of an official executable, I've been looking for
instructions on how to bootstrap stack *without* a preexisting stack
executable, with no luck.

I've got GHC 8.6.4, Cabal 2.4.0 and Happy 1.19.5.

Any thoughts?

Cheers

Mike Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200209/f3770b2e/attachment.html>

From vamchale at gmail.com  Sun Feb  9 00:25:52 2020
From: vamchale at gmail.com (Vanessa McHale)
Date: Sat, 8 Feb 2020 18:25:52 -0600
Subject: [Haskell-cafe] OpenBSD stack executable
In-Reply-To: <CAFh3CN3X43d6d5F4cBfCSSk45OY_eSXO9RXDOUL3B1FBLAmNWg@mail.gmail.com>
References: <CAFh3CN3X43d6d5F4cBfCSSk45OY_eSXO9RXDOUL3B1FBLAmNWg@mail.gmail.com>
Message-ID: <d1deffa7-1995-5fcd-7510-3d7d8645fbc8@gmail.com>

I compiled stack using cabal awhile back (on a raspberry pi :p)

Hopefully you can use cabal new-build after cloning the git repo for
stack? You might have to install alex or c2hs or the like, but that's
not bad with cabal-install 2.4+

Cheers,
Vanessa McHale

On 2/8/20 5:20 PM, mike thomas wrote:
> Hi there.
>
> I want to use stack on OpenBSD 6.6.  
>
> In the absence of an official executable, I've been looking for
> instructions on how to bootstrap stack _without_ a preexisting stack
> executable, with no luck.
>
> I've got GHC 8.6.4, Cabal 2.4.0 and Happy 1.19.5.
>
> Any thoughts?
>
> Cheers
>
> Mike Thomas
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200208/d0392afe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200208/d0392afe/attachment.sig>

From ml-haskell-cafe at drewhess.com  Tue Feb 11 09:11:13 2020
From: ml-haskell-cafe at drewhess.com (Drew Hess)
Date: Tue, 11 Feb 2020 09:11:13 +0000
Subject: [Haskell-cafe] [Job] Hackworth are hiring a Haskell developer,
 full time, on-site in London
Message-ID: <5C926F4A-5F7B-41BB-83C6-8FCED160BA85@drewhess.com>

[Hi Haskellers! Apologies if you’ve already seen this on Reddit or Hacker News.]

Hackworth are hiring a full-time Haskell developer in London. This is an on-site role, at our office in Shoreditch.

Salary range: £70,000-£80,000 per year

In this role, you'll help lead the research phase of our first product: a programming language optimized for learning to program, rooted in functional programming concepts, with a particular focus on the visualization of program execution. You'll be responsible for designing several prototype languages, exploring the programming language and computer education research literature for ideas, and explaining these designs and their trade-offs to your colleagues.

Once the research phase concludes, you'll help lead the development phase of the product, the result of which will be a novel interactive programming environment for children. We're targeting the end of 2021 for initial beta testing with schools and external organizations.

We expect to open-source the product at some point during the development phase. You'll have the option of leading that open source effort, if you wish.

This role does not include any on-call, devops, or customer support requirements. You'll be focused exclusively on writing Haskell and creating an innovative programming environment for kids.

For more information, please see the full job posting on our website: https://www.hackworthltd.uk/jobs/20200204/.

## Tech

Our software stack is entirely Haskell and Nix. We use macOS on the desktop, and NixOS and AWS everywhere else. If you prefer Linux on your desktop, we can probably arrange that.

## About us

Hackworth Ltd is a well-financed, bootstrapped, private limited company based in London. Our purpose is to make programming relevant to the interests of children of all backgrounds.

We're committed to building a sustainable, ethical, socially responsible business. We serve children and schools; therefore, we’ll never fund our business by selling ad placements or exploiting compulsion loops via loot boxes or micro-transactions. See here for more: https://www.hackworthltd.uk/about/

## Applying

To apply for this role, you should meet the following requirements:

* The equivalent of (approximately) 2 years' experience writing Haskell, in either an industrial or research setting. It need not have been all at one organization, nor one contiguous block of time.

* You can be on-site at our London office at least 4 days per week.

* You're eligible to work in the United Kingdom.

If you're familiar with any of the following topics, that's a definite plus, and you should mention it in your application; but please note that these are not required for the role:

* Dependent types

* Gradual typing

* Refinement types

* Total functional programming

* Program synthesis

* Structured editing a la Hazel or similar

* Block-based programming (e.g., Scratch)

* Virtual machines designed for functional languages, e.g., Landin's SECD.
  
## To apply

To apply for this role, please submit a resume/CV to careers at hackworthltd.com. Even if you’re unsure about your fit, or if you have any additional questions about the role, or about working at Hackworth in general, please get in touch!

Hackworth are committed to diversity. We are an equal opportunities employer and do not discriminate on the grounds of gender, sexual orientation, marital or civil partner status, pregnancy or maternity, gender reassignment, race, colour, nationality, ethnic or national origin, religion or belief, disability or age.


From frederic-emmanuel.picca at synchrotron-soleil.fr  Wed Feb 12 17:20:33 2020
From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel)
Date: Wed, 12 Feb 2020 17:20:33 +0000
Subject: [Haskell-cafe] help designing a function
Message-ID: <A2A20EC3B8560D408356CAC2FC148E53018BDD4199@SUN-DAG3.synchrotron-soleil.fr>

Hello,

I try to write a software, which takes a stack of images and produce a data cube.
Depending on the user input obtain via an .ini file, these cube are computed from different kind of projection.

For now I have only two projection QxQyQzProjection and HklProjection.
I prepare the InputXXX for the processXXX functions from the BinocularConfiguration and a function (InputType -> a)

mkInputQxQyQz :: FramesQxQyQzP a => BinocularsConfig -> (InputType -> a) -> IO (InputQxQyQz a)
processQxQyQz :: FramesQxQyQzP a => InputQxQyQz a -> IO ()

mkInputHkl :: FramesHklP a => BinocularsConfig -> (InputType -> a) -> IO (InputHkl a b)
processHkl :: FramesHklP a => InputHkl a b -> IO ()

now I want to write this kind of function, which use the right Projection depending on the type find in the BinocularsConfig

processProjection :: Show a => BinocularsConfig -> (InputType -> a) -> IO ()
processProjection c' f = do
  print c'
  case  (ptype . bProjection $ c') of
    QxQyQzProjection -> do
      i <- mkInputQxQyQz c' f
      print i
      processQxQyQz i
    HklProjection -> do
      i <- mkInputHkl c' f
      print i
      processHkl i
  return ()

Indeed when I compile this code, I have an Error explaining that a FramesHklP a  constrain is missing from the processProjection function.
and idem for the FramesQxQyQzP. so I can add both constrains, but in that case I need to implement the two interfaces for each type a.

Indeed this is wrong the `a` is for a specific projection thus I can not create an instance for each kind of Projection.

I do not know If I am clear, but I do not know how to organise my code in order to be able to write this processProjection method.

any help would be appreciate.

thanks 

Frederic

From tomas_jose_gallegos at protonmail.com  Wed Feb 12 23:48:27 2020
From: tomas_jose_gallegos at protonmail.com (tomas jose gallegos)
Date: Wed, 12 Feb 2020 23:48:27 +0000
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
Message-ID: <_5h4RxK-uhgT1LTF7qDquw7F6Bh2P3mAe45C8NylKtB-8T1U21CItg5QzvFGmzFKb8XwglQNkUd5ESWdrFaVP6qLvEC0Ig6TivuFqjOmifU=@protonmail.com>

Hello there,
My name is Tomas Gallegos and I specialize in functional programming using Haskell. I am very interested in this Haskell job position. It would be great if we could talk to discuss this position further and maybe schedule an interview. Thank you for your time and consideration, I look forward to hearing from you.(Attached to this email is my resume).
Regards,
Tomas Gallegos

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200212/9588e43b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resume.pdf
Type: application/pdf
Size: 35295 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200212/9588e43b/attachment.pdf>

From tomasjosegallegos3 at gmail.com  Thu Feb 13 00:17:30 2020
From: tomasjosegallegos3 at gmail.com (tomas gallegos)
Date: Wed, 12 Feb 2020 17:17:30 -0700
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
Message-ID: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>

Hello there,
My name is Tomas Gallegos and I specialize in functional programming using
Haskell. I am very interested in this Haskell job position. It would be
great if we could talk to discuss this position further and maybe schedule
an interview. Thank you for your time and consideration, I look forward to
hearing from you.(Attached to this email is my resume).
Regards,
Tomas Gallegos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200212/4b1c9651/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resume.pdf
Type: application/pdf
Size: 35295 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200212/4b1c9651/attachment-0001.pdf>

From mukeshtiwari.iiitm at gmail.com  Thu Feb 13 02:11:47 2020
From: mukeshtiwari.iiitm at gmail.com (mukesh tiwari)
Date: Thu, 13 Feb 2020 13:11:47 +1100
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
In-Reply-To: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
References: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
Message-ID: <CAFHZvE_Y8Wk6zrsq9omx0e381fJ0TtF6UshJhAp5LigmCxykOg@mail.gmail.com>

All the best Tomas, but, I believe, you should directly email your
resume to the recruiter. I have not seen any announcement from
Cloudseal [1] this month. However, there is announcement from
Hackworth [2, 3], so feel free to contact them directly. Wish you all
the best.



[1] https://mail.haskell.org/pipermail/haskell-cafe/2020-February/thread.html
[2] https://mail.haskell.org/pipermail/haskell-cafe/2020-February/131906.html
[3] https://www.hackworthltd.uk/jobs/20200204/



On Thu, Feb 13, 2020 at 11:18 AM tomas gallegos
<tomasjosegallegos3 at gmail.com> wrote:
>
> Hello there,
> My name is Tomas Gallegos and I specialize in functional programming using Haskell. I am very interested in this Haskell job position. It would be great if we could talk to discuss this position further and maybe schedule an interview. Thank you for your time and consideration, I look forward to hearing from you.(Attached to this email is my resume).
> Regards,
> Tomas Gallegos
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From ky3 at atamo.com  Thu Feb 13 02:18:53 2020
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Thu, 13 Feb 2020 09:18:53 +0700
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
In-Reply-To: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
References: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
Message-ID: <CAPY+ZdTMw6oWFNX8muixQJ0zr+4YM=RHJCT+qNcb9urAY7M2jA@mail.gmail.com>

Dear tomas,

The first sentence in your resume says that you are a computer. Don’t you
want to reword that?

Best regards,

On Thu, Feb 13, 2020 at 7:18 AM tomas gallegos <tomasjosegallegos3 at gmail.com>
wrote:

> Hello there,
> My name is Tomas Gallegos and I specialize in functional programming using
> Haskell. I am very interested in this Haskell job position. It would be
> great if we could talk to discuss this position further and maybe schedule
> an interview. Thank you for your time and consideration, I look forward to
> hearing from you.(Attached to this email is my resume).
> Regards,
> Tomas Gallegos
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-- 
-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/20ed39ba/attachment.html>

From clintonmead at gmail.com  Thu Feb 13 02:26:47 2020
From: clintonmead at gmail.com (Clinton Mead)
Date: Thu, 13 Feb 2020 13:26:47 +1100
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
In-Reply-To: <CAPY+ZdTMw6oWFNX8muixQJ0zr+4YM=RHJCT+qNcb9urAY7M2jA@mail.gmail.com>
References: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
 <CAPY+ZdTMw6oWFNX8muixQJ0zr+4YM=RHJCT+qNcb9urAY7M2jA@mail.gmail.com>
Message-ID: <CAFDVgwGr8gJnPWDu0svd+g8qmbwVDQAKNx6q8yqPt35jSyfHhw@mail.gmail.com>

A self taught computer. Why would you want to reword that? That’s very
impressive!

On Thu, 13 Feb 2020 at 1:19 pm, Kim-Ee Yeoh <ky3 at atamo.com> wrote:

> Dear tomas,
>
> The first sentence in your resume says that you are a computer. Don’t you
> want to reword that?
>
> Best regards,
>
> On Thu, Feb 13, 2020 at 7:18 AM tomas gallegos <
> tomasjosegallegos3 at gmail.com> wrote:
>
>> Hello there,
>> My name is Tomas Gallegos and I specialize in functional programming
>> using Haskell. I am very interested in this Haskell job position. It would
>> be great if we could talk to discuss this position further and maybe
>> schedule an interview. Thank you for your time and consideration, I look
>> forward to hearing from you.(Attached to this email is my resume).
>> Regards,
>> Tomas Gallegos
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> --
> -- Kim-Ee
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/27ec12d8/attachment.html>

From ky3 at atamo.com  Thu Feb 13 02:32:49 2020
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Thu, 13 Feb 2020 09:32:49 +0700
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
In-Reply-To: <CAFDVgwGr8gJnPWDu0svd+g8qmbwVDQAKNx6q8yqPt35jSyfHhw@mail.gmail.com>
References: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
 <CAPY+ZdTMw6oWFNX8muixQJ0zr+4YM=RHJCT+qNcb9urAY7M2jA@mail.gmail.com>
 <CAFDVgwGr8gJnPWDu0svd+g8qmbwVDQAKNx6q8yqPt35jSyfHhw@mail.gmail.com>
Message-ID: <CAPY+ZdTgWgaiZGaSiW0QAHz2r08=w9pC1rtUkdiCnRroE8bV6A@mail.gmail.com>

It’s one thing to have created a computer that thinks it has taught itself,
for uncertain values of the last two verbs.

It’s another to identify as a machine. Why would anyone want to do that?

On Thu, Feb 13, 2020 at 9:26 AM Clinton Mead <clintonmead at gmail.com> wrote:

> A self taught computer. Why would you want to reword that? That’s very
> impressive!
>
> On Thu, 13 Feb 2020 at 1:19 pm, Kim-Ee Yeoh <ky3 at atamo.com> wrote:
>
>> Dear tomas,
>>
>> The first sentence in your resume says that you are a computer. Don’t you
>> want to reword that?
>>
>> Best regards,
>>
>> On Thu, Feb 13, 2020 at 7:18 AM tomas gallegos <
>> tomasjosegallegos3 at gmail.com> wrote:
>>
>>> Hello there,
>>> My name is Tomas Gallegos and I specialize in functional programming
>>> using Haskell. I am very interested in this Haskell job position. It would
>>> be great if we could talk to discuss this position further and maybe
>>> schedule an interview. Thank you for your time and consideration, I look
>>> forward to hearing from you.(Attached to this email is my resume).
>>> Regards,
>>> Tomas Gallegos
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>> --
>> -- Kim-Ee
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> --
-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/c994ebab/attachment.html>

From irfon at ambienautica.com  Thu Feb 13 02:47:40 2020
From: irfon at ambienautica.com (Irfon-Kim Ahmad)
Date: Wed, 12 Feb 2020 21:47:40 -0500
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
In-Reply-To: <CAPY+ZdTgWgaiZGaSiW0QAHz2r08=w9pC1rtUkdiCnRroE8bV6A@mail.gmail.com>
References: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
 <CAPY+ZdTMw6oWFNX8muixQJ0zr+4YM=RHJCT+qNcb9urAY7M2jA@mail.gmail.com>
 <CAFDVgwGr8gJnPWDu0svd+g8qmbwVDQAKNx6q8yqPt35jSyfHhw@mail.gmail.com>
 <CAPY+ZdTgWgaiZGaSiW0QAHz2r08=w9pC1rtUkdiCnRroE8bV6A@mail.gmail.com>
Message-ID: <cbe7edea-f9d4-da97-4fd5-ee9b564e9140@ambienautica.com>

Well, at the very least, if he's actually a self-taught machine, I 
imagine a lot of organizations will want to snatch him up right away.

On 2020-02-12 9:32 p.m., Kim-Ee Yeoh wrote:
> It’s one thing to have created a computer that thinks it has taught 
> itself, for uncertain values of the last two verbs.
>
> It’s another to identify as a machine. Why would anyone want to do that?
>
> On Thu, Feb 13, 2020 at 9:26 AM Clinton Mead <clintonmead at gmail.com 
> <mailto:clintonmead at gmail.com>> wrote:
>
>     A self taught computer. Why would you want to reword that? That’s
>     very impressive!
>
>     On Thu, 13 Feb 2020 at 1:19 pm, Kim-Ee Yeoh <ky3 at atamo.com
>     <mailto:ky3 at atamo.com>> wrote:
>
>         Dear tomas,
>
>         The first sentence in your resume says that you are a
>         computer. Don’t you want to reword that?
>
>         Best regards,
>
>         On Thu, Feb 13, 2020 at 7:18 AM tomas gallegos
>         <tomasjosegallegos3 at gmail.com
>         <mailto:tomasjosegallegos3 at gmail.com>> wrote:
>
>             Hello there,
>             My name is Tomas Gallegos and I specialize in functional
>             programming using Haskell. I am very interested in this
>             Haskell job position. It would be great if we could talk
>             to discuss this position further and maybe schedule an
>             interview. Thank you for your time and consideration, I
>             look forward to hearing from you.(Attached to this email
>             is my resume).
>             Regards,
>             Tomas Gallegos
>             _______________________________________________
>             Haskell-Cafe mailing list
>             To (un)subscribe, modify options or view archives go to:
>             http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>             Only members subscribed via the mailman list are allowed
>             to post.
>
>         -- 
>         -- Kim-Ee
>         _______________________________________________
>         Haskell-Cafe mailing list
>         To (un)subscribe, modify options or view archives go to:
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>         Only members subscribed via the mailman list are allowed to post.
>
> -- 
> -- Kim-Ee
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200212/5a2ef4eb/attachment.html>

From a.pelenitsyn at gmail.com  Thu Feb 13 03:27:58 2020
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Wed, 12 Feb 2020 22:27:58 -0500
Subject: [Haskell-cafe] [ANN] BNFC-meta 0.6.1 release -- embedded Happy
	parsers
Message-ID: <CAPKAvQXjxVLDLnNmm_d5hrS4ce9Gs1SN1mW5=KRQ5efWQWYc6A@mail.gmail.com>

Hello!

BNFC-meta 0.6.1 has been released.

The library [1,2] allows you to define simple parsers inside your source
files using BNF-like formalism by the way of Template Haskell. A couple of
small example applications are hosted here [3]. Details are described in
the Haskell '11 paper [4] (preprint [5]).

Compared with the previous release, support for recent GHCs is added. Also
a minor problem with spaces after closing parenthesis in pretty-printer is
fixed courtesy GitHub user @mbuszka.

[1]: http://hackage.haskell.org/package/BNFC-meta
[2]: https://github.com/ulysses4ever/BNFC-meta
[3]: https://github.com/ulysses4ever/BNFC-meta-examples
[4]: https://dl.acm.org/doi/10.1145/2096148.2034689
[5]:
http://www.cse.chalmers.se/~patrikj/papers/MetaDSL_preprint_20110325.pdf

--
Cheers, Artem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200212/e042dc73/attachment.html>

From a.pelenitsyn at gmail.com  Thu Feb 13 03:31:34 2020
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Wed, 12 Feb 2020 22:31:34 -0500
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
In-Reply-To: <cbe7edea-f9d4-da97-4fd5-ee9b564e9140@ambienautica.com>
References: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
 <CAPY+ZdTMw6oWFNX8muixQJ0zr+4YM=RHJCT+qNcb9urAY7M2jA@mail.gmail.com>
 <CAFDVgwGr8gJnPWDu0svd+g8qmbwVDQAKNx6q8yqPt35jSyfHhw@mail.gmail.com>
 <CAPY+ZdTgWgaiZGaSiW0QAHz2r08=w9pC1rtUkdiCnRroE8bV6A@mail.gmail.com>
 <cbe7edea-f9d4-da97-4fd5-ee9b564e9140@ambienautica.com>
Message-ID: <CAPKAvQX3ZTJf_FWESk0531xrrNCg07291c75X7OWrrv6dEraaA@mail.gmail.com>

People start forgetting good-old times when computers were humans...

On Wed, 12 Feb 2020 at 21:48, Irfon-Kim Ahmad <irfon at ambienautica.com>
wrote:

> Well, at the very least, if he's actually a self-taught machine, I imagine
> a lot of organizations will want to snatch him up right away.
> On 2020-02-12 9:32 p.m., Kim-Ee Yeoh wrote:
>
> It’s one thing to have created a computer that thinks it has taught
> itself, for uncertain values of the last two verbs.
>
> It’s another to identify as a machine. Why would anyone want to do that?
>
> On Thu, Feb 13, 2020 at 9:26 AM Clinton Mead <clintonmead at gmail.com>
> wrote:
>
>> A self taught computer. Why would you want to reword that? That’s very
>> impressive!
>>
>> On Thu, 13 Feb 2020 at 1:19 pm, Kim-Ee Yeoh <ky3 at atamo.com> wrote:
>>
>>> Dear tomas,
>>>
>>> The first sentence in your resume says that you are a computer. Don’t
>>> you want to reword that?
>>>
>>> Best regards,
>>>
>>> On Thu, Feb 13, 2020 at 7:18 AM tomas gallegos <
>>> tomasjosegallegos3 at gmail.com> wrote:
>>>
>>>> Hello there,
>>>> My name is Tomas Gallegos and I specialize in functional programming
>>>> using Haskell. I am very interested in this Haskell job position. It would
>>>> be great if we could talk to discuss this position further and maybe
>>>> schedule an interview. Thank you for your time and consideration, I look
>>>> forward to hearing from you.(Attached to this email is my resume).
>>>> Regards,
>>>> Tomas Gallegos
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>
>>> --
>>> -- Kim-Ee
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>> --
> -- Kim-Ee
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200212/266079d9/attachment.html>

From fumiexcel at gmail.com  Thu Feb 13 04:20:33 2020
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Thu, 13 Feb 2020 13:20:33 +0900
Subject: [Haskell-cafe] [ANN] Documentation for base-4.13.0.0 & GHC 8.8.1
Message-ID: <CAATCwUnPat3L9aVvM4NF1Ve=fN38aDJONYkayXUhmU8JTmo1=A@mail.gmail.com>

It seems unlikely that they will be uploaded to Hackage anytime soon, so I
decided to host them on my server.

http://docs.hask.moe/base-4.13.0.0/index.html

GHC 8.8.1: http://docs.hask.moe/ghc-8.8.1/index.html

Hope this helps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/653fd5c9/attachment.html>

From konn.jinro at gmail.com  Thu Feb 13 04:29:32 2020
From: konn.jinro at gmail.com (=?utf-8?B?55+z5LqV5aSn5rW3?=)
Date: Thu, 13 Feb 2020 13:29:32 +0900
Subject: [Haskell-cafe] [ANN] Documentation for base-4.13.0.0 & GHC 8.8.1
In-Reply-To: <87F1F3C4-52F1-4E37-A923-CF2FE825157B@gmail.com>
References: <CAATCwUnPat3L9aVvM4NF1Ve=fN38aDJONYkayXUhmU8JTmo1=A@mail.gmail.com>
 <87F1F3C4-52F1-4E37-A923-CF2FE825157B@gmail.com>
Message-ID: <CB087566-1308-4D87-95ED-8A060326F934@gmail.com>

Oops, sorry I've sent the question only to Fumi mistakingly.
Here I re-send to Cafe. Sorry!

> 2020/02/13 13:28、石井大海 <konn.jinro at gmail.com>のメール:
> 
> Hi,
> 
> What's the difference with documentations already distributed with GHC Users' Guide?
> 
> * https://downloads.haskell.org/~ghc/8.8.2/docs/html/ <https://downloads.haskell.org/~ghc/8.8.2/docs/html/>
> * https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/ghc-8.8.2/index.html <https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/ghc-8.8.2/index.html>
> * https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/index.html <https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/index.html>
> 
> Are they hooglable?
> 
>> 2020/02/13 13:20、Fumiaki Kinoshita <fumiexcel at gmail.com <mailto:fumiexcel at gmail.com>>のメール:
>> 
>> It seems unlikely that they will be uploaded to Hackage anytime soon, so I decided to host them on my server.
>> 
>> http://docs.hask.moe/base-4.13.0.0/index.html <http://docs.hask.moe/base-4.13.0.0/index.html>
>> 
>> GHC 8.8.1: http://docs.hask.moe/ghc-8.8.1/index.html <http://docs.hask.moe/ghc-8.8.1/index.html>
>> 
>> Hope this helps
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>> Only members subscribed via the mailman list are allowed to post.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/b81b5c29/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/b81b5c29/attachment.sig>

From mukeshtiwari.iiitm at gmail.com  Thu Feb 13 05:11:28 2020
From: mukeshtiwari.iiitm at gmail.com (mukesh tiwari)
Date: Thu, 13 Feb 2020 16:11:28 +1100
Subject: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
In-Reply-To: <CAPKAvQX3ZTJf_FWESk0531xrrNCg07291c75X7OWrrv6dEraaA@mail.gmail.com>
References: <CAJQuYhMWB=q1WNtgNSvNcwDdmx7S-kqTh3EXKuh0uDDFkwEX9w@mail.gmail.com>
 <CAPY+ZdTMw6oWFNX8muixQJ0zr+4YM=RHJCT+qNcb9urAY7M2jA@mail.gmail.com>
 <CAFDVgwGr8gJnPWDu0svd+g8qmbwVDQAKNx6q8yqPt35jSyfHhw@mail.gmail.com>
 <CAPY+ZdTgWgaiZGaSiW0QAHz2r08=w9pC1rtUkdiCnRroE8bV6A@mail.gmail.com>
 <cbe7edea-f9d4-da97-4fd5-ee9b564e9140@ambienautica.com>
 <CAPKAvQX3ZTJf_FWESk0531xrrNCg07291c75X7OWrrv6dEraaA@mail.gmail.com>
Message-ID: <CAFHZvE9rbOSND2TbuBBQGhecMd1BtnFD6Eg21THD0XFrNddD0A@mail.gmail.com>

On Thu, 13 Feb 2020 at 2:32 pm, Artem Pelenitsyn <a.pelenitsyn at gmail.com>
wrote:

> People start forgetting good-old times when computers were humans...
>

Exactly, the same thing I was going to reply, but saw your message.



>
> On Wed, 12 Feb 2020 at 21:48, Irfon-Kim Ahmad <irfon at ambienautica.com>
> wrote:
>
>> Well, at the very least, if he's actually a self-taught machine, I
>> imagine a lot of organizations will want to snatch him up right away.
>> On 2020-02-12 9:32 p.m., Kim-Ee Yeoh wrote:
>>
>> It’s one thing to have created a computer that thinks it has taught
>> itself, for uncertain values of the last two verbs.
>>
>> It’s another to identify as a machine. Why would anyone want to do that?
>>
>> On Thu, Feb 13, 2020 at 9:26 AM Clinton Mead <clintonmead at gmail.com>
>> wrote:
>>
>>> A self taught computer. Why would you want to reword that? That’s very
>>> impressive!
>>>
>>> On Thu, 13 Feb 2020 at 1:19 pm, Kim-Ee Yeoh <ky3 at atamo.com> wrote:
>>>
>>>> Dear tomas,
>>>>
>>>> The first sentence in your resume says that you are a computer. Don’t
>>>> you want to reword that?
>>>>
>>>> Best regards,
>>>>
>>>> On Thu, Feb 13, 2020 at 7:18 AM tomas gallegos <
>>>> tomasjosegallegos3 at gmail.com> wrote:
>>>>
>>>>> Hello there,
>>>>> My name is Tomas Gallegos and I specialize in functional programming
>>>>> using Haskell. I am very interested in this Haskell job position. It would
>>>>> be great if we could talk to discuss this position further and maybe
>>>>> schedule an interview. Thank you for your time and consideration, I look
>>>>> forward to hearing from you.(Attached to this email is my resume).
>>>>> Regards,
>>>>> Tomas Gallegos
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> To (un)subscribe, modify options or view archives go to:
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>> Only members subscribed via the mailman list are allowed to post.
>>>>
>>>> --
>>>> -- Kim-Ee
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>
>>> --
>> -- Kim-Ee
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/99e49bdf/attachment.html>

From fumiexcel at gmail.com  Thu Feb 13 05:35:29 2020
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Thu, 13 Feb 2020 14:35:29 +0900
Subject: [Haskell-cafe] [ANN] Documentation for base-4.13.0.0 & GHC 8.8.1
In-Reply-To: <CB087566-1308-4D87-95ED-8A060326F934@gmail.com>
References: <CAATCwUnPat3L9aVvM4NF1Ve=fN38aDJONYkayXUhmU8JTmo1=A@mail.gmail.com>
 <87F1F3C4-52F1-4E37-A923-CF2FE825157B@gmail.com>
 <CB087566-1308-4D87-95ED-8A060326F934@gmail.com>
Message-ID: <CAATCwUkLpyXCcoYdyX5xtoXgEcW2HoFPKwP7Zfg5F45JvezBSg@mail.gmail.com>

Oh I had a brainfart. I think there's no difference, thanks

2020年2月13日(木) 13:29 石井大海 <konn.jinro at gmail.com>:

> Oops, sorry I've sent the question only to Fumi mistakingly.
> Here I re-send to Cafe. Sorry!
>
> 2020/02/13 13:28、石井大海 <konn.jinro at gmail.com>のメール:
>
> Hi,
>
> What's the difference with documentations already distributed with GHC
> Users' Guide?
>
> * https://downloads.haskell.org/~ghc/8.8.2/docs/html/
> *
> https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/ghc-8.8.2/index.html
> * https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/index.html
>
> Are they hooglable?
>
> 2020/02/13 13:20、Fumiaki Kinoshita <fumiexcel at gmail.com>のメール:
>
> It seems unlikely that they will be uploaded to Hackage anytime soon, so I
> decided to host them on my server.
>
> http://docs.hask.moe/base-4.13.0.0/index.html
>
> GHC 8.8.1: http://docs.hask.moe/ghc-8.8.1/index.html
>
> Hope this helps
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/3bda1c56/attachment.html>

From byorgey at gmail.com  Thu Feb 13 11:48:02 2020
From: byorgey at gmail.com (Brent Yorgey)
Date: Thu, 13 Feb 2020 05:48:02 -0600
Subject: [Haskell-cafe] Taking over maintainership of cautious-file (or does
 anyone know of an alternative?)
Message-ID: <CAH0njdtp9ebXegtQu48mvZKuMk5YzvoWDqpeF3QgW3-N=Tcdiw@mail.gmail.com>

The cautious-file package

http://hackage.haskell.org/package/cautious-file

has not been updated by the maintainer, Robin Green, since 2013 (though
there have been a few Hackage trustee updates since then).  The linked
source repository was hosted on patch-tag.com and no longer exists.  I
tried contacting the maintainer on January 25 but have not heard back.

I hereby announce my intention to take over as maintainer of the package.
(As a side note, as far as I know my diagrams-haddock package is the only
thing on Hackage that  depends on it.)

Alternatively, if anyone knows of a different, actively maintained package
that provides similar functionality, I'd love to hear about it!

-Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/2d720bb9/attachment.html>

From jiri at jirijakes.eu  Thu Feb 13 12:10:06 2020
From: jiri at jirijakes.eu (Jiri Jakes)
Date: Thu, 13 Feb 2020 20:10:06 +0800
Subject: [Haskell-cafe] Interpreting synchronized streams (pre-IO monad
	Haskell)
Message-ID: <87imkabsdd.fsf@ed.i-did-not-set--mail-host-address--so-tickle-me>

Heλλo!

Before introduction of IO monad, first versions of Haskell used
synchronised streams [1]:

  main :: [Response] -> [Request]
 
where Response and Request were ADTs containing all possible actions
and responses:

  data Request = ReadFile Name | ... | AppendChan Name String | ...
  data Response = Success | Str String | Bn Bin | Failure ...


I wanted to write an interpreter of this representation using a
simplified version:

  import System.Environment (getArgs)

  data Response = Success | StrList [String]
  data Request = GetArgs | PutStr String

  eval :: Request -> IO Response
  eval GetArgs = StrList <$> getArgs
  eval (PutStr s) = putStrLn s >> return Success

  main' :: [Response] -> [Request]
  main' ~(StrList args : _) =
    [ GetArgs,
      PutStr (show args)
    ]

  main :: IO ()
  main = ???

I can imagine how interpreting main' could work, thanks to laziness.
However, when actually trying to implement it, I get lost. I cannot
figure out how could I read requests (result of calling main') before
having something to pass to main'. Having a look at ancient version of
GHC [2] didn't help either.

Is it actually possible without some low-level tricks? Perhaps using
mutually recursive functions? Or by converting to continuations somehow?

Thank you!

Jiri


[1] http://haskell.org/definition/haskell-report-1.0.ps.gz
[2] https://downloads.haskell.org/~ghc/0.29/ghc-0.29-src.tar.gz

From lexi.lambda at gmail.com  Thu Feb 13 12:19:17 2020
From: lexi.lambda at gmail.com (Alexis King)
Date: Thu, 13 Feb 2020 06:19:17 -0600
Subject: [Haskell-cafe] Interpreting synchronized streams (pre-IO monad
 Haskell)
In-Reply-To: <87imkabsdd.fsf@ed.i-did-not-set--mail-host-address--so-tickle-me>
References: <87imkabsdd.fsf@ed.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <8BEF295E-C5F8-4A14-91F6-C07CE686DCE3@gmail.com>

You want unsafeInterleaveIO. That will allow you to build the list of responses as a list of thunks, each of which reads a request and yields a new response when forced.

> On Feb 13, 2020, at 06:10, Jiri Jakes <jiri at jirijakes.eu> wrote:
> 
> Heλλo!
> 
> Before introduction of IO monad, first versions of Haskell used
> synchronised streams [1]:
> 
>  main :: [Response] -> [Request]
> 
> where Response and Request were ADTs containing all possible actions
> and responses:
> 
>  data Request = ReadFile Name | ... | AppendChan Name String | ...
>  data Response = Success | Str String | Bn Bin | Failure ...
> 
> 
> I wanted to write an interpreter of this representation using a
> simplified version:
> 
>  import System.Environment (getArgs)
> 
>  data Response = Success | StrList [String]
>  data Request = GetArgs | PutStr String
> 
>  eval :: Request -> IO Response
>  eval GetArgs = StrList <$> getArgs
>  eval (PutStr s) = putStrLn s >> return Success
> 
>  main' :: [Response] -> [Request]
>  main' ~(StrList args : _) =
>    [ GetArgs,
>      PutStr (show args)
>    ]
> 
>  main :: IO ()
>  main = ???
> 
> I can imagine how interpreting main' could work, thanks to laziness.
> However, when actually trying to implement it, I get lost. I cannot
> figure out how could I read requests (result of calling main') before
> having something to pass to main'. Having a look at ancient version of
> GHC [2] didn't help either.
> 
> Is it actually possible without some low-level tricks? Perhaps using
> mutually recursive functions? Or by converting to continuations somehow?
> 
> Thank you!
> 
> Jiri
> 
> 
> [1] http://haskell.org/definition/haskell-report-1.0.ps.gz
> [2] https://downloads.haskell.org/~ghc/0.29/ghc-0.29-src.tar.gz
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


From mail at nh2.me  Thu Feb 13 16:43:46 2020
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Thu, 13 Feb 2020 17:43:46 +0100
Subject: [Haskell-cafe] Taking over maintainership of cautious-file (or
 does anyone know of an alternative?)
In-Reply-To: <CAH0njdtp9ebXegtQu48mvZKuMk5YzvoWDqpeF3QgW3-N=Tcdiw@mail.gmail.com>
References: <CAH0njdtp9ebXegtQu48mvZKuMk5YzvoWDqpeF3QgW3-N=Tcdiw@mail.gmail.com>
Message-ID: <89f8c534-b4f4-3296-8b56-127f5c2bf994@nh2.me>

Tangentially, note that `cautious-file` has drawbacks:

* It is not async-exception safe and may leak file descriptors. It uses `handleToFd` without proper exception handling (`bracket`).
* It does not `fsync` the directory in which the file is, meaning that you may still experience data loss on computer crashes.

`unliftio` provides actively maintained versions of most of what `cautious-file` does, addresses those drawbacks and is well-tested against crashes:

https://hackage.haskell.org/package/unliftio-0.2.12/docs/UnliftIO-IO-File.html

For example, `writeBinaryFileDurableAtomic`.

Niklas

From byorgey at gmail.com  Thu Feb 13 22:27:16 2020
From: byorgey at gmail.com (Brent Yorgey)
Date: Thu, 13 Feb 2020 16:27:16 -0600
Subject: [Haskell-cafe] Taking over maintainership of cautious-file (or
 does anyone know of an alternative?)
In-Reply-To: <89f8c534-b4f4-3296-8b56-127f5c2bf994@nh2.me>
References: <CAH0njdtp9ebXegtQu48mvZKuMk5YzvoWDqpeF3QgW3-N=Tcdiw@mail.gmail.com>
 <89f8c534-b4f4-3296-8b56-127f5c2bf994@nh2.me>
Message-ID: <CAH0njdu_yP_PcuaSJccTH_ZivSAO1Jv-PsHJhWbAt6NhDn9+Vw@mail.gmail.com>

Perfect, thanks!  I will try switching over to use unliftio.  Assuming it
meets my needs --- and I see no reason why it won't --- I withdraw my
intention to take over cautious-file.

-Brent

On Thu, Feb 13, 2020 at 10:43 AM Niklas Hambüchen <mail at nh2.me> wrote:

> Tangentially, note that `cautious-file` has drawbacks:
>
> * It is not async-exception safe and may leak file descriptors. It uses
> `handleToFd` without proper exception handling (`bracket`).
> * It does not `fsync` the directory in which the file is, meaning that you
> may still experience data loss on computer crashes.
>
> `unliftio` provides actively maintained versions of most of what
> `cautious-file` does, addresses those drawbacks and is well-tested against
> crashes:
>
>
> https://hackage.haskell.org/package/unliftio-0.2.12/docs/UnliftIO-IO-File.html
>
> For example, `writeBinaryFileDurableAtomic`.
>
> Niklas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200213/52ae3a3f/attachment.html>

From ghosh.debasish at gmail.com  Fri Feb 14 21:08:21 2020
From: ghosh.debasish at gmail.com (Debasish Ghosh)
Date: Sat, 15 Feb 2020 02:38:21 +0530
Subject: [Haskell-cafe] Seeking help with polysemy interpreter ..
Message-ID: <CAE7GCT7x3Xz3dfpdnhhKKHhyyTVGH9J1Uf9E99Zz49LLseaNeA@mail.gmail.com>

Hello -

I have a typeclass like this ..

class (Monad m) => DB m where
    query :: Text -> m (Maybe Account)
    ...

and an instance that uses persistent and sqlite ..

instance (MonadIO m) => DB (SqlPersistT m) where
  query ano = get (AccountKey ano)
  ..

Now I want to move this to using an effect system - Polysemy ..

data DB m a where
    Query :: Text -> DB m (Maybe Account)
    ...

makeSem ''DB

which generates the functions .. I need some help figuring out the type of
the function that interpretes the above .. An initial intuition is this ..

runDB :: Member SqlPersistT r => Sem (DB ': r) a -> Sem r a
runDB = interpret $ \case
  Query ano -> get (AccountKey ano)

which doesn't compile .. errors out with ..

Couldn't match type ‘Control.Monad.Trans.Reader.ReaderT backend0 m0 (Maybe
Account)’
                 with ‘Sem r (Maybe Account)’
  Expected type: Sem r x
    Actual type: Control.Monad.Trans.Reader.ReaderT
                   backend0 m0 (Maybe Account)
• In the expression: get (AccountKey accountNo)

I think I am missing something here. The type of interpret is shown as
interpret :: (forall x (m :: * -> *). DB m x -> Sem r x) -> Sem (DB : r) a
-> Sem r a

But how do I translate the SqlPersistT part ? Any help will be appreciated.

regards.
-- 
Debasish Ghosh
http://manning.com/ghosh2
http://manning.com/ghosh

Twttr: @debasishg
Blog: http://debasishg.blogspot.com
Code: http://github.com/debasishg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200215/5383e40c/attachment.html>

From olf at aatal-apotheke.de  Fri Feb 14 23:03:54 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 15 Feb 2020 00:03:54 +0100
Subject: [Haskell-cafe] ghc runtime linker problem on i386
Message-ID: <87B9D3CA-4C97-4202-87B4-87D5871C4007@aatal-apotheke.de>

Dear Cafe,

I'm experiencing strange behaviour on an old i386 machine when interpreting Haskell code on the fly: The same code runs from GHCi and fails as compiled executable. 
It might be a GHC runtime linker problem but I'm not sure. I successfully built haskintex and IHaskell with stack 2.1.3 on that machine. Both programs are supposed to interpret Haskell code at runtime: IHaskell uses the GHC API while haskintex uses hint, which itself is a wrapper for the GHC API. Therefore I suspect the problem lies in the usage of the GHC API itself. Both programs fail at runtime with the same error:

$LIBDIR/ghc-prim-0.5.3/HSghc-prim-0.5.3.o: unknown symbol `_GLOBAL_OFFSET_TABLE_`

When adding -dynamic to the ghc-options field in the package cabal file, the error goes away. Minimal code to reproduce is below. The i386 machine has no system ghc, no cabal, no ghcup and I wiped the $HOME/.stack directory before running "stack build". On x86-64 the error does not occur regardless of the -dynamic flag. 

Should I file a bug report or is this expected behaviour? If this is a bug, who should I file the bug against?
Olaf

{-- put this as app/Main.hs in a new stack project --}
module Main where
import Language.Haskell.Interpreter -- hint

main :: IO ()
main = putStrLn =<< hintstuff

hintstuff :: IO String
hintstuff = fmap (either show show).runInterpreter $ do
    setImports ["Prelude"]
    interpret "1+2" (as :: Int)


From pea at pea.sh  Sat Feb 15 01:44:25 2020
From: pea at pea.sh (Ashlynn Anderson)
Date: Fri, 14 Feb 2020 17:44:25 -0800
Subject: [Haskell-cafe] Taking over maintainership of cautious-file (or
	does anyone know of an alternative?)
In-Reply-To: <CAH0njdtp9ebXegtQu48mvZKuMk5YzvoWDqpeF3QgW3-N=Tcdiw@mail.gmail.com>
References: <CAH0njdtp9ebXegtQu48mvZKuMk5YzvoWDqpeF3QgW3-N=Tcdiw@mail.gmail.com>
Message-ID: <F0338262-D1CE-4D10-92F1-DDE8BAF41A53@pea.sh>

I have no comment on the maintainership issue, but I do feel I should note that according to https://packdeps.haskellers.com/reverse/cautious-file there looks to be one other package that depends on it, called tbox.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200214/e2f55345/attachment.html>

From byorgey at gmail.com  Sat Feb 15 01:53:47 2020
From: byorgey at gmail.com (Brent Yorgey)
Date: Fri, 14 Feb 2020 19:53:47 -0600
Subject: [Haskell-cafe] Taking over maintainership of cautious-file (or
 does anyone know of an alternative?)
In-Reply-To: <F0338262-D1CE-4D10-92F1-DDE8BAF41A53@pea.sh>
References: <CAH0njdtp9ebXegtQu48mvZKuMk5YzvoWDqpeF3QgW3-N=Tcdiw@mail.gmail.com>
 <F0338262-D1CE-4D10-92F1-DDE8BAF41A53@pea.sh>
Message-ID: <CAH0njdsA=H+bJO8ciLKFOTGvVj=1ZPm+kja5M-WKtpw_Akm72g@mail.gmail.com>

Yes, you're right. I wasn't counting tbox since it depends on an old
version of cautious-file and hasn't been updated in 10 years, but I should
have made a more precise statement.

-Brent

On Fri, Feb 14, 2020 at 7:45 PM Ashlynn Anderson <pea at pea.sh> wrote:

> I have no comment on the maintainership issue, but I do feel I should note
> that according to https://packdeps.haskellers.com/reverse/cautious-file
> there looks to be one other package that depends on it, called
> tbox._______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200214/4b0264a0/attachment.html>

From juan.casanova at ed.ac.uk  Sun Feb 16 03:45:05 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Sun, 16 Feb 2020 03:45:05 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
Message-ID: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>

Hello all,

This stems from a Stack Overflow question that I posted a few days ago:

https://stackoverflow.com/questions/60199424/overlapping-multi-parameter-instances-and-instance-specificity/60245126#60245126

I'd like to hear either agreement or a more convincing argument as to  
why GHCi behaves the way it does in this case, since the ones at Stack  
Overflow basically told me that it does to "protect me from being too  
dumb and not understanding my own code", the way I interpret it. I  
felt that was totally against the principles of Haskell, so I thought  
there must be more.

I'm going to focus on my second example (on my own answer to the  
question) for the sake of clarity here. Consider the following code:

{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE ExistentialQuantification #-}
module ExistentialTest where

class Class1 a b where
     foo :: a -> b

instance {-# INCOHERENT #-} Monoid a => Class1 a (Either b a) where
     foo x = Right (x <> x)

instance {-# INCOHERENT #-} Monoid a => Class1 a (Either a b) where
     foo x = Left x

data Bar a = Dir a | forall b. Class1 b a => FromB b

getA :: Bar a -> a
getA (Dir a) = a
getA (FromB b) = foo b

createBar :: Bar (Either String t)
createBar = FromB "abc"

createBar2 :: Bar (Either t String)
createBar2 = FromB "def"


This code compiles, but only because of the INCOHERENT annotations. If  
you remove those, it will give overlapping instances errors on both  
createBar and createBar2.

I argue that those errors are senseless, because, while if t were  
instantiated to String then those instances would be valid, the  
functions createBar and createBar2 are by definition polymorphic, and  
the only way to make those functions work for every t is to use  
specifically one of the instances on each case. Therefore, the  
compiler should realize this, use that instance, and not complain  
about it. When using the INCOHERENT annotations it works, and uses the  
right instance on each case (because of course it would, the other  
instance is absolutely unusable in each of the cases).

The best argument that I was given on stack overflow is that allowing  
that would make it confusing because people might use those  
polymorphic functions with the specific t ~ String instantiation of  
the types and expect the behaviour to use the instance that is not  
usable in general. I find that a really poor argument. A user of the  
function need not know in general how a function internally works  
(that it uses the Class1 instance, which is not a constraint on the  
function signature), and it would be way too much for a user of the  
function to look at that code (that they should not need to look at),  
and then guess which instance it might be using, and guess wrong.  
Having GHCi protect me from that highly hypothetical situation while  
preventing me from compiling theoretically correct programs seems  
strange at best.

I have tried to think of potential situations where a similar kind of  
ambiguity might affect the actual type checking and not just what the  
user might (wrongly) think of it, but I haven't found any.

 From what I understand, though, the INCOHERENT annotation is  
dangerous in that if there were other instances which in fact did  
match in general, then GHCi would choose an arbitrary one. Therefore,  
I'd like them out of my code.

Are there any comments on this that give me a more theoretical reason  
as to why Haskell disallows this without the INCOHERENT annotations?  
Is it worth proposing a change to the compiler to allow this? It  
basically seems that the compiler is checking the overlapping  
instances "too soon" before realizing that t cannot be unified with  
String within createBar, because it is a forall quantified polymorphic  
function.

A way to see this is to precisely comment one of the instances and  
realize that you still get one error on each function, and on the one  
you removed the right instance for, it will actually say that there is  
no instance at all. It feels wrong that Haskell can tell you there are  
two instances that would match, and when you remove one of them, it  
tells you that there are no instances that match. That in of itself  
screams bug to me until someone gives me a really convincing  
explanation of why that is okay.

Thanks once again for any time you spent on this, haskell-cafe.

Juan Casanova.



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From leesteken at pm.me  Sun Feb 16 09:59:44 2020
From: leesteken at pm.me (leesteken at pm.me)
Date: Sun, 16 Feb 2020 09:59:44 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
	myself with overlapping instances and existential types
In-Reply-To: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
Message-ID: <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 16, 2020 4:45 AM, Juan Casanova <juan.casanova at ed.ac.uk> wrote:

> Hello all,
>
> This stems from a Stack Overflow question that I posted a few days ago:
>
> https://stackoverflow.com/questions/60199424/overlapping-multi-parameter-instances-and-instance-specificity/60245126#60245126
>
> I'd like to hear either agreement or a more convincing argument as to
> why GHCi behaves the way it does in this case, since the ones at Stack
> Overflow basically told me that it does to "protect me from being too
> dumb and not understanding my own code", the way I interpret it. I
> felt that was totally against the principles of Haskell, so I thought
> there must be more.
>
> I'm going to focus on my second example (on my own answer to the
> question) for the sake of clarity here. Consider the following code:
>
> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE FlexibleInstances #-}
> {-# LANGUAGE ExistentialQuantification #-}
> module ExistentialTest where
>
> class Class1 a b where
> foo :: a -> b
>
> instance {-# INCOHERENT #-} Monoid a => Class1 a (Either b a) where
>
>      foo x = Right (x <> x)
>
>
> instance {-# INCOHERENT #-} Monoid a => Class1 a (Either a b) where
>
>      foo x = Left x
>
>
> data Bar a = Dir a | forall b. Class1 b a => FromB b
>
> getA :: Bar a -> a
>
> getA (Dir a) = a
> getA (FromB b) = foo b
>
> createBar :: Bar (Either String t)
> createBar = FromB "abc"
>

I think the type checker is worried that someone will use createBar with t==String.
Suppose I define:
  f :: Bar (Either String String)
  f = createBar
or
  g :: String -> Either String String
  g x = foo x
Should the result be a 'Right ...' or a 'Left ...'? Both incoherent instances apply when a==b (==String for example), but the results are different, which means that foo is not a (pure) function.

> createBar2 :: Bar (Either t String)
> createBar2 = FromB "def"
>
> This code compiles, but only because of the INCOHERENT annotations. If
> you remove those, it will give overlapping instances errors on both
> createBar and createBar2.
>
> I argue that those errors are senseless, because, while if t were
> instantiated to String then those instances would be valid, the
> functions createBar and createBar2 are by definition polymorphic, and
> the only way to make those functions work for every t is to use
> specifically one of the instances on each case. Therefore, the
> compiler should realize this, use that instance, and not complain
> about it. When using the INCOHERENT annotations it works, and uses the
> right instance on each case (because of course it would, the other
> instance is absolutely unusable in each of the cases).
>

Okay, you did think about the case that t==String. However, I don't see why this would not be a problem, as I explained above. The two instance types for Class1/foo completely overlap when a==b and it does matter which one the compiler chooses because they are not the same (one results in a Right and the other in a Left). Without being (possibly) incoherent, which instance should the compiler choose for the function 'g' above?

> The best argument that I was given on stack overflow is that allowing
> that would make it confusing because people might use those
> polymorphic functions with the specific t ~ String instantiation of
> the types and expect the behaviour to use the instance that is not
> usable in general. I find that a really poor argument. A user of the
> function need not know in general how a function internally works
> (that it uses the Class1 instance, which is not a constraint on the
> function signature), and it would be way too much for a user of the
> function to look at that code (that they should not need to look at),
> and then guess which instance it might be using, and guess wrong.
> Having GHCi protect me from that highly hypothetical situation while
> preventing me from compiling theoretically correct programs seems
> strange at best.
>
> I have tried to think of potential situations where a similar kind of
> ambiguity might affect the actual type checking and not just what the
> user might (wrongly) think of it, but I haven't found any.
>

I think function 'g' above is an example for such a problem. If I'm wrong, please explain how the compiler/run-time should know which to choose.

> From what I understand, though, the INCOHERENT annotation is
> dangerous in that if there were other instances which in fact did
> match in general, then GHCi would choose an arbitrary one. Therefore,
> I'd like them out of my code.
>
> Are there any comments on this that give me a more theoretical reason
> as to why Haskell disallows this without the INCOHERENT annotations?
> Is it worth proposing a change to the compiler to allow this? It
> basically seems that the compiler is checking the overlapping
> instances "too soon" before realizing that t cannot be unified with
> String within createBar, because it is a forall quantified polymorphic
> function.

Maybe the compiler could realize that t cannot be unified with String in this case. I'm not sure whether the forall in that type means universal of existential quantification as Haskell uses similar notation for both.
However, the problem of someone (later, maybe in another module) defining a function like 'g' above still exists.

> A way to see this is to precisely comment one of the instances and
> realize that you still get one error on each function, and on the one
> you removed the right instance for, it will actually say that there is
> no instance at all. It feels wrong that Haskell can tell you there are
> two instances that would match, and when you remove one of them, it
> tells you that there are no instances that match. That in of itself
> screams bug to me until someone gives me a really convincing
> explanation of why that is okay.
>
> Thanks once again for any time you spent on this, haskell-cafe.
>
> Juan Casanova.

I think I agree with the compiler here and I really don't see why the overlapping instances would not be a potential problem (for a function like 'g'). Our points of view appear to be so far apart, that I'm not sure if I understood your argument correctly. Please don't take offence if I did not address your issue or made a mistake because I did not fully understand.

kind regards, Arjen

From profunctor at pm.me  Sun Feb 16 10:14:00 2020
From: profunctor at pm.me (Marcin Szamotulski)
Date: Sun, 16 Feb 2020 10:14:00 +0000
Subject: [Haskell-cafe] [ANN] zsh-haskell
Message-ID: <5FVnfW3NskAeRs0Sqdr42ospKwnY4zGElBL9eyxo8gq5rMx5of6mv_RA_tLuPWYGltz0t9TPRD1NMG6uv0VG1LGvCOZ2yh4vzDrfufKpXpU=@pm.me>

Dear fellow Haskellers,

I am pleased to announce a `zsh` completion for `cabal`, `ghc` and `ghc-pkg`.

https://github.com/coot/zsh-haskell

Cheers,
Marcin Szamotulski



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200216/b54fefea/attachment.sig>

From juan.casanova at ed.ac.uk  Sun Feb 16 14:44:21 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Sun, 16 Feb 2020 14:44:21 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
Message-ID: <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>

Arjen,

Indeed, I think the fundamental point of disagreement is whether t ~  
String is a valid potential unification or not. In general it is, but  
let me bring to you the following example that I put on the initial  
example on my Stack Overflow question:

aretheyreallyeq :: (Eq a, Eq b) => Either a b -> Either a b -> Bool
aretheyreallyeq (Left a1) (Right b2) = a1 == b2

This does not compile, and rightly so. Because a and b *need not* be  
equal, so it is not guaranteed that you will be able to use an Eq  
instance between them. In other words, within a function body, type  
variables in the definition of that function are not unifiable, they  
cannot be instantiated (within the function's body). There cannot be  
parts of the function's body whose potential outcome depends on what  
the type variables are instantiated to. Of course, and as the error  
message on my first example says itself, the thing is that it *depends  
on the instantiation of t*.

But here is the thing, and please evaluate this statement carefully  
as, if not entirely correct, it might be the entire source of the  
confusion:

A) There is no Class1 constraint on the function createBar. Therefore,  
the Class1 instance that the function uses is going to be fixed and  
will not vary on different calls of the function.

Sure, that instance may rely on other constraints of the function, for  
example. If there were other instances whose head matched but did not  
have matching constraints we would be in a different situation, and I  
understand why in those cases the overlapping errors are necessary: it  
is undecidable in general to solve the problem of transitive  
constraint satisfaction and therefore if the head matches, it is a  
potential overlap and that's the end of the story.

But that is not what happens here. The head of the constraint will  
only match if t ~ String, but then the Class1 instance used within  
createBar would need to be variable for different type instantiations  
of createBar, which contradicts the statement A). Thus, the only  
sensible thing to do is to use the only instance that matches  
regardless of the instantiation of t.


And to circle back, as I said, this comes back to the fact that if you  
remove the instance that does not depend on the instantiation of t,  
then you suddenly get a compile error that says there are *no*  
instances. So the compiler itself knows that it cannot use an instance  
that depends on the instantiation of t, but still brings it up to flag  
an overlapping instances error.

I hope that clarifies at the very least what the core of the  
disagreement is. It is quite possible that there is something I am  
overlooking, but until you provide me with an example of code that, if  
the compiler worked the way I want it to, would have an ambiguous  
instance, or an ambiguous implementation of some function at all, I'll  
still believe that the compiler is flagging up the overlapping  
instances error too soon without really checking whether they are  
really valid instances.

Thanks,
Juan.

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From leesteken at pm.me  Sun Feb 16 15:18:45 2020
From: leesteken at pm.me (leesteken at pm.me)
Date: Sun, 16 Feb 2020 15:18:45 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
	myself with overlapping instances and existential types
In-Reply-To: <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
Message-ID: <kOKW4ig3sMXaKTvmbCac3Zl0TzNPtQjdkjI4-P5JGcD32EPYr4BxiWsDsUBng0uzCgP_fds76Vcaj_HRK0jBTVGrGuJ_kxZf-lW2XZKazdY=@pm.me>

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 16, 2020 3:44 PM, Juan Casanova <juan.casanova at ed.ac.uk> wrote:

> Arjen,
>
> Indeed, I think the fundamental point of disagreement is whether t ~
> String is a valid potential unification or not. In general it is, but
> let me bring to you the following example that I put on the initial
> example on my Stack Overflow question:
>
> aretheyreallyeq :: (Eq a, Eq b) => Either a b -> Either a b -> Bool
>
> aretheyreallyeq (Left a1) (Right b2) = a1 == b2
>
> This does not compile, and rightly so. Because a and b need not be
> equal, so it is not guaranteed that you will be able to use an Eq
> instance between them. In other words, within a function body, type
> variables in the definition of that function are not unifiable, they
> cannot be instantiated (within the function's body). There cannot be
> parts of the function's body whose potential outcome depends on what
> the type variables are instantiated to. Of course, and as the error
> message on my first example says itself, the thing is that it depends
> on the instantiation of t.
>
> But here is the thing, and please evaluate this statement carefully
> as, if not entirely correct, it might be the entire source of the
> confusion:
>
> A) There is no Class1 constraint on the function createBar. Therefore,
> the Class1 instance that the function uses is going to be fixed and
> will not vary on different calls of the function.

The type 't' will be determined by the calling context of createBar, and I do not see why it could not be String.

> Sure, that instance may rely on other constraints of the function, for
> example. If there were other instances whose head matched but did not
> have matching constraints we would be in a different situation, and I
> understand why in those cases the overlapping errors are necessary: it
> is undecidable in general to solve the problem of transitive
> constraint satisfaction and therefore if the head matches, it is a
> potential overlap and that's the end of the story.

My apologies, I expected the compiler to complain about overlapping instances, even without anything other than the instance definitions. It turns out that it only starts complaining when the instances are used. I'm afraid it would appear that I don't really know how multiple-parameter classes and existential types influence the overlap checking as implemented in GHC.

> But that is not what happens here. The head of the constraint will
> only match if t ~ String, but then the Class1 instance used within
> createBar would need to be variable for different type instantiations
> of createBar, which contradicts the statement A). Thus, the only
> sensible thing to do is to use the only instance that matches
> regardless of the instantiation of t.

I would expect that the type checker, when it cannot prove something in general, takes the safe approach of disallowing it. Whether your particular use of this class in your program might be proven to be correct, I really don't know, sorry.

> And to circle back, as I said, this comes back to the fact that if you
> remove the instance that does not depend on the instantiation of t,
> then you suddenly get a compile error that says there are no
> instances. So the compiler itself knows that it cannot use an instance
> that depends on the instantiation of t, but still brings it up to flag
> an overlapping instances error.
>
> I hope that clarifies at the very least what the core of the
> disagreement is. It is quite possible that there is something I am
> overlooking, but until you provide me with an example of code that, if
> the compiler worked the way I want it to, would have an ambiguous
> instance, or an ambiguous implementation of some function at all, I'll
> still believe that the compiler is flagging up the overlapping
> instances error too soon without really checking whether they are
> really valid instances.
>

kind regards, Arjen


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sun Feb 16 15:21:04 2020
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 16 Feb 2020 15:21:04 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
Message-ID: <20200216152104.GA28643@weber>

On Sun, Feb 16, 2020 at 02:44:21PM +0000, Juan Casanova wrote:
> until you provide me with an example of code that, if the compiler
> worked the way I want it to, would have an ambiguous instance, or an
> ambiguous implementation of some function at all, I'll still believe
> that the compiler is flagging up the overlapping instances error too
> soon without really checking whether they are really valid
> instances.

Didn't Arjen already provide such an example?  Should `g "Hello"`
return a `Left` or a `Right`?

  g :: String -> Either String String
  g x = foo x

I think the difficulty may be due to the error being flagged in a
misleading way.  There's nothing wrong with your intended usage of the
type classes, individually.  The problem is that the instances both
exist in the same codebase.  The error message about overlap *appears*
at the use sites but I believe that this is an implementation detail.

The instances you have written can cause problems in *other* parts of
the codebase, perhaps completely unrelated parts that have merely
transitively imported your module through dependencies (someone may
define `g` above, for example).  Thefore the instances should not be
both allowed to exist in the same codebase.  This particular piece of
information is flagged at the use sites but perhaps should be flagged
at the instance definition sites.

Tom

From juan.casanova at ed.ac.uk  Sun Feb 16 15:39:24 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Sun, 16 Feb 2020 15:39:24 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <20200216152104.GA28643@weber>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
 <20200216152104.GA28643@weber>
Message-ID: <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>

Please keep the discussion coming. The fact that I'm not convinced  
(for now) doesn't mean I don't appreciate your answers. I wouldn't  
want to come out as hostile. I'd be very happy for you to convince me  
that I am understanding something the wrong way and learn how to do  
what I want in the right way, which is what has happened essentially  
every time I had a similar issue like this one. But until I am  
convinced please allow me to argue back.

> Didn't Arjen already provide such an example?  Should `g "Hello"`
> return a `Left` or a `Right`?
>
>   g :: String -> Either String String
>   g x = foo x
>

The g you are defining there should not compile indeed, because that  
is an ambiguous usage of foo. But that is not what I defined. And this  
relates to the rest of your reply.

> I think the difficulty may be due to the error being flagged in a
> misleading way.  There's nothing wrong with your intended usage of the
> type classes, individually.  The problem is that the instances both
> exist in the same codebase.  The error message about overlap *appears*
> at the use sites but I believe that this is an implementation detail.
>
> The instances you have written can cause problems in *other* parts of
> the codebase, perhaps completely unrelated parts that have merely
> transitively imported your module through dependencies (someone may
> define `g` above, for example).  Thefore the instances should not be
> both allowed to exist in the same codebase.  This particular piece of
> information is flagged at the use sites but perhaps should be flagged
> at the instance definition sites.

I simply do not agree with this, and I don't think (?) that GHCi  
implementors and designers agree with you either, as exemplified by  
the fact that indeed overlapping instances appear when using instances  
and not when defining them. While it doesn't clearly agree with what I  
said, the general phrasing and approach followed here:  
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#instance-overlap makes me think indeed the approach is that potentially overlapping instances are allowed so long as each of their uses are  
unambiguous.

To address your point more specifically, you worry that if potentially  
overlapping instances exist, then someone somewhere else in the  
codebase might flag up the overlapping instances error. But in order  
for someone to do so, they need to *use* an instance of the class that  
has the potentially overlapping instances. In your example, they need  
to implement g and use foo within its definition, which means that  
they are willfully utilizing a Class1 instance that they are thinking  
of. If there are potentially overlapping instances that match, then  
they need to take care that they use the one they really want.

Now, it is true that a good argument is that, for example in the g  
example you presented, it is quite hard for the implementor to  
actually indicate which instance they wish to use, since in this case  
type annotations will not do the job. This is a problem I have also  
had to deal with myself, and generally solve on a case by case basis  
with various tricks and hacks (normally involving wrapping things in  
newtypes). In my application case for this problem we are discussing  
now, the newtype wrapping would in principle work, but would make my  
code extremely more complicated due to the amount of type classes that  
use each other that I am considering here and the fact that they are  
multi-parameter type classes. All in all I am not very happy anytime  
the solution to trying to do something legitimate is "wrap everything  
up in newtypes and coerce stuff all over the place until it works". I  
think it is too rampant and clutters the code way too much.

Perhaps the fact that no tools are given in GHCi to explicitly  
indicate which instance we wish to use is an argument in favour of  
your perspective that instances should not overlap even on their  
definition? Maybe someone reading this who's more closely situated to  
the Haskell / GHCi development and design principles could throw some  
light on this? I don't feel like it is made clear on any of the  
documentation I've read, but I may have overlooked it.

Rest assured, if it is like this by design as you claim it may be, I  
would have a big amount of complaints about that as well. Things that  
are absolutely sensible to do that would be made very noticeably  
harder to do by this design decision. But it would certainly address  
this particular issue.

Juan.


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From juan.casanova at ed.ac.uk  Sun Feb 16 15:46:25 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Sun, 16 Feb 2020 15:46:25 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
 <20200216152104.GA28643@weber>
 <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
Message-ID: <20200216154625.12782xdlnihqmomc@www.staffmail.ed.ac.uk>

Upon looking more closely, this caught my eyes on the link I provided:

"Errors are reported lazily (when attempting to solve a constraint),  
rather than eagerly (when the instances themselves are defined)."

This may be an argument in favour of your notion, that any kind of  
overlap is wrong by definition and it just so happens that it only  
flags up when used. I'd still love some comment from someone with a  
bit more authority about this.

This would mean I would have to go back to wrapping everything in new  
types so that I can explicitly control what is used where and why. I  
am becoming less and less of a fan of this technique.

Juan.

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sun Feb 16 15:58:10 2020
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 16 Feb 2020 15:58:10 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
 <20200216152104.GA28643@weber>
 <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
Message-ID: <20200216155810.GA32580@weber>

On Sun, Feb 16, 2020 at 03:39:24PM +0000, Juan Casanova wrote:
> > The instances you have written can cause problems in *other* parts of
> > the codebase, perhaps completely unrelated parts that have merely
> > transitively imported your module through dependencies (someone may
> > define `g` above, for example).  Thefore the instances should not be
> > both allowed to exist in the same codebase.  This particular piece of
> > information is flagged at the use sites but perhaps should be flagged
> > at the instance definition sites.
> 
> I simply do not agree with this, and I don't think (?) that GHCi
> implementors and designers agree with you either, as exemplified by the fact
> that indeed overlapping instances appear when using instances and not when
> defining them. While it doesn't clearly agree with what I said, the general
> phrasing and approach followed here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#instance-overlap
> makes me think indeed the approach is that potentially overlapping instances
> are allowed so long as each of their uses are unambiguous.

Potentially overlapping typeclasses are most certainly *not* allowed
by default, which is why need pragmas to enable them.  Enabling them
can be dangerous and violate properties that one would otherwise
assume to hold.

> Rest assured, if it is like this by design as you claim it may be, I would
> have a big amount of complaints about that as well. Things that are
> absolutely sensible to do that would be made very noticeably harder to do by
> this design decision. But it would certainly address this particular issue.

The design is called "global typeclass coherence" and it is very
important for certain desirable properties to hold.  There are other
ways of approaching things, but this is the one chosen in Haskell.
I'm not very knowledgeable about this area but or futher information I
suggest the following resources, in approximate order of importance:

* http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/
* https://www.reddit.com/r/haskell/comments/2w4ctt/boston_haskell_edward_kmett_type_classes_vs_the/
* https://www.reddit.com/r/haskell/comments/2agy14/type_classes_confluence_coherence_global/
* https://www.reddit.com/r/haskell/comments/765ogm/multiple_type_class_instances_for_the_same_type/

I realise that your interest may be more on the theoretical side, but
to add a small codicil of practical advice I highly recommend staying
away from any clever uses of typeclasses.  Passing around first class
values is much more composable and leads to far fewer headaches.

Tom

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sun Feb 16 16:02:17 2020
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 16 Feb 2020 16:02:17 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <20200216154625.12782xdlnihqmomc@www.staffmail.ed.ac.uk>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
 <20200216152104.GA28643@weber>
 <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
 <20200216154625.12782xdlnihqmomc@www.staffmail.ed.ac.uk>
Message-ID: <20200216160217.GB32580@weber>

On Sun, Feb 16, 2020 at 03:46:25PM +0000, Juan Casanova wrote:
> This may be an argument in favour of your notion, that any kind of overlap
> is wrong by definition and it just so happens that it only flags up when
> used. I'd still love some comment from someone with a bit more authority
> about this.

This is an area where an expert language designer needs to chime in I
think and they don't tend to hang out on haskell-cafe.

If you are trying to solve a practical problem, then based on the
discussion so far I am around 90% confident that you would be better
off without using typeclasses at all.  How would your design look if
you just passed around first class values instead?

Tom

From ietf-dane at dukhovni.org  Sun Feb 16 17:27:25 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 16 Feb 2020 12:27:25 -0500
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
 <20200216152104.GA28643@weber>
 <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
Message-ID: <20200216172725.GG49778@straasha.imrryr.org>

On Sun, Feb 16, 2020 at 03:39:24PM +0000, Juan Casanova wrote:

> I simply do not agree with this, and I don't think (?) that GHCi  
> implementors and designers agree with you either, as exemplified by  
> the fact that indeed overlapping instances appear when using instances  
> and not when defining them. While it doesn't clearly agree with what I  
> said, the general phrasing and approach followed here:  
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#instance-overlap
> makes me think indeed the approach is that potentially overlapping
> instances are allowed so long as each of their uses are  
> unambiguous.

And yet the particular overlapping instances leave room for unexpected
results.  For example, if the code is specialized a bit to impose "Eq a"
and "Typeable b, Eq b" constaints on "Bar", and one implements a
heterogenous comparison function for "Bar", not quite the right thing
happens:

    {-# LANGUAGE MultiParamTypeClasses #-}
    {-# LANGUAGE FlexibleInstances #-}
    {-# LANGUAGE ExistentialQuantification #-}

    module Main (main) where
    import           Data.Typeable (Typeable, cast)

    class Class1 a b where
         foo :: a -> b
    instance {-# INCOHERENT #-} Monoid a => Class1 a (Either b a) where
         foo x = Right (x <> x)
    instance {-# INCOHERENT #-} Monoid a => Class1 a (Either a b) where
         foo x = Left x

    data Bar a = Dir a | forall b. (Typeable b, Eq b, Class1 b a) => FromB b
    instance Eq a => Eq (Bar a) where
        (Dir x) == (Dir y) = x == y
        (FromB x) == (FromB y) = case cast x of
            Just x' -> x' == y
            _       -> False
        _ == _ = False

    getA :: Bar a -> a
    getA (Dir a) = a
    getA (FromB b) = foo b

    createBar :: Eq t => Bar (Either String t)
    createBar = FromB "abc"

    createBar2 :: Eq t => Bar (Either t String)
    createBar2 = FromB "abc"

    main :: IO ()
    main = do
        let x = createBar :: Bar (Either String String)
            y = createBar2 :: Bar (Either String String)
        print $ map getA [x, y]
        print $ x == y

If your run the above, the output you get is:

    [Left "abc",Right "abcabc"]
    True

Which shows some of the trouble one can run into with incoherent
definitions.  Structurally equal terms are no longer equivalent.

-- 
    Viktor.

From juan.casanova at ed.ac.uk  Sun Feb 16 19:37:25 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Sun, 16 Feb 2020 19:37:25 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <20200216172725.GG49778@straasha.imrryr.org>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
 <20200216152104.GA28643@weber>
 <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
 <20200216172725.GG49778@straasha.imrryr.org>
Message-ID: <20200216193725.20425wip453628lw@www.staffmail.ed.ac.uk>

>     {-# LANGUAGE MultiParamTypeClasses #-}
>     {-# LANGUAGE FlexibleInstances #-}
>     {-# LANGUAGE ExistentialQuantification #-}
>
>     module Main (main) where
>     import           Data.Typeable (Typeable, cast)
>
>     class Class1 a b where
>          foo :: a -> b
>     instance {-# INCOHERENT #-} Monoid a => Class1 a (Either b a) where
>          foo x = Right (x <> x)
>     instance {-# INCOHERENT #-} Monoid a => Class1 a (Either a b) where
>          foo x = Left x
>
>     data Bar a = Dir a | forall b. (Typeable b, Eq b, Class1 b a) => FromB b
>     instance Eq a => Eq (Bar a) where
>         (Dir x) == (Dir y) = x == y
>         (FromB x) == (FromB y) = case cast x of
>             Just x' -> x' == y
>             _       -> False
>         _ == _ = False
>
>     getA :: Bar a -> a
>     getA (Dir a) = a
>     getA (FromB b) = foo b
>
>     createBar :: Eq t => Bar (Either String t)
>     createBar = FromB "abc"
>
>     createBar2 :: Eq t => Bar (Either t String)
>     createBar2 = FromB "abc"
>
>     main :: IO ()
>     main = do
>         let x = createBar :: Bar (Either String String)
>             y = createBar2 :: Bar (Either String String)
>         print $ map getA [x, y]
>         print $ x == y
>
> If your run the above, the output you get is:
>
>     [Left "abc",Right "abcabc"]
>     True

I'm not that familiar with Typeable. If I understand correctly, what  
is going on here is that by pattern-matching on the FromB constructor  
and using Typeable, you are bypassing the instance checking and  
comparing two things that should not be compared. Is this a more or  
less correct understanding?

If so, your conclusion then is that by allowing incoherent instances,  
if someone bypasses them under the hood then I might get very  
unexpected results that cannot be directly traced back to "using the  
wrong instance". Right?

This is quite a bit more convincing. The fact that I had clearly  
gotten wrong the design principles of Haskell when it comes to  
overlapping instances already got me quite convinced, but this helps  
as well. I just hate having to wrap everything in newtypes as the only  
solution out of it...

Thanks a lot for taking the time to explain this,
Juan.

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From olf at aatal-apotheke.de  Sun Feb 16 20:27:47 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sun, 16 Feb 2020 21:27:47 +0100
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
	myself with overlapping instances and existential types
Message-ID: <0E99630D-212F-40FA-B0E5-64F11F0E4C13@aatal-apotheke.de>

> the ones at Stack  
> Overflow basically told me that it does to "protect me from being too  
> dumb and not understanding my own code", the way I interpret it. I  
> felt that was totally against the principles of Haskell

On the contrary! Protecing me against writing dumb code is one of the things where Haskell shines, and I am infinitely grateful for that.  

> Having GHCi protect me from that highly hypothetical situation while  
> preventing me from compiling theoretically correct programs seems  
> strange at best.
But those theoretically correct programs may suddenly cease to be correct in very mysterious and little hypothetical ways, as explained below. 

I agree with Arien. Making the semantics of a function dependent on how many type class instances are in scope is totally against the principles of Haskell, IMHO. Even worse the function signature of createBar does not mention Class1 so at first glance there is no hint that type classes are at work here. Type class instances are hard to contain, in the sense that there is currently no mechanism of selectively importing or not importing them from some module. Change in semantics through orphan instances would be a nightmare to debug:

Suppose you have written a package that defines Class1 and only the first incoherent instance. Alice comes along and uses your package to define a function

useFoo :: Monoid a => a -> Either a a
useFoo = foo

and henceforth Alice relies on the semantics useFoo a = Right (a <> a), because that's what your package intends. Alice's code also depends on a package written by Bob, but she only uses some part of that package which is totally unrelated to useFoo and Class1. In an update of his package, Bob defines your second Class1 instance as orphan instance. Alice never explicitly imported any Class1 stuff from Bob's module, but the new instance will leak anyways. Suddenly the semantics of Alice's function changes, she gets useFoo a = Left a without any changes in her own code! If Bob did not adhere to the versioning policy then Alice has little chance of knowing that Bob's package is the cause. The only hint for Alice is the INCOHERENT pragma that signals danger, and you propose to take that away.  

Olaf

From juan.casanova at ed.ac.uk  Sun Feb 16 21:04:06 2020
From: juan.casanova at ed.ac.uk (Juan Casanova)
Date: Sun, 16 Feb 2020 21:04:06 +0000
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <0E99630D-212F-40FA-B0E5-64F11F0E4C13@aatal-apotheke.de>
References: <0E99630D-212F-40FA-B0E5-64F11F0E4C13@aatal-apotheke.de>
Message-ID: <20200216210406.946757tvlfufqgow@www.staffmail.ed.ac.uk>

> Suddenly the semantics of Alice's function changes, she gets useFoo  
> a = Left a without any changes in her own code!

That's not what would happen with my originally proposed behaviour. It  
would suddenly not compile, because in that case there are, in fact,  
two instances that do match all the way through. It's not the same as  
my original code.

But that is just a punctualization aside from all the things I already  
accepted about the potential problems my solution could indeed fact,  
and more importantly that I had totally misunderstood how overlapping  
instances were meant to be used in principle.



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From ietf-dane at dukhovni.org  Sun Feb 16 22:59:36 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 16 Feb 2020 17:59:36 -0500
Subject: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from
 myself with overlapping instances and existential types
In-Reply-To: <20200216193725.20425wip453628lw@www.staffmail.ed.ac.uk>
References: <20200216034505.15356bo0x4x4i0g8@www.staffmail.ed.ac.uk>
 <jqRNVZJZw5cnIIJ1yn3OkypkHH5ditel3S9G-9c1qBaLBI8prkUvzt7y5m5P6b5h7TT7Ug872-BDFRaU-7y21SNHey22Qa0-taaag75cV4w=@pm.me>
 <20200216144421.15585j8i2pkc63wo@www.staffmail.ed.ac.uk>
 <20200216152104.GA28643@weber>
 <20200216153924.436164zxv9cuxgws@www.staffmail.ed.ac.uk>
 <20200216172725.GG49778@straasha.imrryr.org>
 <20200216193725.20425wip453628lw@www.staffmail.ed.ac.uk>
Message-ID: <986E8EA5-CC6B-4052-B694-CF96F252DC69@dukhovni.org>

> On Feb 16, 2020, at 2:37 PM, Juan Casanova <juan.casanova at ed.ac.uk> wrote:
> 
> I'm not that familiar with Typeable. If I understand correctly, what is
> going on here is that by pattern-matching on the FromB constructor and
> using Typeable, you are bypassing the instance checking and comparing
> two things that should not be compared. Is this a more or less correct
> understanding?

Somewhat, but "should not be compared" is not how I see it.
I prefer types in which structural equivalence is equivalence.
Types that violate this cannot be handled generically.

Typeable allows one to ask whether two terms of a-priori distinct
(polymorphic) types are in fact of the same actual type, and if so,
for example, "cast" one to the other:
	
    cast :: forall a b. (Typeable a, Typeable b) => a -> Maybe b

	The type-safe cast operation

In your example (jazzed up with Typeable and some Eq constraints)
however, it is possible to construct two terms, both of the *same*
type: Bar (Either String String), constructor "FromB" and data
"abc", which are not in fact equivalent because they're
bound to different instances of Class1.

The different instance bindings are not apparent in the types
of the terms or their data, so the reflection machinery fails
tell them apart, and yet they're not the same.  This is best
avoided IMHO.

-- 
-- 
	Viktor.


From godzbanebane at gmail.com  Mon Feb 17 13:12:39 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Mon, 17 Feb 2020 15:12:39 +0200
Subject: [Haskell-cafe] Seeking help with polysemy interpreter ..
In-Reply-To: <CAE7GCT7x3Xz3dfpdnhhKKHhyyTVGH9J1Uf9E99Zz49LLseaNeA@mail.gmail.com>
References: <CAE7GCT7x3Xz3dfpdnhhKKHhyyTVGH9J1Uf9E99Zz49LLseaNeA@mail.gmail.com>
Message-ID: <CABT0e9pPvAfC_j3M0mFUjH8e0phiLZ+NKHGkCcbmbnTSXAKC+Q@mail.gmail.com>

Hi! Sorry for the late reply
The "direct" issue is that you're trying to use SqlPersistT as an effect
(when using it as an argument to Member in runDB) - Member expects things
that are "effects" (produced by polysemy).

If you're not going to be using runDB as an "intermediate" interpreter, but
rather running it as a "final" interpreter (to actually run your program)
you could instead use something like this:

runDB :: forall b. Members [Embed IO, Input (Pool SqlBackend)] r =>
SqlPersistT IO b -> Sem r b
runDB query = embed . runSqlPool query =<< input

to run your db queries in IO and embed the IO in the resulting effect stack
(in this case by also having an input effect from which you can receive
your connection pool)

On Fri, Feb 14, 2020 at 11:08 PM Debasish Ghosh <ghosh.debasish at gmail.com>
wrote:

> Hello -
>
> I have a typeclass like this ..
>
> class (Monad m) => DB m where
>     query :: Text -> m (Maybe Account)
>     ...
>
> and an instance that uses persistent and sqlite ..
>
> instance (MonadIO m) => DB (SqlPersistT m) where
>   query ano = get (AccountKey ano)
>   ..
>
> Now I want to move this to using an effect system - Polysemy ..
>
> data DB m a where
>     Query :: Text -> DB m (Maybe Account)
>     ...
>
> makeSem ''DB
>
> which generates the functions .. I need some help figuring out the type of
> the function that interpretes the above .. An initial intuition is this ..
>
> runDB :: Member SqlPersistT r => Sem (DB ': r) a -> Sem r a
> runDB = interpret $ \case
>   Query ano -> get (AccountKey ano)
>
> which doesn't compile .. errors out with ..
>
> Couldn't match type ‘Control.Monad.Trans.Reader.ReaderT backend0 m0 (Maybe
> Account)’
>                  with ‘Sem r (Maybe Account)’
>   Expected type: Sem r x
>     Actual type: Control.Monad.Trans.Reader.ReaderT
>                    backend0 m0 (Maybe Account)
> • In the expression: get (AccountKey accountNo)
>
> I think I am missing something here. The type of interpret is shown as
> interpret :: (forall x (m :: * -> *). DB m x -> Sem r x) -> Sem (DB : r) a
> -> Sem r a
>
> But how do I translate the SqlPersistT part ? Any help will be
> appreciated.
>
> regards.
> --
> Debasish Ghosh
> http://manning.com/ghosh2
> http://manning.com/ghosh
>
> Twttr: @debasishg
> Blog: http://debasishg.blogspot.com
> Code: http://github.com/debasishg
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200217/4d2f113b/attachment.html>

From ghosh.debasish at gmail.com  Mon Feb 17 18:21:08 2020
From: ghosh.debasish at gmail.com (Debasish Ghosh)
Date: Mon, 17 Feb 2020 23:51:08 +0530
Subject: [Haskell-cafe] Seeking help with polysemy interpreter ..
In-Reply-To: <CABT0e9pPvAfC_j3M0mFUjH8e0phiLZ+NKHGkCcbmbnTSXAKC+Q@mail.gmail.com>
References: <CAE7GCT7x3Xz3dfpdnhhKKHhyyTVGH9J1Uf9E99Zz49LLseaNeA@mail.gmail.com>
 <CABT0e9pPvAfC_j3M0mFUjH8e0phiLZ+NKHGkCcbmbnTSXAKC+Q@mail.gmail.com>
Message-ID: <CAE7GCT5_Y97tacABQcWZ7tKc1kFxAt1T1eFwXDSKUD6PpRCNyg@mail.gmail.com>

Thanks .. I will try it out. Meanwhile I could run the following without
SqlPersistT but using sqlite-simple directly.

runDB :: Member (Embed IO) r => Sem (DB ': r) a -> Sem (Input
SQL.Connection ': r) a
runDB = reinterpret $ \case
  QueryAccount ano -> do
    conn <- input
    account <- embed $ SQL.queryNamed conn
              "SELECT * FROM account WHERE account_no = :accountno"
              [":accountno" := ano]
    return $ listToMaybe account

regards.


On Mon, Feb 17, 2020 at 6:42 PM Georgi Lyubenov <godzbanebane at gmail.com>
wrote:

> Hi! Sorry for the late reply
> The "direct" issue is that you're trying to use SqlPersistT as an effect
> (when using it as an argument to Member in runDB) - Member expects things
> that are "effects" (produced by polysemy).
>
> If you're not going to be using runDB as an "intermediate" interpreter,
> but rather running it as a "final" interpreter (to actually run your
> program) you could instead use something like this:
>
> runDB :: forall b. Members [Embed IO, Input (Pool SqlBackend)] r =>
> SqlPersistT IO b -> Sem r b
> runDB query = embed . runSqlPool query =<< input
>
> to run your db queries in IO and embed the IO in the resulting effect
> stack (in this case by also having an input effect from which you can
> receive your connection pool)
>
> On Fri, Feb 14, 2020 at 11:08 PM Debasish Ghosh <ghosh.debasish at gmail.com>
> wrote:
>
>> Hello -
>>
>> I have a typeclass like this ..
>>
>> class (Monad m) => DB m where
>>     query :: Text -> m (Maybe Account)
>>     ...
>>
>> and an instance that uses persistent and sqlite ..
>>
>> instance (MonadIO m) => DB (SqlPersistT m) where
>>   query ano = get (AccountKey ano)
>>   ..
>>
>> Now I want to move this to using an effect system - Polysemy ..
>>
>> data DB m a where
>>     Query :: Text -> DB m (Maybe Account)
>>     ...
>>
>> makeSem ''DB
>>
>> which generates the functions .. I need some help figuring out the type
>> of the function that interpretes the above .. An initial intuition is this
>> ..
>>
>> runDB :: Member SqlPersistT r => Sem (DB ': r) a -> Sem r a
>> runDB = interpret $ \case
>>   Query ano -> get (AccountKey ano)
>>
>> which doesn't compile .. errors out with ..
>>
>> Couldn't match type ‘Control.Monad.Trans.Reader.ReaderT backend0 m0
>> (Maybe Account)’
>>                  with ‘Sem r (Maybe Account)’
>>   Expected type: Sem r x
>>     Actual type: Control.Monad.Trans.Reader.ReaderT
>>                    backend0 m0 (Maybe Account)
>> • In the expression: get (AccountKey accountNo)
>>
>> I think I am missing something here. The type of interpret is shown as
>> interpret :: (forall x (m :: * -> *). DB m x -> Sem r x) -> Sem (DB : r)
>> a -> Sem r a
>>
>> But how do I translate the SqlPersistT part ? Any help will be
>> appreciated.
>>
>> regards.
>> --
>> Debasish Ghosh
>> http://manning.com/ghosh2
>> http://manning.com/ghosh
>>
>> Twttr: @debasishg
>> Blog: http://debasishg.blogspot.com
>> Code: http://github.com/debasishg
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>

-- 
Debasish Ghosh
http://manning.com/ghosh2
http://manning.com/ghosh

Twttr: @debasishg
Blog: http://debasishg.blogspot.com
Code: http://github.com/debasishg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200217/8916484b/attachment.html>

From emilypi at cohomolo.gy  Tue Feb 18 05:51:02 2020
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Tue, 18 Feb 2020 05:51:02 +0000
Subject: [Haskell-cafe] [Ann] base16, base16-lens, base32, base32-lens
Message-ID: <k6rguzvg.3db74b04-7e1b-4de4-8905-8802758b68d3@we.are.superhuman.com>

Hi Everyone, It's been a productive weekend. I'm pleased to announce the following packages:

* https://hackage.haskell.org/package/base16

* https://hackage.haskell.org/package/base16-lens

* https://hackage.haskell.org/package/base32

* https://hackage.haskell.org/package/base32-lens

These libraries are the conclusion of a small audit I've been doing of the existing base encoding implementations, focusing on performance and providing a common interface for both ByteString and Text values. 

As always, these libraries have a pretty obvious optical interface, and that has been provided as well.

Cheers, and happy President's Day weekend!

- Emily Pillmore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200218/40c5474d/attachment.html>

From eirik.ravnskog92 at gmail.com  Thu Feb 20 20:27:51 2020
From: eirik.ravnskog92 at gmail.com (Eirik Ravnskog)
Date: Thu, 20 Feb 2020 21:27:51 +0100
Subject: [Haskell-cafe] A static analyzer
Message-ID: <5e4eebc8.1c69fb81.22c8a.0cee@mx.google.com>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200220/a174e289/attachment.html>

From byorgey at gmail.com  Thu Feb 20 21:00:21 2020
From: byorgey at gmail.com (Brent Yorgey)
Date: Thu, 20 Feb 2020 15:00:21 -0600
Subject: [Haskell-cafe] A static analyzer
In-Reply-To: <5e4eebc8.1c69fb81.22c8a.0cee@mx.google.com>
References: <5e4eebc8.1c69fb81.22c8a.0cee@mx.google.com>
Message-ID: <CAH0njduPL2po5_hxwQaSACGKi96mR3CL4epB5L1sQ2BQzp9g6w@mail.gmail.com>

Do you have specific questions, or something you are stuck on?  Maybe you
accidentally sent the message before you finished writing it?  People on
this list aren't going to do your homework for you.  If you have no idea
how to even start, you should go talk to the course instructor or teaching
assistant.

+Brent

On Thu, Feb 20, 2020, 2:28 PM Eirik Ravnskog <eirik.ravnskog92 at gmail.com>
wrote:

> Hi. I have a homework-assignment where one of the tasks is to make a
> static Analyzer for BIPL-E, BIPL-E being the BIPL Language with input- and
> output-parameters.
>
> The Analyzer is supposed to
>
>    1. check that all variables has been defined before use. If not, give
>    an error message.
>
> You can do this by traversing each statement in the program to check if it
> uses values that
>
> haven’t been defined before. You can keep track of which variables that
> has been defined so far in a list, and put new ones to the list when you
> encounter Assign-statements
>
>    1. check that all output parameters have been given a value when the
>    program has ended
>    2. You don’t care about what the different statements really evaluates
>    to .
>
>
>
> As a start:
>
>
>
> static_analyzer :: BIPLE -> ..
>
> ..
>
>
>
> Best regards,
>
> Eirik
>
>
>
> Sendt fra E-post <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200220/61cb5386/attachment.html>

From leah at vuxu.org  Sat Feb 22 12:59:01 2020
From: leah at vuxu.org (Leah Neukirchen)
Date: Sat, 22 Feb 2020 13:59:01 +0100
Subject: [Haskell-cafe] Munich Haskell Meeting, 2020-02-25 @ 19:30
Message-ID: <877e0eg4mi.fsf@vuxu.org>

Dear all,

Next week, our monthly Munich Haskell Meeting will take place again on
Tueday, February 25 at Cafe Puck at 19h30. For details see here:

http://muenchen.haskell.bayern/dates.html

If you plan to join, please add yourself to this dudle so we can
reserve enough seats!  It is OK to add yourself to the dudle
anonymously or pseudonymously.

https://dudle.inf.tu-dresden.de/haskell-munich-feb-2020/

Everybody is welcome!

cu,
-- 
Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/

From leah at vuxu.org  Sat Feb 22 17:51:02 2020
From: leah at vuxu.org (Leah Neukirchen)
Date: Sat, 22 Feb 2020 18:51:02 +0100
Subject: [Haskell-cafe] Munich Haskell Meeting, 2020-02-25 @ 19:30
In-Reply-To: <877e0eg4mi.fsf@vuxu.org> (Leah Neukirchen's message of "Sat, 22
 Feb 2020 13:59:01 +0100")
References: <877e0eg4mi.fsf@vuxu.org>
Message-ID: <87y2suecjd.fsf@vuxu.org>

Leah Neukirchen <leah at vuxu.org> writes:

> Dear all,
>
> Next week, our monthly Munich Haskell Meeting will take place again on
> Tueday, February 25 at Cafe Puck at 19h30. For details see here:

There has been a mistake: the meeting is at Augustiner-Gaststätte Rumpler!

> http://muenchen.haskell.bayern/dates.html

cu,
-- 
Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/

From raoknz at gmail.com  Sun Feb 23 10:13:51 2020
From: raoknz at gmail.com (Richard O'Keefe)
Date: Sun, 23 Feb 2020 23:13:51 +1300
Subject: [Haskell-cafe] A static analyzer
In-Reply-To: <5e4eebc8.1c69fb81.22c8a.0cee@mx.google.com>
References: <5e4eebc8.1c69fb81.22c8a.0cee@mx.google.com>
Message-ID: <CABcYAdJLxRDYvhPSPdDO+hfDC7hdo5izVRRg5g099LST+40QgA@mail.gmail.com>

There are very few programming language mailing lists or newsgroups
that tolerate "do my homework" questions, although many, including this,
are helpful to beginners.

The thing you need to understand is that this assignment has three aspects:
(1) understand the problem
(2) craft a solution to the problem
(3) implement the solution in your chosen programming language.

It is only the last of these aspects which actually has anything to do
with Haskell.  If you cannot complete (1) and (2) in *any* form, then
Haskell is not going to help you.

(1) I presume BIPL is the "Basic Imperative Programming Language"
defined in "Software Languages: Syntax, Semantics, and Metaprogramming"
by Ralf Lämmel.  BIPL-E is not mentioned in that book, so I have no clear
idea of it, and I don't suppose others on this mailing list had any more luck
finding it than I did.  A reference to the definition would be handy.

Having understood the data that you will work with (the abstract syntax of
a programming language), you have to understand what kind of problem
you have.  What are you supposed to COMPUTE?

This is a *data-flow* problem.  There are many books about
data-flow analysis, and lecture slides and tutorials in great abundance
on the web.

However, it is a *simplified* problem because the programming
language you are using is composed using single-entry single-exit
control structures, with no exception handling, and where
expressions cannot contain assignments.  (I haven't actually read
the book, so I don't know what BIPL-E does about procedures.)

The things you need to know in your traversal are
 - which variables are DEFINED on entry to a statement
 - which variables BECOME defined during a statement
 - which variables are defined on exit from a statement
 - which variables are USED within a statement (whether
   redefined in that statement or not).
The nasty problem is that getting a precise answer is not
possible, but you have been given a hint.  In
   if <expr> then <stmt> [else <stmt>]
   while <expr> do <stmt>
you don't know whether <expr> will come out true or false.
In (if E then S1 else S2), a variable should be treated as used
if it is used in E, S1, or S2.  A variable will become defined only
if it becomes defined in both S1 and S2.
In (while E do S), a variable should be treated as used
if it is used in E or S.  Since S might not be executed,
a variable is certain to be defined after the while only if it
is certain to be defined before it.
That is, you are not calculating WILL be defined/used but
MUST be defined/MIGHT be used.

Work through a number of exercises by hand to make sure
you understand the problem and formulate a solution.

(3) You will have to figure out a way to represent a set of
variables.  If memory serves me correctly, BIPL does not have
indexed variables, so a variable is just a variable name.  You
might want to see what data structures Haskell already has for
sets.  That would be a good question to ask here.

On Fri, 21 Feb 2020 at 09:28, Eirik Ravnskog <eirik.ravnskog92 at gmail.com> wrote:
>
> Hi. I have a homework-assignment where one of the tasks is to make a static Analyzer for BIPL-E, BIPL-E being the BIPL Language with input- and output-parameters.
>
> The Analyzer is supposed to
>
> check that all variables has been defined before use. If not, give an error message.
>
> You can do this by traversing each statement in the program to check if it uses values that
>
> haven’t been defined before. You can keep track of which variables that has been defined so far in a list, and put new ones to the list when you encounter Assign-statements
>
> check that all output parameters have been given a value when the program has ended
> You don’t care about what the different statements really evaluates to .
>
>
>
> As a start:
>
>
>
> static_analyzer :: BIPLE -> ..
>
> ..
>
>
>
> Best regards,
>
> Eirik
>
>
>
> Sendt fra E-post for Windows 10
>
>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From steven.ramsay at outlook.com  Sun Feb 23 10:39:09 2020
From: steven.ramsay at outlook.com (Steven Ramsay)
Date: Sun, 23 Feb 2020 10:39:09 +0000
Subject: [Haskell-cafe] Lecturer,
 Senior Lecturer or Associate Professor in Programming Languages:
 University of Bristol
Message-ID: <VI1P195MB0416559C713BCCB4A5D7FF23F8EF0@VI1P195MB0416.EURP195.PROD.OUTLOOK.COM>

The University of Bristol are seeking to appoint an
assistant/associate professor in Programming Languages,
those with expertise in functional programming especially welcome!
(Postdoc and funded PhD positions also available).

Position: Lecturer, Senior Lecturer or Associate Professor in
Programming Languages
Location: University of Bristol, UK
Type: Full time, open-ended contract
Salary: £38,017 -- £59,135 per annum
Applications deadline: March 11
Website: http://www.bristol.ac.uk/jobs/find/details.html?nPostingId=65334&nPostingTargetId=182336&id=Q50FK026203F3VBQBV7V77V83&lg=UK

The Department of Computer Science at the University of Bristol is
seeking to appoint a full-time faculty member in Programming Languages
at Lecturer, Senior Lecturer or Associate Professor level; comparable
to Assistant / Associate Professorship.

You will be expected to both deliver outstanding teaching and
undertake internationally leading research in the area of Programming
Languages. There is opportunity to play a significant role in shaping
and leading a new Programming Languages research group.

The Department of Computer Science is an international centre of
excellence in the foundations and applications of computing, ranked
4th in the UK for research intensity by the 2014 REF.  The Department
is already home to expertise in functional programming, program
analysis, algorithms and complexity; it benefits from a close
association with neighbouring groups in Cryptography and Trustworthy
Systems.  The University of Bristol is a leading institution among the
UK's Russell Group Universities and is regularly placed among the
top-ranking institutions in global league tables.  Bristol is a
friendly, green, coastal city with a rich and lively cultural scene
and has consistently been voted one of the best places to live in the
UK.

This post is being offered on a full-time, open-ended contract. A
recruitment supplement scheme is available up to £5K.

For informal discussion about the post you are welcome to contact:
Seth Bullock (Head of Department, mailto:seth.bullock at bristol.ac.uk) or
Steven Ramsay (Lecturer in Programming Languages,
mailto:steven.ramsay at bristol.ac.uk).

The closing date for all applications is 23:59 on Wednesday 11 March
2020. Interviews are expected to take place shortly after the closing
date.

From ben at well-typed.com  Mon Feb 24 18:01:21 2020
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 24 Feb 2020 13:01:21 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.3 is now available
References: <87r1zz1f09.fsf@smart-cactus.org>
Message-ID: <87h7zfamqf.fsf@smart-cactus.org>


Hello everyone,

The GHC team is proud to announce the release of GHC 8.8.3. The source
distribution, binary distributions, and documentation are available at

    https://downloads.haskell.org/~ghc/8.8.3

Release notes are also available [1].

This release fixes a handful of issues affecting 8.8.2:

 - a compiler panic (#17429) due to over-zealous eta reduction

 - a linker crash on Windows (#17575)

 - the ability to bootstrap with earlier 8.8 releases has been restored
   (#17146)

 - the `directory` submodule has been updated, fixing #17598

As always, if anything looks amiss do let us know.

Happy compiling!

Cheers,

- Ben


[1] https://downloads.haskell.org/ghc/8.8.3/docs/html/users_guide/8.8.3-notes.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200224/4d2b095b/attachment.sig>

From ben at well-typed.com  Mon Feb 24 20:37:10 2020
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 24 Feb 2020 15:37:10 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.3 is now available
In-Reply-To: <notmuch-sha1-f74cdd6b3f125f30ec4ea6f72dbe29b93f674488>
References: <87r1zz1f09.fsf@smart-cactus.org>
Message-ID: <87a757afin.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> --text follows this line--
> <#part sign=pgpmime>
>
> Hello everyone,
>
> The GHC team is proud to announce the release of GHC 8.8.3. The source
> distribution, binary distributions, and documentation are available at
>
>     https://downloads.haskell.org/~ghc/8.8.3
>
> Release notes are also available [1].
>
Unfortunately there has been a slight mix-up in the binary distributions
associated with this release and I will need to do a re-spin. I have
pulled down the binary distributions for the time being. They should be
back in a few hours.

Many apologies for the confusion!

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200224/b0d67f45/attachment.sig>

From ben at well-typed.com  Tue Feb 25 01:51:30 2020
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 24 Feb 2020 20:51:30 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.3 is now available
In-Reply-To: <87a757afin.fsf@smart-cactus.org>
References: <87r1zz1f09.fsf@smart-cactus.org> <87a757afin.fsf@smart-cactus.org>
Message-ID: <877e0ba0yq.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Ben Gamari <ben at well-typed.com> writes:
>
>> --text follows this line--
>> <#part sign=pgpmime>
>>
>> Hello everyone,
>>
>> The GHC team is proud to announce the release of GHC 8.8.3. The source
>> distribution, binary distributions, and documentation are available at
>>
>>     https://downloads.haskell.org/~ghc/8.8.3
>>
>> Release notes are also available [1].
>>
> Unfortunately there has been a slight mix-up in the binary distributions
> associated with this release and I will need to do a re-spin. I have
> pulled down the binary distributions for the time being. They should be
> back in a few hours.
>
> Many apologies for the confusion!
>
The issues with the release artifacts have been sorted out. Note that
these are new artifacts built from
d0bab2e3419e49cdbb1201d4650572b57f33420c, which is the commit pointed to
by the ghc-8.8.3-release tag.

While we typically try hard to avoid changing artifacts after they are
announced, given how quickly this issue was caught we thought this was
the least bad option.

Again, my apologies for the confusion and thanks for the patience.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200224/53a53963/attachment.sig>

From juhpetersen at gmail.com  Tue Feb 25 03:10:53 2020
From: juhpetersen at gmail.com (Jens Petersen)
Date: Tue, 25 Feb 2020 11:10:53 +0800
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.3 is now available
In-Reply-To: <87h7zfamqf.fsf@smart-cactus.org>
References: <87r1zz1f09.fsf@smart-cactus.org> <87h7zfamqf.fsf@smart-cactus.org>
Message-ID: <CAEDGBqLRY+cDtoMoPwrj5Ez3bEDx8A=H9NLk=s2VYnLhz4oq5A@mail.gmail.com>

Thank you for the release.

On Tue, 25 Feb 2020 at 02:02, Ben Gamari <ben at well-typed.com> wrote:

> [1]
> https://downloads.haskell.org/ghc/8.8.3/docs/html/users_guide/8.8.3-notes.html
>

I am getting 404 from the docs.

Cheers, Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200225/1a29b0ba/attachment.html>

From ben at well-typed.com  Tue Feb 25 06:16:20 2020
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 25 Feb 2020 01:16:20 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.3 is now available
In-Reply-To: <CAEDGBqLRY+cDtoMoPwrj5Ez3bEDx8A=H9NLk=s2VYnLhz4oq5A@mail.gmail.com>
References: <87r1zz1f09.fsf@smart-cactus.org> <87h7zfamqf.fsf@smart-cactus.org>
 <CAEDGBqLRY+cDtoMoPwrj5Ez3bEDx8A=H9NLk=s2VYnLhz4oq5A@mail.gmail.com>
Message-ID: <87y2sr8a4u.fsf@smart-cactus.org>

Jens Petersen <juhpetersen at gmail.com> writes:

> Thank you for the release.
>
> On Tue, 25 Feb 2020 at 02:02, Ben Gamari <ben at well-typed.com> wrote:
>
>> [1]
>> https://downloads.haskell.org/ghc/8.8.3/docs/html/users_guide/8.8.3-notes.html
>>
>
> I am getting 404 from the docs.

Hmm, this appears to be a CDN issue given that the file exists on the
server and

    https://downloads.haskell.org/ghc/8.8.3/docs/html/users_guide//8.8.3-notes.html

works. This is quite odd given that I am quite aggressive in purging
the CDN at this point.

I'll try to investigate tomorrow.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200225/730004ae/attachment.sig>

From kolar at fit.vutbr.cz  Tue Feb 25 17:18:50 2020
From: kolar at fit.vutbr.cz (=?UTF-8?Q?Kol=C3=A1=C5=99_Du=C5=A1an?=)
Date: Tue, 25 Feb 2020 18:18:50 +0100
Subject: [Haskell-cafe] GHC profiling overhead
Message-ID: <090a054c5f18d70825c91f0a0a313b15@fit.vutbr.cz>

Dear Café,

I'm quite curious about overhead of the profiler...
I've compiled my program with --make -threaded -rtsopts -O2 -prof 
options.
It was started with +RTS -N5 -p

Usually, the program evaluates like 6-7 hours of real time. What is the 
overhead of the profiling? After 8 hours of working, the program has not 
finished yet. I've looked over the Internet and it seems like the 
overhead may be 25 times slowdown and even worse. Is it true? If yes, 
it's not worth waiting then :-)

Best regards,
Dusan

From jaro.reinders at gmail.com  Tue Feb 25 17:58:31 2020
From: jaro.reinders at gmail.com (Jaro Reinders)
Date: Tue, 25 Feb 2020 18:58:31 +0100
Subject: [Haskell-cafe] GHC profiling overhead
In-Reply-To: <090a054c5f18d70825c91f0a0a313b15@fit.vutbr.cz>
References: <090a054c5f18d70825c91f0a0a313b15@fit.vutbr.cz>
Message-ID: <1b8698a9-b302-1c8f-a1b6-c72f8215e03e@gmail.com>

Dear Dusan,

(Automatic) profiling can prevent some very important optimizations such as
inlining. I would recommend this blog post:
https://www.tweag.io/posts/2020-01-30-haskell-profiling.html.

Kind regards,

Jaro

On 25-02-2020 18:18, Kolář Dušan wrote:
> Dear Café,
> 
> I'm quite curious about overhead of the profiler...
> I've compiled my program with --make -threaded -rtsopts -O2 -prof options.
> It was started with +RTS -N5 -p
> 
> Usually, the program evaluates like 6-7 hours of real time. What is the
> overhead of the profiling? After 8 hours of working, the program has not
> finished yet. I've looked over the Internet and it seems like the overhead may
> be 25 times slowdown and even worse. Is it true? If yes, it's not worth waiting
> then :-)
> 
> Best regards,
> Dusan
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From carter.schonwald at gmail.com  Tue Feb 25 20:34:39 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 25 Feb 2020 15:34:39 -0500
Subject: [Haskell-cafe] GHC profiling overhead
In-Reply-To: <1b8698a9-b302-1c8f-a1b6-c72f8215e03e@gmail.com>
References: <090a054c5f18d70825c91f0a0a313b15@fit.vutbr.cz>
 <1b8698a9-b302-1c8f-a1b6-c72f8215e03e@gmail.com>
Message-ID: <CAHYVw0z3Uin_chwOq4LmGUrXSXQ5PrqoXxCT7vgve-O=LriRvg@mail.gmail.com>

its worth nothing that if you build the application / libraries / ghc  with
-g or g2 or the like, you can do low over head statistical profiling using
DWARF metadata related tools, though the source code mapping isn't as nice
as what cost center time / allocation profilng can accomplish.

On Tue, Feb 25, 2020 at 12:59 PM Jaro Reinders <jaro.reinders at gmail.com>
wrote:

> Dear Dusan,
>
> (Automatic) profiling can prevent some very important optimizations such as
> inlining. I would recommend this blog post:
> https://www.tweag.io/posts/2020-01-30-haskell-profiling.html.
>
> Kind regards,
>
> Jaro
>
> On 25-02-2020 18:18, Kolář Dušan wrote:
> > Dear Café,
> >
> > I'm quite curious about overhead of the profiler...
> > I've compiled my program with --make -threaded -rtsopts -O2 -prof
> options.
> > It was started with +RTS -N5 -p
> >
> > Usually, the program evaluates like 6-7 hours of real time. What is the
> > overhead of the profiling? After 8 hours of working, the program has not
> > finished yet. I've looked over the Internet and it seems like the
> overhead may
> > be 25 times slowdown and even worse. Is it true? If yes, it's not worth
> waiting
> > then :-)
> >
> > Best regards,
> > Dusan
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200225/75b21cb3/attachment.html>

From tebogos at gmail.com  Thu Feb 27 03:57:00 2020
From: tebogos at gmail.com (Tebogo Sikwane)
Date: Thu, 27 Feb 2020 05:57:00 +0200
Subject: [Haskell-cafe] How to deal with HTML input select option on a form
 using in a scotty and Text.Blaze.Html5
Message-ID: <CANLM0wZVZ91+iT3W3mCvam+KCd7xg4QY_TaAwAP_EtQVOwCDNw@mail.gmail.com>

I am using scotty
and Text.Blaze.Html5 Text.Digestive Text.Digestive.Blaze.Html5
 What I want to achieve is a list of options as shown below.


I have a Option sum type and will like to restrict the user to those
options.

data Options = Option1 | Option2 | Option3 | Option4 deriving Show

Below is the Register record typeY

data Register = Register

{ regName::Text

, regOption::Options

} deriving (Show,Eq)

My problem is with Text.Digestive.choice.
I don't know how to use it with Text.Digestive.Blaze.Html5 and will
appreciate your help on the correct way to achieve this.
I have tried to use the code below but battle to get it right.

registerForm :: Monad m => Form Text m Register
registerForm = Register
   <$> "name"     .: text Nothing
   <*> "options" .: choice options Nothing
   where
     options= [(Option1,"Option1"),(Option2,"Option2"),  (Option3,
       "Option3"),Option4,"Option4"]
registerView:: View H.Html -> H.Html
registerView view = do
    label     "name" view "Name: "
    inputText "name" view
    H.br
    label       "options" view "Options: "
    inputSelect "options" view
    H.br

I get the following error when I compile my code:

/root/work/src/Adapter/HTTP/Web/Auth.hs:107:29: error:
    • Couldn't match type ‘Text’ with ‘Char’
        arising from the literal ‘"Option1"’
    • In the first argument of ‘pack’, namely ‘"Option1"’
      In the expression: pack "Option1"
      In the expression: (Option1, pack "Option1")
    |
107 |     options=  [(Option1,pack "Option1"),(Option2,pack
"Option2"),(Option3,pack "Option3"),(Option4,pack "Option4")]


Your help will be highly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200227/f71b5204/attachment.html>

From juhpetersen at gmail.com  Sat Feb 29 09:51:53 2020
From: juhpetersen at gmail.com (Jens Petersen)
Date: Sat, 29 Feb 2020 17:51:53 +0800
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.3 is now available
In-Reply-To: <877e0ba0yq.fsf@smart-cactus.org>
References: <87r1zz1f09.fsf@smart-cactus.org> <87a757afin.fsf@smart-cactus.org>
 <877e0ba0yq.fsf@smart-cactus.org>
Message-ID: <CAEDGBq+VuNTuqv6XU43wadPpt-qJt_sMg57NqJMz=HBLDuGKDw@mail.gmail.com>

On Tue, 25 Feb 2020 at 09:52, Ben Gamari <ben at well-typed.com> wrote:

> > Ben Gamari <ben at well-typed.com> writes:
> >> The GHC team is proud to announce the release of GHC 8.8.3.
>

Thank you, if you are in Fedora you can now install this with:

`sudo dnf --enablerepo=updates-testing-modular` module install ghc:8.8`

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200229/1acfc999/attachment.html>