From jack at jackkelly.name  Wed Apr  1 08:38:08 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Wed, 01 Apr 2020 18:38:08 +1000
Subject: [Haskell-cafe] [ANN] acme-dont-1.2 - a "don't" construct
Message-ID: <874ku38utr.fsf@jackkelly.name>

Hello all,

I have taken over the maintainership of acme-dont, and am pleased to
announce a new acme-dont release on Hackage[1].


acme-dont provides a `don't` function, which does not execute its
argument. For example, the following code will not print anything:

    import Acme.Dont (don't)

    quiet :: IO ()
    quiet = don't $ putStrLn "You'll never see this on stdout"


New in this release:

* `don't` has been generalised from `Monad` to `Applicative`. If you
  have been waiting since GHC 8.0.1's release in 2016[2] to use `don't` with
  `-XApplicativeDo`, wait no longer.

* A test suite, to ensure that `don't` does not do anything. Previous
  versions could have been defined as `don't = void` for all we knew.


Also, the acme-dont community now has a new home on sourcehut. On there,
you can find the following invaluable resources:

* A source repository[3], to track further developement and new ways of
  not doing things, with a commit history reconstructed from the release
  tarballs uploaded to Hackage.

* A mailing list[4] for the acme-dont community to discuss the best ways
  of not doing things.

* A bug tracker[5] to handle reports, in case someone observes acme-dont
  doing something.

* Continuous integration[6], to ensure that acme-dont continues to not
  do things across multiple versions of GHC.


I would like to thank Gracjan Polak for uploading the initial releases
of `acme-dont`, and for maintaining the package these past eleven
years. I do not intend to betray the responsibility he has assigned me
in handing over this critical package.

Best,

-- Jack

[1]: https://hackage.haskell.org/package/acme-dont-1.2
[2]: https://www.haskell.org/ghc/download_ghc_8_0_1
[3]: https://git.sr.ht/~jack/acme-dont
[4]: https://lists.sr.ht/~jack/acme-dont-discuss
[5]: https://todo.sr.ht/~jack/acme-dont
[6]: https://builds.sr.ht/~jack/acme-dont

From compl.yue at icloud.com  Wed Apr  1 09:41:27 2020
From: compl.yue at icloud.com (YueCompl)
Date: Wed, 1 Apr 2020 17:41:27 +0800
Subject: [Haskell-cafe] mmap Failure in: 24:Counters should be zero
Message-ID: <4DE49E82-C118-40FD-B237-1EBBF7A3C894@icloud.com>

Hi mmap maintainers,

Today I found the last test case out of 25 failed like:

```bash
$ cabal v2-run -f mmaptest mmaptest
Resolving dependencies...
Build profile: -w ghc-8.6.5 -O1
In order, the following will be built (use -v for more details):
 - mmap-0.5.9 (exe:mmaptest) (configuration changed)
Configuring mmap-0.5.9...
Preprocessing executable 'mmaptest' for mmap-0.5.9..
Building executable 'mmaptest' for mmap-0.5.9..

<no location info>: warning: [-Wmissing-home-modules]
    These modules are needed for compilation but not listed in your .cabal file's other-modules: 
        System.IO.MMap

<no location info>: warning: [-Wmissing-home-modules]
    These modules are needed for compilation but not listed in your .cabal file's other-modules: 
        System.IO.MMap
### Failure in: 24:Counters should be zero  
tests/mmaptest.hs:256
expected: 0
 but got: 4
Cases: 25  Tried: 25  Errors: 0  Failures: 1
```

And the test code is:

```haskell
test_counters_zero = do
    System.Mem.performGC
    threadDelay 1000
    counters <- c_system_io_counters
    return (counters @?= 0)
```

I see it is to make sure no resource held open after 1 millisecond after garbage collection is triggered. 
I tried extending the threadDelay to 10 second and still got 4 thus failing the test, maybe newer machinery of GC with GHC 8.6 should be leveraged to prevent such leakage?

I CC haskell-cafe list to seek for broader community help, maybe some one can confirm that I can just live with this specific failure without worries?

Thanks & best regards,
Compl

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

From jack at jackkelly.name  Wed Apr  1 09:48:42 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Wed, 01 Apr 2020 19:48:42 +1000
Subject: [Haskell-cafe] mmap Failure in: 24:Counters should be zero
In-Reply-To: <4DE49E82-C118-40FD-B237-1EBBF7A3C894@icloud.com> (YueCompl's
 message of "Wed, 1 Apr 2020 17:41:27 +0800")
References: <4DE49E82-C118-40FD-B237-1EBBF7A3C894@icloud.com>
Message-ID: <87v9mj7czp.fsf@jackkelly.name>

I am not a maintainer for mmap, and do not know.

-- Jack

YueCompl <compl.yue at icloud.com> writes:

> Hi mmap maintainers,
>
> Today I found the last test case out of 25 failed like:
>
> ```bash
> $ cabal v2-run -f mmaptest mmaptest
> Resolving dependencies...
> Build profile: -w ghc-8.6.5 -O1
> In order, the following will be built (use -v for more details):
>  - mmap-0.5.9 (exe:mmaptest) (configuration changed)
> Configuring mmap-0.5.9...
> Preprocessing executable 'mmaptest' for mmap-0.5.9..
> Building executable 'mmaptest' for mmap-0.5.9..
>
> <no location info>: warning: [-Wmissing-home-modules]
>     These modules are needed for compilation but not listed in your .cabal file's other-modules: 
>         System.IO.MMap
>
> <no location info>: warning: [-Wmissing-home-modules]
>     These modules are needed for compilation but not listed in your .cabal file's other-modules: 
>         System.IO.MMap
> ### Failure in: 24:Counters should be zero  
> tests/mmaptest.hs:256
> expected: 0
>  but got: 4
> Cases: 25  Tried: 25  Errors: 0  Failures: 1
> ```
>
> And the test code is:
>
> ```haskell
> test_counters_zero = do
>     System.Mem.performGC
>     threadDelay 1000
>     counters <- c_system_io_counters
>     return (counters @?= 0)
> ```
>
> I see it is to make sure no resource held open after 1 millisecond after garbage collection is triggered. 
> I tried extending the threadDelay to 10 second and still got 4 thus failing the test, maybe newer machinery of GC with GHC 8.6 should be leveraged to prevent such leakage?
>
> I CC haskell-cafe list to seek for broader community help, maybe some one can confirm that I can just live with this specific failure without worries?
>
> Thanks & best regards,
> Compl

From hjgtuyl at chello.nl  Wed Apr  1 13:07:08 2020
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Wed, 01 Apr 2020 15:07:08 +0200
Subject: [Haskell-cafe] [ANN] acme-dont-1.2 - a "don't" construct
In-Reply-To: <874ku38utr.fsf@jackkelly.name>
References: <874ku38utr.fsf@jackkelly.name>
Message-ID: <op.0ieb2awfpz0j5l@alquantor>


Thanks,

The `don't` function is a big step forward in computering; it will surely
prevent many bugs from occurring, with little effort to software
developers.

Is it published in a scientific magazine yet?

Regards,
Henk-Jan van Tuyl


On Wed, 01 Apr 2020 10:38:08 +0200, Jack Kelly <jack at jackkelly.name> wrote:

> Hello all,
>
> I have taken over the maintainership of acme-dont, and am pleased to
> announce a new acme-dont release on Hackage[1].
>
>
> acme-dont provides a `don't` function, which does not execute its
> argument. For example, the following code will not print anything:
>
>     import Acme.Dont (don't)
>
>     quiet :: IO ()
>     quiet = don't $ putStrLn "You'll never see this on stdout"
>
>
> New in this release:
>
> * `don't` has been generalised from `Monad` to `Applicative`. If you
>   have been waiting since GHC 8.0.1's release in 2016[2] to use `don't`  
> with
>   `-XApplicativeDo`, wait no longer.
>
> * A test suite, to ensure that `don't` does not do anything. Previous
>   versions could have been defined as `don't = void` for all we knew.
>
>
> Also, the acme-dont community now has a new home on sourcehut. On there,
> you can find the following invaluable resources:
>
> * A source repository[3], to track further developement and new ways of
>   not doing things, with a commit history reconstructed from the release
>   tarballs uploaded to Hackage.
>
> * A mailing list[4] for the acme-dont community to discuss the best ways
>   of not doing things.
>
> * A bug tracker[5] to handle reports, in case someone observes acme-dont
>   doing something.
>
> * Continuous integration[6], to ensure that acme-dont continues to not
>   do things across multiple versions of GHC.
>
>
> I would like to thank Gracjan Polak for uploading the initial releases
> of `acme-dont`, and for maintaining the package these past eleven
> years. I do not intend to betray the responsibility he has assigned me
> in handing over this critical package.
>
> Best,
>
> -- Jack
>
> [1]: https://hackage.haskell.org/package/acme-dont-1.2
> [2]: https://www.haskell.org/ghc/download_ghc_8_0_1
> [3]: https://git.sr.ht/~jack/acme-dont
> [4]: https://lists.sr.ht/~jack/acme-dont-discuss
> [5]: https://todo.sr.ht/~jack/acme-dont
> [6]: https://builds.sr.ht/~jack/acme-dont
> _______________________________________________
> 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.




-- 
Message from Stanford University:

Folding at home

What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
https://foldingathome.org/

--
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From lemming at henning-thielemann.de  Wed Apr  1 13:22:36 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 1 Apr 2020 15:22:36 +0200 (CEST)
Subject: [Haskell-cafe] [ANN] acme-dont-1.2 - a "don't" construct
In-Reply-To: <op.0ieb2awfpz0j5l@alquantor>
References: <874ku38utr.fsf@jackkelly.name> <op.0ieb2awfpz0j5l@alquantor>
Message-ID: <alpine.DEB.2.20.2004011521420.4608@sputnik>


On Wed, 1 Apr 2020, Henk-Jan van Tuyl wrote:

> The `don't` function is a big step forward in computering; it will surely
> prevent many bugs from occurring, with little effort to software
> developers.

The library also shines at documentation, test coverage and community 
support!

From rae at richarde.dev  Wed Apr  1 13:33:31 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 1 Apr 2020 14:33:31 +0100
Subject: [Haskell-cafe] [ANN] acme-dont-1.2 - a "don't" construct
In-Reply-To: <874ku38utr.fsf@jackkelly.name>
References: <874ku38utr.fsf@jackkelly.name>
Message-ID: <C3DCB96D-2037-4395-8265-1BC82020B433@richarde.dev>

Presumably, if we don't execute the argument of don't, we don't need to type-check it either. This suggests that, with -fdefer-type-errors -Wno-deferred-type-errors -Wno-deferred-out-of-scope-variables, `don't $` becomes a decent replacement for the `--` commenting operator, except that `don't` has the advantage of being indentation-aware in a `do` block. Perhaps with https://github.com/ghc-proposals/ghc-proposals/pull/216 <https://github.com/ghc-proposals/ghc-proposals/pull/216>, we can have `Not.do` introduce an indentation-aware block of comments. This would surely show off the power, elegance, and beauty of Haskell.

Richard

> On Apr 1, 2020, at 9:38 AM, Jack Kelly <jack at jackkelly.name> wrote:
> 
> Hello all,
> 
> I have taken over the maintainership of acme-dont, and am pleased to
> announce a new acme-dont release on Hackage[1].
> 
> 
> acme-dont provides a `don't` function, which does not execute its
> argument. For example, the following code will not print anything:
> 
>    import Acme.Dont (don't)
> 
>    quiet :: IO ()
>    quiet = don't $ putStrLn "You'll never see this on stdout"
> 
> 
> New in this release:
> 
> * `don't` has been generalised from `Monad` to `Applicative`. If you
>  have been waiting since GHC 8.0.1's release in 2016[2] to use `don't` with
>  `-XApplicativeDo`, wait no longer.
> 
> * A test suite, to ensure that `don't` does not do anything. Previous
>  versions could have been defined as `don't = void` for all we knew.
> 
> 
> Also, the acme-dont community now has a new home on sourcehut. On there,
> you can find the following invaluable resources:
> 
> * A source repository[3], to track further developement and new ways of
>  not doing things, with a commit history reconstructed from the release
>  tarballs uploaded to Hackage.
> 
> * A mailing list[4] for the acme-dont community to discuss the best ways
>  of not doing things.
> 
> * A bug tracker[5] to handle reports, in case someone observes acme-dont
>  doing something.
> 
> * Continuous integration[6], to ensure that acme-dont continues to not
>  do things across multiple versions of GHC.
> 
> 
> I would like to thank Gracjan Polak for uploading the initial releases
> of `acme-dont`, and for maintaining the package these past eleven
> years. I do not intend to betray the responsibility he has assigned me
> in handing over this critical package.
> 
> Best,
> 
> -- Jack
> 
> [1]: https://hackage.haskell.org/package/acme-dont-1.2
> [2]: https://www.haskell.org/ghc/download_ghc_8_0_1
> [3]: https://git.sr.ht/~jack/acme-dont
> [4]: https://lists.sr.ht/~jack/acme-dont-discuss
> [5]: https://todo.sr.ht/~jack/acme-dont
> [6]: https://builds.sr.ht/~jack/acme-dont
> _______________________________________________
> 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/20200401/b261c334/attachment.html>

From jack at jackkelly.name  Wed Apr  1 20:49:23 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Thu, 02 Apr 2020 06:49:23 +1000
Subject: [Haskell-cafe] [ANN] acme-dont-1.2 - a "don't" construct
In-Reply-To: <op.0ieby7nbl13hs7@alquantor> (Henk-Jan van Tuyl's message of
 "Wed, 01 Apr 2020 15:05:17 +0200")
References: <874ku38utr.fsf@jackkelly.name> <op.0ieby7nbl13hs7@alquantor>
Message-ID: <87imij53u4.fsf@jackkelly.name>

Dear Henk-Jan,

You can view the preprint yourself with the following commands:

$ true > dont.txt
$ less dont.txt

You'll then start seeing it everywhere you look, and I'm not sure that
wider distribution is possible.

-- Jack

"Henk-Jan van Tuyl" <b.vantuyl1 at upcmail.nl> writes:

> Thanks,
>
> The `don't` function is a big step forward in computering; it will
> surely prevent many bugs from occurring, with little effort to
> software developers.
>
> Is it published in a scientific magazine yet?
>
> Regards,
> Henk-Jan van Tuyl
>
>
> On Wed, 01 Apr 2020 10:38:08 +0200, Jack Kelly <jack at jackkelly.name> wrote:
>
>> Hello all,
>>
>> I have taken over the maintainership of acme-dont, and am pleased to
>> announce a new acme-dont release on Hackage[1].
>>
>>
>> acme-dont provides a `don't` function, which does not execute its
>> argument. For example, the following code will not print anything:
>>
>>     import Acme.Dont (don't)
>>
>>     quiet :: IO ()
>>     quiet = don't $ putStrLn "You'll never see this on stdout"
>>
>>
>> New in this release:
>>
>> * `don't` has been generalised from `Monad` to `Applicative`. If you
>>   have been waiting since GHC 8.0.1's release in 2016[2] to use
>> `don't` with
>>   `-XApplicativeDo`, wait no longer.
>>
>> * A test suite, to ensure that `don't` does not do anything. Previous
>>   versions could have been defined as `don't = void` for all we knew.
>>
>>
>> Also, the acme-dont community now has a new home on sourcehut. On there,
>> you can find the following invaluable resources:
>>
>> * A source repository[3], to track further developement and new ways of
>>   not doing things, with a commit history reconstructed from the release
>>   tarballs uploaded to Hackage.
>>
>> * A mailing list[4] for the acme-dont community to discuss the best ways
>>   of not doing things.
>>
>> * A bug tracker[5] to handle reports, in case someone observes acme-dont
>>   doing something.
>>
>> * Continuous integration[6], to ensure that acme-dont continues to not
>>   do things across multiple versions of GHC.
>>
>>
>> I would like to thank Gracjan Polak for uploading the initial releases
>> of `acme-dont`, and for maintaining the package these past eleven
>> years. I do not intend to betray the responsibility he has assigned me
>> in handing over this critical package.
>>
>> Best,
>>
>> -- Jack
>>
>> [1]: https://hackage.haskell.org/package/acme-dont-1.2
>> [2]: https://www.haskell.org/ghc/download_ghc_8_0_1
>> [3]: https://git.sr.ht/~jack/acme-dont
>> [4]: https://lists.sr.ht/~jack/acme-dont-discuss
>> [5]: https://todo.sr.ht/~jack/acme-dont
>> [6]: https://builds.sr.ht/~jack/acme-dont
>> _______________________________________________
>> 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 mikehulluk at gmail.com  Thu Apr  2 08:01:28 2020
From: mikehulluk at gmail.com (Michael Hull)
Date: Thu, 2 Apr 2020 09:01:28 +0100
Subject: [Haskell-cafe] Using State monad with lens
In-Reply-To: <20200321211129.12615yypjih4nesk@www.staffmail.ed.ac.uk>
References: <CABzAe0Y6RVb7coxYcTy48whSzmwdjjt=c_tRss9r5BUqk_xuNg@mail.gmail.com>
 <k81tssum.5136de04-9b7e-47be-8963-f281a939829a@we.are.superhuman.com>
 <CAEru=j5CGM4-07hUuz1u30qE_Jra20wH44n2eK-U3VrF8e9UKA@mail.gmail.com>
 <20200321211129.12615yypjih4nesk@www.staffmail.ed.ac.uk>
Message-ID: <CABzAe0afVurUi69FziA5WaZqcosuNLiLBED++nOexvA-BFjh1A@mail.gmail.com>

Thankyou everybody - this is really helpful, especially the \case technique.
@Juan I am not sure my Haskell is strong enough to use zoom yet, but I will
look into it!
Thanks again.

Mike


On Sat, 21 Mar 2020 at 21:12, Juan Casanova <juan.casanova at ed.ac.uk> wrote:

> I'm surprised noone has mentioned 'zoom' yet. It does not make your
> original example work directly, but almost. It may be very useful to
> keep in mind as a way to do whatever you want.
>
>
> http://hackage.haskell.org/package/lens-4.19.1/docs/Control-Lens-Zoom.html#v:zoom
>
> The idea of zoom is that you use it like so:
>
> zoom my_lens my_monadic_action
>
> where my_monadic_action is a monadic action that works on the
> sub-element (call it 's') of the state, and the entire thing 'zoom
> my_lens my_monadic_action' is then a monadic action that works on the
> whole element (call it 't'). my_lens is a lens that focuses on 's'
> within 't'.
>
> So instead of using the lens all the time in the monadic action,
> you're basically saying: "Put this everywhere that you need to", and
> then you can do things with the sub-element 's'.
>
> Juan.
>
> PS: I hope I did not severely misunderstand what you wanted, but it's
> still a possibility.
>
> --
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200402/68dfd441/attachment.html>

From mail at joachim-breitner.de  Thu Apr  2 09:02:05 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 02 Apr 2020 11:02:05 +0200
Subject: [Haskell-cafe] [ANN] acme-dont-1.2 - a "don't" construct
In-Reply-To: <C3DCB96D-2037-4395-8265-1BC82020B433@richarde.dev>
References: <874ku38utr.fsf@jackkelly.name>
 <C3DCB96D-2037-4395-8265-1BC82020B433@richarde.dev>
Message-ID: <1059b9edb92e65d39018d80153a6aef9256006e2.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 01.04.2020, 14:33 +0100 schrieb Richard Eisenberg:
> Perhaps with https://github.com/ghc-proposals/ghc-proposals/pull/216,
> we can have `Not.do` introduce an indentation-aware block of
> comments. This would surely show off the power, elegance, and beauty
> of Haskell.

Unfortunately, not:

  Not.do print "Hello"

will still desguar to 

> 
> Richard
> 
> > On Apr 1, 2020, at 9:38 AM, Jack Kelly <jack at jackkelly.name> wrote:
> > 
> > Hello all,
> > 
> > I have taken over the maintainership of acme-dont, and am pleased to
> > announce a new acme-dont release on Hackage[1].
> > 
> > 
> > acme-dont provides a `don't` function, which does not execute its
> > argument. For example, the following code will not print anything:
> > 
> >    import Acme.Dont (don't)
> > 
> >    quiet :: IO ()
> >    quiet = don't $ putStrLn "You'll never see this on stdout"
> > 
> > 
> > New in this release:
> > 
> > * `don't` has been generalised from `Monad` to `Applicative`. If you
> >  have been waiting since GHC 8.0.1's release in 2016[2] to use `don't` with
> >  `-XApplicativeDo`, wait no longer.
> > 
> > * A test suite, to ensure that `don't` does not do anything. Previous
> >  versions could have been defined as `don't = void` for all we knew.
> > 
> > 
> > Also, the acme-dont community now has a new home on sourcehut. On there,
> > you can find the following invaluable resources:
> > 
> > * A source repository[3], to track further developement and new ways of
> >  not doing things, with a commit history reconstructed from the release
> >  tarballs uploaded to Hackage.
> > 
> > * A mailing list[4] for the acme-dont community to discuss the best ways
> >  of not doing things.
> > 
> > * A bug tracker[5] to handle reports, in case someone observes acme-dont
> >  doing something.
> > 
> > * Continuous integration[6], to ensure that acme-dont continues to not
> >  do things across multiple versions of GHC.
> > 
> > 
> > I would like to thank Gracjan Polak for uploading the initial releases
> > of `acme-dont`, and for maintaining the package these past eleven
> > years. I do not intend to betray the responsibility he has assigned me
> > in handing over this critical package.
> > 
> > Best,
> > 
> > -- Jack
> > 
> > [1]: https://hackage.haskell.org/package/acme-dont-1.2
> > [2]: https://www.haskell.org/ghc/download_ghc_8_0_1
> > [3]: https://git.sr.ht/~jack/acme-dont
> > [4]: https://lists.sr.ht/~jack/acme-dont-discuss
> > [5]: https://todo.sr.ht/~jack/acme-dont
> > [6]: https://builds.sr.ht/~jack/acme-dont
> > _______________________________________________
> > 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.
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Thu Apr  2 09:03:42 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 02 Apr 2020 11:03:42 +0200
Subject: [Haskell-cafe] [ANN] acme-dont-1.2 - a "don't" construct
In-Reply-To: <C3DCB96D-2037-4395-8265-1BC82020B433@richarde.dev>
References: <874ku38utr.fsf@jackkelly.name>
 <C3DCB96D-2037-4395-8265-1BC82020B433@richarde.dev>
Message-ID: <49f11c6f25e05cc1b49ef54ae2e2abb97670403b.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 01.04.2020, 14:33 +0100 schrieb Richard Eisenberg:
> Perhaps with https://github.com/ghc-proposals/ghc-proposals/pull/216,
> we can have `Not.do` introduce an indentation-aware block of
> comments. This would surely show off the power, elegance, and beauty
> of Haskell.

Unfortunately, not:

  Not.do print "Hello"

will still desguar to 

  print "Hello"

which points to a crucial design flaw of do notation (and which could
be fixed as part of #216): The inability to specify an operation to
apply to the do-block as a whole.


Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Thu Apr  2 09:09:38 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 2 Apr 2020 10:09:38 +0100
Subject: [Haskell-cafe] [ANN] acme-dont-1.2 - a "don't" construct
In-Reply-To: <49f11c6f25e05cc1b49ef54ae2e2abb97670403b.camel@joachim-breitner.de>
References: <874ku38utr.fsf@jackkelly.name>
 <C3DCB96D-2037-4395-8265-1BC82020B433@richarde.dev>
 <49f11c6f25e05cc1b49ef54ae2e2abb97670403b.camel@joachim-breitner.de>
Message-ID: <A439E4FE-BF0E-4353-8D43-B67F5F7A7369@richarde.dev>



> On Apr 2, 2020, at 10:03 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> a crucial design flaw of do notation (and which could
> be fixed as part of #216): The inability to specify an operation to
> apply to the do-block as a whole.

Even having seen the dawn of a new day, this is an interesting point. Built-in `do` notation does not need to do any desugaring to a single statement, but maybe variants do. And even within GHC, the last statement of a do-block has special status -- it's just that do-notation treats it like any other statement. So maybe it's worth extending #216 with a new feature that applies an operation to the last statement. Seems to fit very much with the spirit of #216, with little downside.

Just posting here to make sure I'm not crazy before posting to the altogether-more-serious #216 itself.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200402/72fb9163/attachment.html>

From cyberfined at protonmail.com  Thu Apr  2 19:25:53 2020
From: cyberfined at protonmail.com (cyberfined)
Date: Thu, 02 Apr 2020 19:25:53 +0000
Subject: [Haskell-cafe] How to safely and fast write repa array to a file?
Message-ID: <BU6nBD07EP-WTdwM3YvhBuUkxQ2JKLZ5lsFcHqbWnlqyXtK0AFR8hlJi0xO9f6mXrNEa0lObMHmeVgHi55ucVYgf2s_asu41RR8VMJFZGbU=@protonmail.com>

Hello, all. I decide to write parallel ray tracer on haskell with repa. Now, to save repa array to file I use dirty trick casting repa array ptr to bytestring with fromForeignPtr and then writing it to file with hPut. It looks something like that:

import qualified Data.Array.Repa as R

import qualified Data.Array.Repa.Repr.ForeignPtr as RF

import qualified Data.ByteString as B
import qualified Data.ByteString.Char8 as BC
import qualified Data.ByteString.Internal as BI

type Image = Array F DIM2 Pixel

writeImage :: FilePath -> Image -> IO ()
writeImage path img = bracket (openFile path WriteMode) (hClose) $ \hdl -> B.hPut hdl header >> B.hPut hdl body
  where Z :. h :. w = R.extent img
        header = BC.pack $ "P6\n" ++ show w ++ ' ':show h ++ "\n255\n"
        body = BI.fromForeignPtr(castForeignPtr $ RF.toForeignPtr img) 0 (w*h*3)

My question is: how to write repa array to file safely and fast?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200402/f91addfc/attachment.html>

From manny at fpcomplete.com  Thu Apr  2 23:56:44 2020
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Thu, 2 Apr 2020 16:56:44 -0700
Subject: [Haskell-cafe] ANN: stack-2.3.0.1 release candidate
Message-ID: <CACGj5vLLExMvhjhEdK7TDXWMMXGVVii=9TizM3FMQF+Km4_EuA@mail.gmail.com>

### First release candidate for v2.3

**Changes since v2.1.3**

Release notes:

Major changes:
* `setup-info-locations` yaml configuration now allows overwriting the
default locations of `stack-setup-2.yaml`.
  [#5031](https://github.com/commercialhaskell/stack/pull/5031)
  [#2983](https://github.com/commercialhaskell/stack/issues/2983)
  [#2913](https://github.com/commercialhaskell/stack/issues/2913)

* The `setup-info` configuration key now allows overwriting parts of
the default `setup-info`

* The `--setup-info-yaml` command line flag now may be used in all
stack commands such as `stack build`, and not only in `stack setup`

* The `--setup-info-yaml` may specify multiple locations for
`stack-setup.yaml` files.

* The `stack upload` can read first reads environment Variable
`$HACKAGE_USERNAME` and `$HACKAGE_PASSWORD` if they are missing only
then asks for `username` or `password`

* Fully remove GHCJS support.

* Remove the `freeze` command. It has been replaced by lock files.

Behavior changes:
* Remove the deprecated `--stack-setup-yaml` command line argument in
favor of `--setup-info-yaml`
  [#2647](https://github.com/commercialhaskell/stack/issues/2647)

* We now recommend checking in generated cabal files for repos. When
generating lock files for
  extra-deps that only include `package.yaml` files, a deprecation
warning will be generated.
  Also, those packages will no longer be included in the generated lock files.
  See [#5210](https://github.com/commercialhaskell/stack/issues/5210).

Other enhancements:
* Add `build-output-timestamps` flag in yaml. Setting it to true
  prefixes each build log output line with a timestamp.

* Show warning about `local-programs-path` with spaces on windows
  when running scripts. See
  [#5013](https://github.com/commercialhaskell/stack/pull/5013)

* Add `ls dependencies json` which will print dependencies as JSON.
  `ls dependencies --tree`  is now `ls dependencies tree`. See
  [#4424](https://github.com/commercialhaskell/stack/pull/4424)

* Remove warning for using Stack with GHC 8.8 and Cabal 3.0.

* Allow relative paths in `--setup-info-yaml` and tool paths
  [#3394](https://github.com/commercialhaskell/stack/issues/3394)

Bug fixes:

* Upgrade `pantry`: module mapping insertions into the database are now atomic.
  Previously, if you SIGTERMed at the wrong time while running a script, you
  could end up with an inconsistent database state.

* `--resolver global` doesn't retrieve snapshots list from the internet
   beause doesn't need it. See
[#5103](https://github.com/commercialhaskell/stack/issues/5103)

* Fix using relative links in haddocks output.  See
  [#4971](https://github.com/commercialhaskell/stack/issues/4971).
* Do not include generated cabal file information in lock files. See
  [#5045](https://github.com/commercialhaskell/stack/issues/5045).

* Use proper Hoogle executable path when installed automatically. See
  [#4905](https://github.com/commercialhaskell/stack/issues/4905)

* Fix GHC version for batched package unregistration. See
  [#4951](https://github.com/commercialhaskell/stack/issues/4951)

* Use Hoogle from the snapshot used and not the latest version. See
  [#4905](https://github.com/commercialhaskell/stack/issues/4905)

* Resolve "'stty' is not recognized". See
  [#4901](https://github.com/commercialhaskell/stack/issues/4901)

* Fix missing reconfigure check causing errors when a package gets
  used in multiple projects. See
  [#5147](https://github.com/commercialhaskell/stack/issues/5147)

From manny at fpcomplete.com  Thu Apr  2 23:58:02 2020
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Thu, 2 Apr 2020 16:58:02 -0700
Subject: [Haskell-cafe] ANN: stack-2.3.0.1 release candidate
In-Reply-To: <CACGj5vLLExMvhjhEdK7TDXWMMXGVVii=9TizM3FMQF+Km4_EuA@mail.gmail.com>
References: <CACGj5vLLExMvhjhEdK7TDXWMMXGVVii=9TizM3FMQF+Km4_EuA@mail.gmail.com>
Message-ID: <CACGj5vLDxZjDpGr7ym6jKE_P-3sHLne94gzZsbt-mp+thSOo=A@mail.gmail.com>

I should add: you can download binaries here:
https://github.com/commercialhaskell/stack/releases/tag/v2.3.0.1

On Thu, Apr 2, 2020 at 4:56 PM Emanuel Borsboom <manny at fpcomplete.com> wrote:
>
> ### First release candidate for v2.3
>
> **Changes since v2.1.3**
>
> Release notes:
>
> Major changes:
> * `setup-info-locations` yaml configuration now allows overwriting the
> default locations of `stack-setup-2.yaml`.
>   [#5031](https://github.com/commercialhaskell/stack/pull/5031)
>   [#2983](https://github.com/commercialhaskell/stack/issues/2983)
>   [#2913](https://github.com/commercialhaskell/stack/issues/2913)
>
> * The `setup-info` configuration key now allows overwriting parts of
> the default `setup-info`
>
> * The `--setup-info-yaml` command line flag now may be used in all
> stack commands such as `stack build`, and not only in `stack setup`
>
> * The `--setup-info-yaml` may specify multiple locations for
> `stack-setup.yaml` files.
>
> * The `stack upload` can read first reads environment Variable
> `$HACKAGE_USERNAME` and `$HACKAGE_PASSWORD` if they are missing only
> then asks for `username` or `password`
>
> * Fully remove GHCJS support.
>
> * Remove the `freeze` command. It has been replaced by lock files.
>
> Behavior changes:
> * Remove the deprecated `--stack-setup-yaml` command line argument in
> favor of `--setup-info-yaml`
>   [#2647](https://github.com/commercialhaskell/stack/issues/2647)
>
> * We now recommend checking in generated cabal files for repos. When
> generating lock files for
>   extra-deps that only include `package.yaml` files, a deprecation
> warning will be generated.
>   Also, those packages will no longer be included in the generated lock files.
>   See [#5210](https://github.com/commercialhaskell/stack/issues/5210).
>
> Other enhancements:
> * Add `build-output-timestamps` flag in yaml. Setting it to true
>   prefixes each build log output line with a timestamp.
>
> * Show warning about `local-programs-path` with spaces on windows
>   when running scripts. See
>   [#5013](https://github.com/commercialhaskell/stack/pull/5013)
>
> * Add `ls dependencies json` which will print dependencies as JSON.
>   `ls dependencies --tree`  is now `ls dependencies tree`. See
>   [#4424](https://github.com/commercialhaskell/stack/pull/4424)
>
> * Remove warning for using Stack with GHC 8.8 and Cabal 3.0.
>
> * Allow relative paths in `--setup-info-yaml` and tool paths
>   [#3394](https://github.com/commercialhaskell/stack/issues/3394)
>
> Bug fixes:
>
> * Upgrade `pantry`: module mapping insertions into the database are now atomic.
>   Previously, if you SIGTERMed at the wrong time while running a script, you
>   could end up with an inconsistent database state.
>
> * `--resolver global` doesn't retrieve snapshots list from the internet
>    beause doesn't need it. See
> [#5103](https://github.com/commercialhaskell/stack/issues/5103)
>
> * Fix using relative links in haddocks output.  See
>   [#4971](https://github.com/commercialhaskell/stack/issues/4971).
> * Do not include generated cabal file information in lock files. See
>   [#5045](https://github.com/commercialhaskell/stack/issues/5045).
>
> * Use proper Hoogle executable path when installed automatically. See
>   [#4905](https://github.com/commercialhaskell/stack/issues/4905)
>
> * Fix GHC version for batched package unregistration. See
>   [#4951](https://github.com/commercialhaskell/stack/issues/4951)
>
> * Use Hoogle from the snapshot used and not the latest version. See
>   [#4905](https://github.com/commercialhaskell/stack/issues/4905)
>
> * Resolve "'stty' is not recognized". See
>   [#4901](https://github.com/commercialhaskell/stack/issues/4901)
>
> * Fix missing reconfigure check causing errors when a package gets
>   used in multiple projects. See
>   [#5147](https://github.com/commercialhaskell/stack/issues/5147)

From lemming at henning-thielemann.de  Fri Apr  3 04:21:26 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 3 Apr 2020 06:21:26 +0200 (CEST)
Subject: [Haskell-cafe] How to safely and fast write repa array to a
 file?
In-Reply-To: <BU6nBD07EP-WTdwM3YvhBuUkxQ2JKLZ5lsFcHqbWnlqyXtK0AFR8hlJi0xO9f6mXrNEa0lObMHmeVgHi55ucVYgf2s_asu41RR8VMJFZGbU=@protonmail.com>
References: <BU6nBD07EP-WTdwM3YvhBuUkxQ2JKLZ5lsFcHqbWnlqyXtK0AFR8hlJi0xO9f6mXrNEa0lObMHmeVgHi55ucVYgf2s_asu41RR8VMJFZGbU=@protonmail.com>
Message-ID: <alpine.DEB.2.20.2004030620370.3669@sputnik>


On Thu, 2 Apr 2020, cyberfined via Haskell-Cafe wrote:

> writeImage :: FilePath -> Image -> IO ()
> writeImage path img = bracket (openFile path WriteMode) (hClose) $ \hdl -> B.hPut hdl header >> B.hPut hdl body

Btw. the bracket thing is equivalent to
    withFile path WriteMode

From kramosik at gmail.com  Sat Apr  4 07:53:27 2020
From: kramosik at gmail.com (KS)
Date: Sat, 4 Apr 2020 03:53:27 -0400
Subject: [Haskell-cafe] Efficiency of passing function arguments
Message-ID: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>

Hello everyone,

I was coming from a C++ background and I always wondered if there is a
distinction between pass-by-value and pass-by-reference in Haskell (or
pass-by-thunk? since an argument might be partially evaluated due to
laziness in Haskell).

Is there a way to guarantee that an function argument is passed in an
efficient manner? For example, if we have a data type

data Document
  = Document { title   :: Text
             , author  :: Name
             , content :: Text
             -- and potentially many more
             }
doc = Document {..} -- omitted

and we want to pass doc to a function, we should ideally hope that doc is
not getting duplicated when passing it as an argument. Another example
might be the Reader monad, where we are passing possibly the same
environment to multiple functions. In C++, we could either pass by a
pointer or a reference, but I'm not sure what the best practices are in
Haskell.

The most relevant construct in Haskell seems to be  IORef, though I'm not
sure if this is the correct way to use it. For exmaple, if I want to
pre-load a template document on disk as Text or ByteString into the memory
when the program starts, should I put it in a IORef and pass it into (more
than one) functions or should I pass it into the function directly? Should
I worry about this at all?

This question might be related to the implementation of the ghc compiler.
It would be better if anyone could shed some lights on the implementation
details.

Thank you,
Kram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200404/c734ece7/attachment.html>

From lemming at henning-thielemann.de  Sat Apr  4 08:02:19 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 4 Apr 2020 10:02:19 +0200 (CEST)
Subject: [Haskell-cafe] Efficiency of passing function arguments
In-Reply-To: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>
References: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2004040958330.3975@sputnik>


On Sat, 4 Apr 2020, KS wrote:

> and we want to pass doc to a function, we should ideally hope that doc 
> is not getting duplicated when passing it as an argument.

In Haskell, values are immutable and thus there is no need to copy. Values 
and parameters are always references. Due to laziness a value references a 
union. This union is in the beginning a generating function and once the 
value gots evaluated, it is the computed value.

From godzbanebane at gmail.com  Sat Apr  4 08:31:41 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Sat, 4 Apr 2020 11:31:41 +0300
Subject: [Haskell-cafe] Efficiency of passing function arguments
In-Reply-To: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>
References: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>
Message-ID: <CABT0e9qobOO6Jx9J9gvxzQWtx-Mron3tquOhgVv6yEdEo5mnzg@mail.gmail.com>

Hi!

What the other person said - passing an argument should always be "by
reference", since there is no danger in doing otherwise.
However, "copying" does happen when you deconstruct and reconstruct a value.
For example, consider this idList:
```
idList :: [a] -> [a]
idList [] = []
idList (x:xs) = x : idList xs
```
Semantically this is the same as (a stricter) id, but we're deconstructing
values and then constructing other ones (putting them in new boxes), so in
effect, we're "copying" the input list.
I'm not sure if ghc will do some magic optimisation to transform this
particular function into an operation with no copying, but you can imagine
something more complicated like map/foldr/reverse etc where it isn't
possible (although other stuff like fusion is, to eliminate intermediate
results from composed maps for example).

=======
Georgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200404/216714bc/attachment.html>

From leo at lpw25.net  Sat Apr  4 09:41:11 2020
From: leo at lpw25.net (Leo White)
Date: Sat, 04 Apr 2020 10:41:11 +0100
Subject: [Haskell-cafe] ML Family Workshop 2020: Call for presentations
Message-ID: <bd34fd59-b33d-40da-9efb-61ba1ee9a471@www.fastmail.com>

We are happy to invite submissions to the ML Family Workshop 2020,
to be held during the ICFP conference week on Thursday,
August 27th.

The ML family workshop warmly welcomes submission touching
on the programming languages traditionally seen as part of the
"ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore,
MetaOCaml, etc.). The scope of the workshop includes all aspects
of the design, semantics, theory, application, implementation,
and teaching of the members of the ML family. We also encourage
presentations from related languages (such as Haskell, Scala,
Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange
experience of further developing ML ideas.

Currently, the workshop is still scheduled to go ahead as planned
in Jersey City, however it is likely that the ML workshop will
end up being a virtual workshop this year. Either way provisions
will be made to allow speakers to present their work remotely.

See our detailed CFP online on the ICFP website:

  https://icfp20.sigplan.org/home/mlfamilyworkshop-2020

Important dates
---------------

- Friday 15th May (any time zone): Abstract submission deadline
- Friday 26th June: Author notification
- Thursday 27th August: ML Family Workshop

Program committee
-----------------

- Youyou Cong (Tokyo Institute of Technology)
- Gowtham Kaki (Purdue University)
- Neel Krishnaswami (University of Cambridge)
- Daan Leijen (Microsoft Research)
- Koko Muroya (Kyoto University)
- Atsushi Ohori (Tohoku University)
- Jonathan Protzenko (Microsoft Research)
- Gabriel Radanne (INRIA)
- Claudio Russo (Dfinity)
- Leo White (Jane Street) (Chair)
- Jeremy Yallop (University of Cambridge)

Submission details
------------------

See the online CFP for the details on the expected submission format.

Submissions must be uploaded to the workshop submission website

  https://ml2020.hotcrp.com/

before the submission deadline.

From will.yager at gmail.com  Sat Apr  4 10:37:07 2020
From: will.yager at gmail.com (Will Yager)
Date: Sat, 4 Apr 2020 03:37:07 -0700
Subject: [Haskell-cafe] Efficiency of passing function arguments
In-Reply-To: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>
References: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>
Message-ID: <FC74483C-41AA-4D38-ADFF-208CA4E1317A@gmail.com>

As a slight refinement on the previous responses,

* you do not need to worry about this at all, at least not in the direction you’re thinking. 
* you don’t need to use IORef or anything for efficiency - almost everything is passed by reference already (one benefit of immutable data)
* GHC can automatically switch to pass-by-value when appropriate 

In fact, the tricky part is actually getting your program to *stop* passing by reference when there’s a performance gain associated with pass-by-value. 

My mental model of GHC’s rule for when to use pass-by-value is approximately 

* it won’t change the semantics of the problem
* the value is small

E.g. if we’re writing a very fast small loop that operates over Int64s, there’s no point passing by reference when a value is the same size as a pointer anyway, and we can avoid extraneous dereferences and heap allocations. 

The interesting part is “won’t change the semantics of the program”. That basically boils down to the fact that pass-by-value is strict, so often times all you need to do is tell GHC that a function is strict on some of its arguments and GHC can choose to make those arguments PBV. See BangPatterns.  

Haskellers don’t normally use the terminology PBV and PBR, however, but rather “unboxed” and “boxed” (referring to the values themselves). 

Will


> On Apr 4, 2020, at 12:55 AM, KS <kramosik at gmail.com> wrote:
> 
> Should I worry about this at all?

From compl.yue at icloud.com  Sat Apr  4 14:08:28 2020
From: compl.yue at icloud.com (Compl Yue)
Date: Sat, 4 Apr 2020 22:08:28 +0800
Subject: [Haskell-cafe] How to safely and fast write repa array to a
	file?
In-Reply-To: <BU6nBD07EP-WTdwM3YvhBuUkxQ2JKLZ5lsFcHqbWnlqyXtK0AFR8hlJi0xO9f6mXrNEa0lObMHmeVgHi55ucVYgf2s_asu41RR8VMJFZGbU=@protonmail.com>
References: <BU6nBD07EP-WTdwM3YvhBuUkxQ2JKLZ5lsFcHqbWnlqyXtK0AFR8hlJi0xO9f6mXrNEa0lObMHmeVgHi55ucVYgf2s_asu41RR8VMJFZGbU=@protonmail.com>
Message-ID: <33885172-bfda-53d0-d012-f14d153b645e@icloud.com>

I have a feel that given the result data is dense and already in RAM, 
your approach should already be the most safe & efficient one, though 
benchmarks may favor other slight variants with different sized arrays, 
the speed diffs should be neglectable.

But from overall architecture, I suggest it can be even more proficient 
to mmap the data file into foreign ptr in order to back the array to 
receive computation result, with virtual memory, then after the 
computation, do `msync` to guarantee the data is written to non-volatile 
storage. This puts no burden at GC in the first place, and of course 
demands no further memory pinning etc. at all, by just leveraging the 
os' virtual memory system (and modern file systems that tightly coupled 
with it) for its designed purpose.

I'm myself doing a PoC of an array database thing, I'm currently using 
the vector-mmap package's routine to finish the PoC. But the depended 
mmap package lacks `msync`,  and a test case suggests resource leakage 
with GHC 8.6.5, so a stable solution is yet to be worked out ahead the way.

Btw, when you have more then 10k such array files to mmap, you'll hit 
another limit - nofile for Linux, I used to implement a FUSE filesystem 
providing virtual large data files viewing many small files on the 
remote storage server, but written in Go, and am porting that to GHC in 
the near future.


On 2020/4/3 上午3:25, cyberfined via Haskell-Cafe wrote:
> Hello, all. I decide to write parallel ray tracer on haskell with 
> repa. Now, to save repa array to file I use dirty trick casting repa 
> array ptr to bytestring with fromForeignPtr and then writing it to 
> file with hPut. It looks something like that:
>
> import qualified Data.Array.Repa as R
> import qualified Data.Array.Repa.Repr.ForeignPtr as RF
>
> import qualified Data.ByteString as B
> import qualified Data.ByteString.Char8 as BC
> import qualified Data.ByteString.Internal as BI
>
> type Image = Array F DIM2 Pixel
>
> writeImage :: FilePath -> Image -> IO ()
> writeImage path img = bracket (openFile path WriteMode) (hClose) $ 
> \hdl -> B.hPut hdl header >> B.hPut hdl body
>   where Z :. h :. w = R.extent img
>         header = BC.pack $ "P6\n" ++ show w ++ ' ':show h ++ "\n255\n"
>         body = BI.fromForeignPtr(castForeignPtr $ RF.toForeignPtr img) 
> 0 (w*h*3)
>
> My question is: how to write repa array to file safely and fast?
>
> _______________________________________________
> 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/20200404/24aab54a/attachment.html>

From kramosik at gmail.com  Sat Apr  4 17:32:11 2020
From: kramosik at gmail.com (KS)
Date: Sat, 4 Apr 2020 13:32:11 -0400
Subject: [Haskell-cafe] Efficiency of passing function arguments
In-Reply-To: <FC74483C-41AA-4D38-ADFF-208CA4E1317A@gmail.com>
References: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>
 <FC74483C-41AA-4D38-ADFF-208CA4E1317A@gmail.com>
Message-ID: <CAFXAJKvv8VgWtsQ7zmUdq819npNMGARaNVsPdJ7BNaDpt2hdcg@mail.gmail.com>

Thanks for everyone's answers.

The concept of "boxed" and "unboxed" types seems to be in the correct
direction. I found some relevant sections in GHC's user guide:
https://downloads.haskell.org/~ghc/8.8.3/docs/users_guide.pdf#page=269 . It
might be an interesting read.

Best,
Kram

On Sat, Apr 4, 2020 at 6:37 AM Will Yager <will.yager at gmail.com> wrote:

> As a slight refinement on the previous responses,
>
> * you do not need to worry about this at all, at least not in the
> direction you’re thinking.
> * you don’t need to use IORef or anything for efficiency - almost
> everything is passed by reference already (one benefit of immutable data)
> * GHC can automatically switch to pass-by-value when appropriate
>
> In fact, the tricky part is actually getting your program to *stop*
> passing by reference when there’s a performance gain associated with
> pass-by-value.
>
> My mental model of GHC’s rule for when to use pass-by-value is
> approximately
>
> * it won’t change the semantics of the problem
> * the value is small
>
> E.g. if we’re writing a very fast small loop that operates over Int64s,
> there’s no point passing by reference when a value is the same size as a
> pointer anyway, and we can avoid extraneous dereferences and heap
> allocations.
>
> The interesting part is “won’t change the semantics of the program”. That
> basically boils down to the fact that pass-by-value is strict, so often
> times all you need to do is tell GHC that a function is strict on some of
> its arguments and GHC can choose to make those arguments PBV. See
> BangPatterns.
>
> Haskellers don’t normally use the terminology PBV and PBR, however, but
> rather “unboxed” and “boxed” (referring to the values themselves).
>
> Will
>
>
> > On Apr 4, 2020, at 12:55 AM, KS <kramosik at gmail.com> wrote:
> >
> > Should I worry about this at all?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200404/e9f28717/attachment.html>

From ietf-dane at dukhovni.org  Sat Apr  4 19:03:03 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 4 Apr 2020 15:03:03 -0400
Subject: [Haskell-cafe] Efficiency of passing function arguments
In-Reply-To: <CABT0e9qobOO6Jx9J9gvxzQWtx-Mron3tquOhgVv6yEdEo5mnzg@mail.gmail.com>
References: <CAFXAJKvjsRwdp-avVoyUBG0eb0-ShMbg9chaZafzQ-neOODkaA@mail.gmail.com>
 <CABT0e9qobOO6Jx9J9gvxzQWtx-Mron3tquOhgVv6yEdEo5mnzg@mail.gmail.com>
Message-ID: <20200404190303.GR41308@straasha.imrryr.org>

On Sat, Apr 04, 2020 at 11:31:41AM +0300, Georgi Lyubenov wrote:

> For example, consider this idList:
> ```
> idList :: [a] -> [a]
> idList [] = []
> idList (x:xs) = x : idList xs
> ```
> Semantically this is the same as (a stricter) id, but we're deconstructing
> values and then constructing other ones (putting them in new boxes), so in
> effect, we're "copying" the input list.

But the function is not in fact strict, and so if one uses the value of
"idList xs" no more than once to traverse the list (print it, fold it, ...)
the list *as a whole* is never copied, and total memory used remains small
even for very long lists (that are lazily generated).

That said, interposing idList betweent a fold and the input list
increates the amount of GC work that ultimately takes place to cleanup
the per-element thunks.  The elements themselves are not copied, but the
enclosing lazy thunks are somewhat larger as a result of hiding the real
list behind idList.

> I'm not sure if ghc will do some magic optimisation to transform this
> particular function into an operation with no copying, but you can imagine
> something more complicated like map/foldr/reverse etc where it isn't
> possible (although other stuff like fusion is, to eliminate intermediate
> results from composed maps for example).

Construction of copies of lists typically happens when you traverse them
more than once.  Otherwise you just force each element in turn (possibly
via a more complex thunk that still produces that element).

-- 
    Viktor.

--- Folding 100 million Ints without idList:

       8,000,045,248 bytes allocated in the heap
             771,488 bytes copied during GC
              44,504 bytes maximum residency (2 sample(s))
              29,224 bytes maximum slop
                   0 MB total memory in use (0 MB lost due to fragmentation)

                                         Tot time (elapsed)  Avg pause  Max pause
      Gen  0      7658 colls,     0 par    0.022s   0.022s     0.0000s    0.0018s
      Gen  1         2 colls,     0 par    0.001s   0.001s     0.0004s    0.0007s

      INIT    time    0.001s  (  0.001s elapsed)
      MUT     time    0.981s  (  0.982s elapsed)
      GC      time    0.023s  (  0.023s elapsed)
      EXIT    time    0.000s  (  0.000s elapsed)
      Total   time    1.005s  (  1.005s elapsed)

      %GC     time       0.0%  (0.0% elapsed)

      Alloc rate    8,153,859,656 bytes per MUT second

      Productivity  97.6% of total user, 97.7% of total elapsed

--- Folding 100 million Ints with idList:

      12,800,039,208 bytes allocated in the heap
           1,701,952 bytes copied during GC
              44,504 bytes maximum residency (2 sample(s))
              29,224 bytes maximum slop
                   0 MB total memory in use (0 MB lost due to fragmentation)

                                         Tot time (elapsed)  Avg pause  Max pause
      Gen  0     12206 colls,     0 par    0.030s   0.029s     0.0000s    0.0007s
      Gen  1         2 colls,     0 par    0.001s   0.001s     0.0004s    0.0007s

      INIT    time    0.000s  (  0.000s elapsed)
      MUT     time    1.484s  (  1.485s elapsed)
      GC      time    0.031s  (  0.030s elapsed)
      EXIT    time    0.000s  (  0.000s elapsed)
      Total   time    1.516s  (  1.516s elapsed)

      %GC     time       0.0%  (0.0% elapsed)

      Alloc rate    8,622,777,676 bytes per MUT second

      Productivity  97.9% of total user, 98.0% of total elapsed


From jack at jackkelly.name  Sun Apr  5 06:23:28 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Sun, 05 Apr 2020 16:23:28 +1000
Subject: [Haskell-cafe] Looking for a library for DerivingVia idioms
Message-ID: <87zhbqzc0v.fsf@jackkelly.name>

Hello Cafe,

Here is a problem a friend (CC'd - please include him in replies) and I
wanted to solve using DerivingVia. We have a solution (below). I'm
wondering whether a library for these newtypes exists, and if not,
whether it should.

This email is Literate Haskell.

The problem: given two types `Foo` and `Bar`, and an injection
`foo2bar :: Foo -> Bar`, use DerivingVia to derive instances for
`Foo` in terms of `Bar`.

> {-# LANGUAGE DerivingVia, MultiParamTypeClasses #-}
> {-# LANGUAGE ScopedTypeVariables, TypeOperators #-}
>
> import Data.Function (on)
> import Data.Coerce (coerce)
>
> data Foo = Foo deriving Eq via (Foo `InjectedInto` Bar)
> data Bar = Bar deriving Eq
>
> foo2bar :: Foo -> Bar
> foo2bar Foo = Bar

Section 4.3 of the DerivingVia paper[1] shows how to use a newtype
wrapper to derive instances for one type in terms of another, so long as
their generic representation is the same. We can use the same technique.

We need a newtype that's representationally equal to `a`, to pass to
DerivingVia:

> newtype InjectedInto a b = InjectedInto a

We also need a class, so that we can find our injection given the type:

> class Injective a b where
>   -- Law: to x = to y => x = y
>   to :: a -> b
>
> instance Injective Foo Bar where
>   to = foo2bar

We need an instance that uses the InjectedInto newtype:

> instance (Eq b, Injective a b) => Eq (a `InjectedInto` b) where
>   (==) = (==) `on` (to :: a -> b) . coerce

The `deriving Eq via (Foo `InjectedInto` Bar)` above compiled
successfully, so everything seems to work well. I'm wondering:

1. Is a library collecting useful DerivingVia wrappers?

2. If not, suppose I wanted to stand up such a library. Is there a
   canonical library providing classes like `Injection`? I found the
   `type-iso` package, which provides an `Injective` typeclass[2], but
   it has few revdeps and a dubious instance
   Default a => Injective (Maybe b) (Either a b).

3. What about DerivingVia for types not of kind `Type`? It might be
   possible to repeat this structure one level up for `Eq1` &c. Is it
   worth supporting `Eq1` etc in a world with QuantifiedConstraints?

4. Is there a better name than `InjectedInto`? It doesn't scan
   well. A type operator, perhaps?

Thanks for reading. I look foward to your responses.

-- Jack

[1]: https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf
[2]: https://hackage.haskell.org/package/type-iso-1.0.1.0/docs/Data-Types-Injective.html#t:Injective

From w.s.swierstra at uu.nl  Mon Apr  6 07:47:37 2020
From: w.s.swierstra at uu.nl (Wouter Swierstra)
Date: Mon, 6 Apr 2020 09:47:37 +0200
Subject: [Haskell-cafe] Call for participation: Utrecht AFP Summer School
Message-ID: <20200406074737.GM22409@x1>


 
           SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING

              Utrecht, the Netherlands, 06-10 July 2020

                        http://www.afp.school

# Call for Participation

## About

The Advanced Functional Programming summer school has been running for
more than ten years. We aim to educate aspiring Haskell programmers
beyond the basic material covered by many textbooks.

We have decided to advertise the Summer School and accept new
registrations for the moment, but we are monitoring the situation with
COVID-19 carefully. All the Utrecht Summer Schools offer participants
a full refund of their registration fee if they decide to cancel their
registration.

The lectures will cover several more advanced topics regarding the
theory and practice of Haskell programming, including topics such as:

  * lambda calculus;
  * monads and monad transformers;
  * lazy evaluation;
  * generalized algebraic data types;
  * type families and type-level programming;
  * concurrency and parallelism.

The summer school consists of a mix of lectures, labs, and a busy
social program.

## Lecturers

Utrecht staff:
* Gabriele Keller
* Trevor McDonell
* Wouter Swierstra

## Prerequisites

We expect students to have a basic familiarity with Haskell
already. You should be able to write recursive functions over
algebraic data types, such as lists and trees. There is a great deal
of material readily available that covers this material. If you've
already started learning Haskell and are looking to take your
functional programming skills to the next level, this is the course
for you.

Soft registration deadline: 1 July, 2020
School: 06-10 July, 2020

## Costs
 
  1700 euro - Housing and registration
  1500 euro - Registration only
 
We offer a 1000 discount for students and staff members affiliated with
a university or other non-profit organization.
    
## Scholarships
  
If you're struggling to finance your trip to Utrecht, please let us
know. We have a very limited number of scholarships or discounts
available for students that would not be able to attend otherwise,
especially for women and under-represented minorities.

## Further information
 
Further information, including instructions on how to register, is
available on our website:

  http://www.afp.school
  
  

From w.s.swierstra at uu.nl  Mon Apr  6 09:34:07 2020
From: w.s.swierstra at uu.nl (Wouter Swierstra)
Date: Mon, 6 Apr 2020 11:34:07 +0200
Subject: [Haskell-cafe] Two PhD positions in Utrecht
Message-ID: <20200406093407.GV22409@x1>


==============================================================
             Two PhD positions in functional programming
==============================================================

The Department of Information and Computing Sciences at Utrecht
University is currently advertising two PhD positions in
Functional Programming. The candidates will join the Intelligent
Systems group, working with Johan Jeuring, Gabriele Keller, and
Wouter Swierstra.

Besides research, the successful candidate will be expected to
help supervise MSc students and assist in the teaching of
courses.

The positions should be filled by September 2020, although the exact
starting date is negotiable.

---------------------------------
Research topics
---------------------------------

These two positions are tied to two specific topics.

* Programming tutors for Functional Languages (Johan Jeuring)

The focus of the position is on designing new technologies to support
students working in an intelligent tutoring system for functional
programming. We expect to use techniques from dependently typed
programming, refinement types, program synthesis, automated theorem
proving, and more to analyse student programs, and to help students in
taking the next step when developing a program. The candidate will
investigate the design and use of multiple technologies for this
purpose, add them to Ask-Elle, our intelligent tutoring system,
perform experiments with the system, and improve the technologies
based on the outcome of the experiments.

* Compiler verification for a smart contract language (Wouter
  Swierstra & Gabriele Keller)

This project aims to develop a certifying compiler for Plutus Tx, a
subset of the purely functional language Haskell that is used to
implement smart contracts for the Cardano blockchain. The Plutus smart
contract framework is being developed by IOHK for Cardano and the
present project is a joint effort of IOHK and Utrecht University. The
Plutus Tx compiler is based on the GHC Haskell compiler and adds a
translation step from GHC Core to a minimal lambda calculus. Programs
in this lambda calculus are executed during transaction validation in
a sandboxed execution environment in a manner that is crucial to the
security of the blockchain. This project aims to formalise the
semantics of the languages involved, to reason about the
transformation and optimisation steps that the compiler performs, and
finally, to generate a proof object certifying the correctness of the
generated code together with that code.

---------------------------------
What we are looking for
---------------------------------

The ideal candidates should have a degree in Computer Science, be
highly motivated, speak and write English well, and be proficient in
producing scientific reports. Furthermore, candidates should be able
to demonstrate experience with functional programming languages, such
as Haskell, OCaml, ML, Agda, Idris, or Coq.

---------------------------------
What we offer
---------------------------------

The candidates are offered a full-time position for four or five
years, depending on the teaching load. The gross salary ranges between
€2,325 in the first year and €2,972 in the fourth year per month for
full-time employment. A part-time position of at least 0.8 fte may
also be possible. The salary is supplemented with a holiday bonus of
8% and an end-of-year bonus of 8.3% per year. The position also
includes a generous allocation of fully-paid vacation days. In
addition we offer: a pension scheme, partially paid parental leave,
and flexible employment conditions. Conditions are based on the
Collective Labour Agreement Dutch Universities. The research group
will provide the candidate with necessary support on all aspects of
the project. More information is available on the website:

  Terms and employment: http://bit.ly/1elqpM7

Utrecht is consistently ranked as one of the best places in the world
to live.

---------------------------------
How to apply
---------------------------------

To apply please attach a letter of motivation, a curriculum vitae, and
(email) addresses of two referees. Make sure to also include a
transcript of the courses you have followed (at bachelor and master
level), with the grades you obtained, and to include a sample of your
scientific writing, such as your MSc or BSc thesis.

It is possible to apply for this position if you are close to
obtaining your undergraduate degree. In that case include a letter of
your supervisor with an estimate of your progress, and do not forget
to include at least a sample of your technical writing skills.

The application deadline for the first position closes on April
29th. You can apply through the University's website:

https://www.uu.nl/en/organisation/working-at-utrecht-university/jobs/5-year-phd-candidate-position-in-intelligent-tutoring-systems-for-functional-programming-10-fte

The application for the second position is not yet open -- but feel
free to contact me directly if you're interested.

If you're still unsure about the topic, feel free to apply using the
link above; we're happy to discuss which topic fits your interests
best during the application process.

From capn.freako at gmail.com  Mon Apr  6 17:07:51 2020
From: capn.freako at gmail.com (David Banas)
Date: Mon, 6 Apr 2020 10:07:51 -0700
Subject: [Haskell-cafe] New stack.yaml.lock file to master source repo?
Message-ID: <CD384F9D-8BD8-44C5-86B7-E6FB850E9403@gmail.com>

What’s the general consensus on whether or not the new stack.yaml.lock file should be stored in the master source repo.?

Thanks,
-db


From lysxia at gmail.com  Mon Apr  6 17:53:18 2020
From: lysxia at gmail.com (Li-yao Xia)
Date: Mon, 6 Apr 2020 13:53:18 -0400
Subject: [Haskell-cafe] Looking for a library for DerivingVia idioms
In-Reply-To: <87zhbqzc0v.fsf@jackkelly.name>
References: <87zhbqzc0v.fsf@jackkelly.name>
Message-ID: <4272cee2-a801-afc4-e926-626bd44a3157@gmail.com>

Hi Jack and Luke,

It seems you can generalize this scheme, from deriving via a "canonical 
injection" to deriving via any user-supplied function. The class 
"Injective" could thus be replaced with a more general one:

     class Function a b f where
       apply :: a -> b

Instead of writing instances "Injective a b", one would write instances 
"Function a b Inject" (the indices are in this order because I am 
imagining that a proper thing to do would be for the kind of f to depend 
on a and b), where Inject is a "(defunctionalized) symbol", concretely 
defined as a dummy data type:

     data Inject

Then there will be a newtype to take a function (a -> b) with which to 
transform Eq dictionaries Eq b -> Eq a: Comap seems like a fitting name. 
So you could write:

     data Foo = Foo deriving Eq via (Comap Foo Bar Inject)

Provided

     newtype Comap a b f = Comap a

     instance Eq b => Eq (Comap a b f) where
       (==) = (==) `on` apply @a @b @f

     instance Function Foo Bar Inject where
       apply = foo2bar

One advantage of this generalization is that there is no longer a notion 
of globally canonical injection as with the Injective class, which is 
quite dubious to begin with. Instead, users can declare their own Inject 
symbol (or whatever name is appropriate) that makes sense only within 
their own projects.

The singletons library has some applicable machinery here to compose 
functions while staying at the type level (this may have only rare 
applications). The Function class above is equivalent to a combination 
of SingI (implicitly construct a singleton value) and SingKind (unrefine 
a singleton to a plain type).

Cheers,
Li-yao

On 4/5/20 2:23 AM, Jack Kelly wrote:
> Hello Cafe,
> 
> Here is a problem a friend (CC'd - please include him in replies) and I
> wanted to solve using DerivingVia. We have a solution (below). I'm
> wondering whether a library for these newtypes exists, and if not,
> whether it should.
> 
> This email is Literate Haskell.
> 
> The problem: given two types `Foo` and `Bar`, and an injection
> `foo2bar :: Foo -> Bar`, use DerivingVia to derive instances for
> `Foo` in terms of `Bar`.
> 
>> {-# LANGUAGE DerivingVia, MultiParamTypeClasses #-}
>> {-# LANGUAGE ScopedTypeVariables, TypeOperators #-}
>>
>> import Data.Function (on)
>> import Data.Coerce (coerce)
>>
>> data Foo = Foo deriving Eq via (Foo `InjectedInto` Bar)
>> data Bar = Bar deriving Eq
>>
>> foo2bar :: Foo -> Bar
>> foo2bar Foo = Bar
> 
> Section 4.3 of the DerivingVia paper[1] shows how to use a newtype
> wrapper to derive instances for one type in terms of another, so long as
> their generic representation is the same. We can use the same technique.
> 
> We need a newtype that's representationally equal to `a`, to pass to
> DerivingVia:
> 
>> newtype InjectedInto a b = InjectedInto a
> 
> We also need a class, so that we can find our injection given the type:
> 
>> class Injective a b where
>>    -- Law: to x = to y => x = y
>>    to :: a -> b
>>
>> instance Injective Foo Bar where
>>    to = foo2bar
> 
> We need an instance that uses the InjectedInto newtype:
> 
>> instance (Eq b, Injective a b) => Eq (a `InjectedInto` b) where
>>    (==) = (==) `on` (to :: a -> b) . coerce
> 
> The `deriving Eq via (Foo `InjectedInto` Bar)` above compiled
> successfully, so everything seems to work well. I'm wondering:
> 
> 1. Is a library collecting useful DerivingVia wrappers?
> 
> 2. If not, suppose I wanted to stand up such a library. Is there a
>     canonical library providing classes like `Injection`? I found the
>     `type-iso` package, which provides an `Injective` typeclass[2], but
>     it has few revdeps and a dubious instance
>     Default a => Injective (Maybe b) (Either a b).
> 
> 3. What about DerivingVia for types not of kind `Type`? It might be
>     possible to repeat this structure one level up for `Eq1` &c. Is it
>     worth supporting `Eq1` etc in a world with QuantifiedConstraints?
> 
> 4. Is there a better name than `InjectedInto`? It doesn't scan
>     well. A type operator, perhaps?
> 
> Thanks for reading. I look foward to your responses.
> 
> -- Jack
> 
> [1]: https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf
> [2]: https://hackage.haskell.org/package/type-iso-1.0.1.0/docs/Data-Types-Injective.html#t:Injective
> _______________________________________________
> 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 andrew.thaddeus at gmail.com  Mon Apr  6 17:59:13 2020
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Mon, 6 Apr 2020 13:59:13 -0400
Subject: [Haskell-cafe] New stack.yaml.lock file to master source repo?
In-Reply-To: <CD384F9D-8BD8-44C5-86B7-E6FB850E9403@gmail.com>
References: <CD384F9D-8BD8-44C5-86B7-E6FB850E9403@gmail.com>
Message-ID: <7FB59F8E-7BE9-4B47-82A4-1281C3C99AEE@gmail.com>

Files that pin versions of every transitive dependency (cabal’s freeze file and stack’s lock file) are usually for applications, not libraries. This is the same in basically every ecosystem. If you have an application, sure, commit it, and then it’s less likely that people run into trouble when building your application. But if it’s a library, don’t do that.

Sent from my iPhone

> On Apr 6, 2020, at 1:08 PM, David Banas <capn.freako at gmail.com> wrote:
> 
> What’s the general consensus on whether or not the new stack.yaml.lock file should be stored in the master source repo.?
> 
> Thanks,
> -db
> 
> _______________________________________________
> 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 trupill at gmail.com  Tue Apr  7 12:41:47 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 7 Apr 2020 14:41:47 +0200
Subject: [Haskell-cafe] Uppercase OverloadedLabels
Message-ID: <CAHnFXOsPM=JpZBT30Zv5esWdN7=EyUwj9NO3JJ9i43PFjrDmUw@mail.gmail.com>

Dear Haskell-Café / GHC devs,
Is there any reason why the `OverloadedHaskell` extension does not work
with labels starting with an uppercase letter?

Kind regards,
Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200407/5a1306b9/attachment.html>

From godzbanebane at gmail.com  Tue Apr  7 12:59:48 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Tue, 7 Apr 2020 15:59:48 +0300
Subject: [Haskell-cafe] Uppercase OverloadedLabels
In-Reply-To: <CAHnFXOsPM=JpZBT30Zv5esWdN7=EyUwj9NO3JJ9i43PFjrDmUw@mail.gmail.com>
References: <CAHnFXOsPM=JpZBT30Zv5esWdN7=EyUwj9NO3JJ9i43PFjrDmUw@mail.gmail.com>
Message-ID: <CABT0e9o1L5nRTuZcFx+gF=o48Wdd8XPNUkQZOpicyuxCO1gWAg@mail.gmail.com>

Hi!

I believe these two answer your question mostly (?):
https://gitlab.haskell.org/ghc/ghc/issues/11671
https://github.com/ghc-proposals/ghc-proposals/pull/170

=======
Georgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200407/8fd8b9be/attachment.html>

From klebinger.andreas at gmx.at  Wed Apr  8 08:19:23 2020
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Wed, 8 Apr 2020 10:19:23 +0200
Subject: [Haskell-cafe] Targeting old Windows versions
Message-ID: <efb79622-53b1-ed27-64e3-e6eb0c2b37ee@gmx.at>

Hello devs,

GHC is planning to use the Large Address Space mode of allocation for
future releases on windows.
See https://gitlab.haskell.org/ghc/ghc/issues/12576

This is a significant optimization for the GC and well tested as we use
it on Linux already.

However it will regress memory useage on versions of windows *older*
than Windows 8.1/Sever 2012.

Please let us know if you are targeting older versions than that either
by responding to the mailing list,
commenting on the ticket or contacting me directly if you have privacy
concerns.

Depending on how many people are affected by this change we might
consider measures to reduce the impact.

Cheers,
Andreas

From amindfv at gmail.com  Sat Apr 11 20:23:52 2020
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sat, 11 Apr 2020 16:23:52 -0400
Subject: [Haskell-cafe] Attoparsec: match many, skipping rest
Message-ID: <D7FE2F89-020A-4FBC-A677-99E8B64A09A7@gmail.com>

Say I've got an Attoparsec parser like:

    p = string "prio:" *> digit

And some text, e.g.

    s = "this is just a prio:5 example, I'd prio:6 very much like to prio:4 parse"

What's the most idiomatic way to apply p to s so that I get out a list ['5', '6', '4']?

Thanks,
Tom

From godzbanebane at gmail.com  Sat Apr 11 21:09:04 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Sun, 12 Apr 2020 00:09:04 +0300
Subject: [Haskell-cafe] Attoparsec: match many, skipping rest
In-Reply-To: <D7FE2F89-020A-4FBC-A677-99E8B64A09A7@gmail.com>
References: <D7FE2F89-020A-4FBC-A677-99E8B64A09A7@gmail.com>
Message-ID: <CABT0e9r3etOsZ+ghxN74T67BnD-jrmMV+UpCKnzW2OwzuBXRfA@mail.gmail.com>

Hi!

There was "recently" a family libraries published for exactly this purpose:
https://github.com/jamesdbrock/replace-attoparsec
In the past I've done it character by character, but I definitely wasn't
caring about performance then. I would assume the replace-* family of
libraries are more efficient for the purpose

=======
Georgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200412/536c42ef/attachment.html>

From blamario at rogers.com  Sun Apr 12 19:07:07 2020
From: blamario at rogers.com (Mario)
Date: Sun, 12 Apr 2020 15:07:07 -0400
Subject: [Haskell-cafe] Attoparsec: match many, skipping rest
In-Reply-To: <D7FE2F89-020A-4FBC-A677-99E8B64A09A7@gmail.com>
References: <D7FE2F89-020A-4FBC-A677-99E8B64A09A7@gmail.com>
Message-ID: <71f0ee2a-64c4-40e2-bd35-df0f2ca7d87f@rogers.com>

On 2020-04-11 4:23 p.m., amindfv at gmail.com wrote:
> Say I've got an Attoparsec parser like:
>
>      p = string "prio:" *> digit
>
> And some text, e.g.
>
>      s = "this is just a prio:5 example, I'd prio:6 very much like to prio:4 parse"
>
> What's the most idiomatic way to apply p to s so that I get out a list ['5', '6', '4']?


I'd go with


many (many (notFollowedBy (string "prio:")

             *> anyChar *> skipWhile (/= 'p')

       *> string "prio:" *> digit)



From dyaitskov at gmail.com  Mon Apr 13 05:46:53 2020
From: dyaitskov at gmail.com (Daneel Yaitskov)
Date: Sun, 12 Apr 2020 22:46:53 -0700
Subject: [Haskell-cafe] Eff verbose/ambiguous/type safety
Message-ID: <CACNT4y73ejcprD_X8Axk=P=H8s7oe8dkBNKZsiGVteSjA0vK8w@mail.gmail.com>

Hello Group,

Recently I discovered for my self an alternative for monad
transformers - extensible effects.

http://okmij.org/ftp/Haskell/extensible/

Overall it is really cool and Eff1.hs started working right away,
but I noticed a problem with mixing several effects in 1 function.
Type checker requires pretty verbose type signature, which looks
unreasonable plus
the error reported to a beginner developer is not intuitive.

So my questions are:
    - why it happens?
    - what could I do to get more friendly error message?
    - is there a workaround enforcing GHC make an extra mile and work
without these "extra hints"?
    - any more maintainable Eff implementations?

Here it an example I wish should working.

    $ stack gchi Eff1.hs
*Eff1 > doLift = lift (putStrLn "EFF!")
*Eff1 > doWrite = tell "HELLO"
*Eff1 > doLiftAndWrite = doLift >> doWrite
*Eff1 > runLift (runWriter doLiftAndWrite)

<interactive>:82:20: error:
    * Couldn't match type `Writer [Char]' with `Lift IO'
        arising from a use of `doLiftAndWrite'
    * In the first argument of `runWriter', namely `doLiftAndWrite'
      In the first argument of `runLift', namely
        `(runWriter doLiftAndWrite)'
      In the expression: runLift (runWriter doLiftAndWrite)

The error message looks unclear, because documentation makes me think
 that Writer and Lift are members of same Eff monad and they are composable and
doLiftAndWrite has been evaluated successfully.

And my workaround:
*Eff1 > runLift $ do { x :: ((), [String]) <- runWriter
doLiftAndWrite; return x; }
EFF!
((),["HELLO"])

Plus GHCi swallows a type error:
*Eff1 > badCast = do { x :: ((), [Int]) <- runWriter doLiftAndWrite; return x; }
*Eff1 > :t badCast
badCast
  :: (MemberU2 Lift (Lift IO) r,
      OpenUnion52.FindElem (Writer [Char]) r) =>
     Eff r ((), [Int])

Definitely Extensible Effects are more flexible that MTL, but compile
type safety looks jeopardized. Type verbosity overhead is kind of
acceptable, but having possibility of run-time errors is too big price
for flexibility.



-- 


Daneel S. Yaitskov

From godzbanebane at gmail.com  Mon Apr 13 07:01:27 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Mon, 13 Apr 2020 10:01:27 +0300
Subject: [Haskell-cafe] Eff verbose/ambiguous/type safety
In-Reply-To: <CACNT4y73ejcprD_X8Axk=P=H8s7oe8dkBNKZsiGVteSjA0vK8w@mail.gmail.com>
References: <CACNT4y73ejcprD_X8Axk=P=H8s7oe8dkBNKZsiGVteSjA0vK8w@mail.gmail.com>
Message-ID: <CABT0e9oXVpTf5t=sEfVWruypCLzSawT2wd_-mEXzbfRodnv_sw@mail.gmail.com>

Hi!

I'm not too familiar with the particular implementation in Eff1.hs but when
working with highly polymorphic Haskell code in general (like here, where
you want your actions to be polymorphic over the effect stack), it's a good
idea to write out everything in a file with type signatures present, so
that you're 100% about what is happening, and there isn't some weird type
defaulting/type families getting stuck business going on.

For other implementations you can take a look at freer-simple, polysemy,
fused-effects, eff.

=======
Georgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200413/94889ad0/attachment.html>

From anthony_clayden at clear.net.nz  Mon Apr 13 23:57:06 2020
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Tue, 14 Apr 2020 11:57:06 +1200
Subject: [Haskell-cafe] Eff verbose/ambiguous/type safety
Message-ID: <CAM7nRYSrcnYpynD95ni8_q2SpuF8mbkLu9HQK5RXuWrNpUNqSQ@mail.gmail.com>

Hi Daneel, welcome

> Recently I discovered for my self an alternative for monad
> transformers - extensible effects.
>
> http://okmij.org/ftp/Haskell/extensible/
>

So straight away a word of warning: the 'ok' there is Oleg Kiselyov,
who has produced many wonderful demonstrations of the power of
Haskell's type system. (HList is anoher inspiration.) Many would say
he has warped the type system beyond what it could reasonably be
expected to achieve. So we measure the brain power needed to
understand type signatures and messages in milli-Olegs.

> Overall it is really cool and Eff1.hs started working right away,
> but I noticed a problem with mixing several effects in 1 function.
> Type checker requires pretty verbose type signature, which looks
> unreasonable plus the error reported to a beginner developer

> is not intuitive.

Extensible effects/all of Oleg's work is not aimed at beginners. I
advise beginners to stay well clear. You can expect enormous,
inscrutable type errors.

I agree with Georgi you should give type signatures everywhere you
can. And your code should be used only by type experts.


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

From tom.schrijvers at cs.kuleuven.be  Tue Apr 14 08:01:43 2020
From: tom.schrijvers at cs.kuleuven.be (Tom Schrijvers)
Date: Tue, 14 Apr 2020 10:01:43 +0200
Subject: [Haskell-cafe] Haskell Symposium 2020 -- Call for Papers: Regular
	track & demos
Message-ID: <CAPB6rfHQPB4fTMsHxV_uk0U4UFetDZk8d-6=AYp4dJ-ut_X8PA@mail.gmail.com>

================================================================================
 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

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

From joshchia at gmail.com  Wed Apr 15 16:40:19 2020
From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=)
Date: Thu, 16 Apr 2020 00:40:19 +0800
Subject: [Haskell-cafe] streaming package: How to demux a stream properly?
Message-ID: <CALxtSbRo0OyRcJzeMNZS1qyhsZc_+rU+TRjdHi9KD_k0FN48Sw@mail.gmail.com>

I have a streaming package question.

Suppose I have a:
Stream (Of (Int, a)) m ()

I would like to demultiplex it into Vector (Stream (Of a) m ()) using the
Int as the index of an item into the Vector of output streams.

How can I do this efficiently (constant memory and linear time)?

Does the following work?
import qualified Streaming.Prelude as SP
import qualified Data.Vector as V

type StreamOf a m r = Stream (Of a) m r

demuxStream :: forall a m. MonadIO m
=> Int -> StreamOf (Int, a) m () -> m (Vector (StreamOf a m ()))
demuxStream numSyms stream =
let emptyStreams = V.replicate numSyms (pure ())
processItem v (iD, x) = V.modify (\vm -> VM.modify vm (>> SP.yield x) iD) v
in SP.fold_ processItem emptyStreams id stream

My guess is that it takes more than constant memory as it goes through the
entire input stream before returning.

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

From tikhon at jelv.is  Wed Apr 15 17:04:32 2020
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Wed, 15 Apr 2020 10:04:32 -0700
Subject: [Haskell-cafe] streaming package: How to demux a stream
	properly?
In-Reply-To: <CALxtSbRo0OyRcJzeMNZS1qyhsZc_+rU+TRjdHi9KD_k0FN48Sw@mail.gmail.com>
References: <CALxtSbRo0OyRcJzeMNZS1qyhsZc_+rU+TRjdHi9KD_k0FN48Sw@mail.gmail.com>
Message-ID: <CAJN5CVJyRSvOJ-72yqP=rCwB-v19x8+auq0ns5SNZ0z7K2MqZA@mail.gmail.com>

I'm not sure it's possible to do that efficiently.

Here's a hypothetical situation: you have a stream with elements tagged as
1 and 2, but none tagged as 0. If somebody applies an operation to the
stream of 0 elements (say stdoutLn), we have to process every single
element—and perform every single effect—in the input stream before we know
that the stream at index 0 is empty. In general, if we apply an operation
to an element of one of the output streams, we'd have to process at minimum
all the input elements up to and including that particular element. The
important thing is that, semantically, the output of your demux operation
is not n independent streams, but n views into a single stream.

It's probably possible to implement a version of this function that doesn't
process the *entire* input stream up-front—it would just process as much of
the input as it needed when you look at any given element in the output—but
it probably needs a different type than just Vector to make it work
correctly, and I'm not sure how to do that. More importantly, the behavior
of this function would still be confusing; it might *look* like you have
several distinct streams, but you'd have to do the effects and store the
results of every single step in the input stream even if you only used one
of your demuxed streams.

Does that explanation make sense? I haven't done much streaming stuff in a
while, so I'm struggling a bit with how to express my intuitions about it.

On Wed, Apr 15, 2020 at 9:42 AM ☂Josh Chia (謝任中) <joshchia at gmail.com> wrote:

> I have a streaming package question.
>
> Suppose I have a:
> Stream (Of (Int, a)) m ()
>
> I would like to demultiplex it into Vector (Stream (Of a) m ()) using the
> Int as the index of an item into the Vector of output streams.
>
> How can I do this efficiently (constant memory and linear time)?
>
> Does the following work?
> import qualified Streaming.Prelude as SP
> import qualified Data.Vector as V
>
> type StreamOf a m r = Stream (Of a) m r
>
> demuxStream :: forall a m. MonadIO m
> => Int -> StreamOf (Int, a) m () -> m (Vector (StreamOf a m ()))
> demuxStream numSyms stream =
> let emptyStreams = V.replicate numSyms (pure ())
> processItem v (iD, x) = V.modify (\vm -> VM.modify vm (>> SP.yield x) iD)
> v
> in SP.fold_ processItem emptyStreams id stream
>
> My guess is that it takes more than constant memory as it goes through the
> entire input stream before returning.
>
> Josh
> _______________________________________________
> 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/20200415/b46f8f86/attachment.html>

From compl.yue at icloud.com  Wed Apr 15 17:42:58 2020
From: compl.yue at icloud.com (YueCompl)
Date: Thu, 16 Apr 2020 01:42:58 +0800
Subject: [Haskell-cafe] streaming package: How to demux a stream
	properly?
In-Reply-To: <CALxtSbRo0OyRcJzeMNZS1qyhsZc_+rU+TRjdHi9KD_k0FN48Sw@mail.gmail.com>
References: <CALxtSbRo0OyRcJzeMNZS1qyhsZc_+rU+TRjdHi9KD_k0FN48Sw@mail.gmail.com>
Message-ID: <84BA647F-E949-49B9-996F-25EFFDE91D03@icloud.com>

Not directly answering your question, but off the top of my head is: 

  why not demux into a Vector (Sink (Of a) m ()) 

Yet I have no idea if there is actually a Sink construct in any stream lib, but the theory is the Vector should contain reactive actions taking elements, rather than containers to collect elements (even thunks of them demand space).

Just my bit of thoughts, I'm definitely novice at it.

Cheers,
Compl


> On 2020-04-16, at 00:40, ☂Josh Chia (謝任中) <joshchia at gmail.com> wrote:
> 
> I have a streaming package question.
> 
> Suppose I have a:
> Stream (Of (Int, a)) m ()
> 
> I would like to demultiplex it into Vector (Stream (Of a) m ()) using the Int as the index of an item into the Vector of output streams.
> 
> How can I do this efficiently (constant memory and linear time)?
> 
> Does the following work?
> import qualified         Streaming.Prelude            as SP
> import qualified         Data.Vector                  as V
> 
> type StreamOf a m r = Stream (Of a) m r
> 
> demuxStream :: forall a m. MonadIO m
>             => Int -> StreamOf (Int, a) m () -> m (Vector (StreamOf a m ()))
> demuxStream numSyms stream =
>   let emptyStreams = V.replicate numSyms (pure ())
>       processItem v (iD, x) = V.modify (\vm -> VM.modify vm (>> SP.yield x) iD) v
>   in SP.fold_ processItem emptyStreams id stream
> 
> My guess is that it takes more than constant memory as it goes through the entire input stream before returning.
> 
> Josh
> _______________________________________________
> 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/20200416/a9e172cd/attachment.html>

From ben.franksen at online.de  Fri Apr 17 08:18:25 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Fri, 17 Apr 2020 10:18:25 +0200
Subject: [Haskell-cafe] Attoparsec: match many, skipping rest
In-Reply-To: <D7FE2F89-020A-4FBC-A677-99E8B64A09A7@gmail.com>
References: <D7FE2F89-020A-4FBC-A677-99E8B64A09A7@gmail.com>
Message-ID: <r7booi$2eh6$1@ciao.gmane.io>

Am 11.04.20 um 22:23 schrieb amindfv at gmail.com:
> Say I've got an Attoparsec parser like:
> 
>     p = string "prio:" *> digit
> 
> And some text, e.g.
> 
>     s = "this is just a prio:5 example, I'd prio:6 very much like to prio:4 parse"
> 
> What's the most idiomatic way to apply p to s so that I get out a list ['5', '6', '4']?

If your input language is regular, as it appears to be, you could try
regex-applicative. Your desired combinator could be expressed simply as:

  many_ending_with p = many (many anySym *> p)

without incurring any backtracking cost.

Cheers
Ben


From me at abn.sh  Fri Apr 17 15:10:03 2020
From: me at abn.sh (Alexander Ben Nasrallah)
Date: Fri, 17 Apr 2020 17:10:03 +0200
Subject: [Haskell-cafe] GHC Dockerimage
Message-ID: <20200417151003.GA5231@scherox.fritz.box>

Hi fellow Haskellers,

since I was missing a Dockerimage for GHC built with musl and
integer-simple for static linking, which is kept up to date, I created
my own.

I use it to test compatibility with different GHC versions and provide a
full statically linked binary for download with GitLab CI/CD.

Maybe someone will find it useful, too. Or maybe there already is
another more sophisticated project someone can point me to.

https://registry.hub.docker.com/r/neosimsim/ghc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200417/d96e80e9/attachment.sig>

From godzbanebane at gmail.com  Fri Apr 17 16:10:46 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Fri, 17 Apr 2020 19:10:46 +0300
Subject: [Haskell-cafe] GHC Dockerimage
In-Reply-To: <20200417151003.GA5231@scherox.fritz.box>
References: <20200417151003.GA5231@scherox.fritz.box>
Message-ID: <CABT0e9prwqfeDPntweiUNsnYkP0QznhUd1NKXOWs8uS7EMis-w@mail.gmail.com>

Hey!

Thanks! I think this may also be relevant to you -
https://github.com/utdemir/ghc-musl

=======
Georgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200417/2fb6a03e/attachment.html>

From lists at utdemir.com  Sat Apr 18 07:36:56 2020
From: lists at utdemir.com (Utku Demir)
Date: Sat, 18 Apr 2020 19:36:56 +1200
Subject: [Haskell-cafe] GHC Dockerimage
In-Reply-To: <CABT0e9prwqfeDPntweiUNsnYkP0QznhUd1NKXOWs8uS7EMis-w@mail.gmail.com>
References: <20200417151003.GA5231@scherox.fritz.box>
 <CABT0e9prwqfeDPntweiUNsnYkP0QznhUd1NKXOWs8uS7EMis-w@mail.gmail.com>
Message-ID: <2d7928ce-fc91-4104-a0ee-82973003e06f@www.fastmail.com>

Indeed. I just added it to utdemir/ghc-musl's README.

I think building it as a regular Docker image on top of Alpine has
some advantages over mine. In paticular, the user can easily use
it as a base image and extend it with more libraries from Alpine's
repository. Nix-based Docker image lacks this ability since it requires
rebuilding the whole image on any change. Currently I just embed 
commonly used libraries with the images, but it is not a great solution.

If your project survives and keeps working reliably (it's a hard job
maintaining different GHC versions), I will consider deprecating 
utdemir/ghc-musl :).

Thanks!
Utku

On Sat, Apr 18, 2020, at 4:10 AM, Georgi Lyubenov wrote:
> Hey!
> 
> Thanks! I think this may also be relevant to you - https://github.com/utdemir/ghc-musl
> 
> =======
> Georgi
> _______________________________________________
> 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/20200418/6fbe71f4/attachment.html>

From me at abn.sh  Sat Apr 18 09:55:12 2020
From: me at abn.sh (Alexander Ben Nasrallah)
Date: Sat, 18 Apr 2020 11:55:12 +0200
Subject: [Haskell-cafe] GHC Dockerimage
In-Reply-To: <2d7928ce-fc91-4104-a0ee-82973003e06f@www.fastmail.com>
References: <20200417151003.GA5231@scherox.fritz.box>
 <CABT0e9prwqfeDPntweiUNsnYkP0QznhUd1NKXOWs8uS7EMis-w@mail.gmail.com>
 <2d7928ce-fc91-4104-a0ee-82973003e06f@www.fastmail.com>
Message-ID: <20200418095512.GA4808@scherox.fritz.box>

On Sat, Apr 18, 2020 at 07:36:56PM +1200, Utku Demir wrote:
> Indeed. I just added it to utdemir/ghc-musl's README.
> 
> On Sat, Apr 18, 2020, at 4:10 AM, Georgi Lyubenov wrote:
> > Hey!
> > 
> > Thanks! I think this may also be relevant to you - https://github.com/utdemir/ghc-musl
> > 

Thanks for the feedback and the link. It is very much appreciated.

> If your project survives and keeps working reliably (it's a hard job
> maintaining different GHC versions), I will consider deprecating 
> utdemir/ghc-musl :).

I'll do my very best. And yes, It was harder that I thought in the
beginning. That's why I replaced the parameterized Dockerfile with a
Dockerfile for each GHC version.
Also I haven't got GHC 8.2.2 and GHC 8.4.2 working because of some
issues with Cabal 2.0.*. Maybe I'll pack them with Cabal 2.4.

Thanks and cheers,
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200418/fcb2496d/attachment.sig>

From dekudekuplex at yahoo.com  Sat Apr 18 15:54:29 2020
From: dekudekuplex at yahoo.com (Benjamin L. Russell)
Date: Sat, 18 Apr 2020 15:54:29 +0000 (UTC)
Subject: [Haskell-cafe] [ANN] Haskell Beginners WT.Social Community:
 "Haskell: The Haskell-Beginners Community"
References: <1594917799.2743276.1587225269442.ref@mail.yahoo.com>
Message-ID: <1594917799.2743276.1587225269442@mail.yahoo.com>

Twenty-eight days ago (on March 23, 2020 JST), I created a new Haskell
beginners WT.Social community, "Haskell: The Haskell-Beginners
Community" (see
https://pashpost.com/group/haskell-the-haskell-beginners-community),
and migrated a substantial portion of the posts originally from my
former corresponding pashPOST (since renamed to "theTUNDRA") community
of the same name thereto (sansposts with missing links or irrelevant
content).

Feel free to join and contribute!

-- Benjamin L. Russell
-- 
Benjamin L. Russell  /   DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Computer Science Document Translator/Editor
"Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ 

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

From bernardobruno at gmail.com  Tue Apr 21 07:37:26 2020
From: bernardobruno at gmail.com (Bruno Bernardo)
Date: Tue, 21 Apr 2020 09:37:26 +0200
Subject: [Haskell-cafe] FMBC 2020: 2nd Workshop on Formal Methods for
 Blockchains (CfP, Deadline Extension)
Message-ID: <fa5292da-b0b2-ffb6-13d8-e3d302abe3fa@gmail.com>

[ Please distribute, apologies for multiple postings. ]

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

2nd Workshop on Formal Methods for Blockchains (FMBC) 2020 - Second Call

https://fmbc.gitlab.io/2020

July 19, 2020, Los Angeles, USA

Co-located with the 32nd International Conference on Computer-Aided 
Verification (CAV 2020)

http://i-cav.org/2020/

-------------------------------------------------------------
IMPORTANT DATES
--------------------------------
Abstract submission: May 5, 2020 (extended)
Full paper submission: May 12, 2020 (extended)
Notification: June 16, 2020 (extended)
Camera-ready: July 7, 2020
Conference: July 19, 2020
--------------------------------
--------------------------------
TOPICS OF INTEREST
--------------------------------

Blockchains are decentralized transactional ledgers that rely on
cryptographic hash functions for guaranteeing the integrity of the
stored data. Participants on the network reach agreement on what valid
transactions are through consensus algorithms.

Blockchains may also provide support for Smart Contracts. Smart
Contracts are scripts of an ad-hoc programming language that are
stored in the Blockchain and that run on the network. They can
interact with the ledger’s data and update its state. These scripts
can express the logic of possibly complex contracts between users of
the Blockchain. Thus, Smart Contracts can facilitate the economic
activity of Blockchain participants.

With the emergence and increasing popularity of cryptocurrencies such
as Bitcoin and Ethereum, it is now of utmost importance to have strong
guarantees of the behavior of Blockchain software.
These guarantees can be brought by using Formal Methods. Indeed,
Blockchain software encompasses many topics of computer science where
using Formal Methods techniques and tools are relevant: consensus
algorithms to ensure the liveness and the security of the data on the
chain, programming languages specifically designed to write Smart
Contracts, cryptographic protocols, such as zero-knowledge proofs,
used to ensure privacy, etc.

This workshop is a forum to identify theoretical and practical
approaches of formal methods for Blockchain technology. Topics
include, but are not limited to:
* Formal models of Blockchain applications or concepts
* Formal methods for consensus protocols
* Formal methods for Blockchain-specific cryptographic primitives or 
protocols
* Design and implementation of Smart Contract languages
* Verification of Smart Contracts

--------------------------------
--------------------------------
SUBMISSION
--------------------------------

Submit original manuscripts (not published or considered elsewhere)
with a maximum of twelve pages (full papers), six pages (short
papers), and two pages (extended abstract) describing new and emerging
ideas or summarizing existing work). Each paper should include a title
and the name and affiliation of each author. Authors of selected
extended-abstracts are invited to give a short lightning talk.

At least one author of an accepted paper is expected to present the
paper at the workshop as a registered participant.

Submission link: https://easychair.org/conferences/?conf=fmbc2020

The authors are encouraged to use LaTeX and the EasyChair style files:
https://easychair.org/publications/for_authors

--------------------------------
--------------------------------
PROCEEDINGS
--------------------------------

All submissions will be peer-reviewed by at least three members of the
program committee for quality and relevance. Accepted regular papers
(full and short papers) will be included in the workshop proceedings.

--------------------------------
--------------------------------
INVITED SPEAKER
--------------------------------

Grigore Rosu, Professor at University of Illinois at Urbana-Champaign,
USA and Founder of Runtime Verification

http://fsl.cs.illinois.edu/index.php/Grigore_Rosu
https://runtimeverification.com/

--------------------------------
--------------------------------
PROGRAM COMMITTEE
--------------------------------

PC CO-CHAIRS
* Bruno Bernardo (Nomadic Labs, France) (bruno at nomadic-labs.com)
* Diego Marmsoler (University of Exeter, UK) (D.Marmsoler at exeter.ac.uk)

PC MEMBERS
* Wolfgang Ahrendt (Chalmers University of Technology, Sweden)
* Lacramioara Astefanoei (Nomadic Labs, France)
* Massimo Bartoletti (University of Cagliari, Italy)
* Bernhard Beckert (Karlsruhe Institute of Technology, Germany)
* Achim Brucker (University of Exeter, UK)
* Silvia Crafa (Universita di Padova, Italy)
* Zaynah Dargaye (Nomadic Labs, France)
* Jérémie Decouchant (University of Luxembourg, Luxembourg)
* Ansgar Fehnker (University of Twente, Netherlands)
* Georges Gonthier (Inria, France)
* Florian Kammueller (Middlesex University London, UK)
* Maurice Herlihy (Brown University, USA)
* Igor Konnov (Informal, Austria)
* Andreas Lochbihler (Digital Asset, Switzerland)
* Anastasia Mavridou (NASA Ames, USA)
* Simão Melo de Sousa (Universidade da Beira Interior, Portugal)
* Andrew Miller (University of Illinois at Urbana-Champaign, USA)
* Karl Palmskog (KTH, Sweden)
* Vincent Rahli (University of Birmingham, UK)
* Andreas Rossberg (Dfinity Foundation, Germany)
* Claudio Russo (Dfinity Foundation, USA)
* César Sanchez (Imdea, Spain)
* Clara Schneidewind (TU Wien, Austria)
* Ilya Sergey (Yale-NUS College/NUS, Singapore)
* Bas Spitters (Aarhus University/Concordium, Denmark)
* Mark Staples (CSIRO Data61, Australia)
* Meng Sun (Peking University, China)
* Simon Thompson (University of Kent, UK)
* Philip Wadler (University of Edinburgh / IOHK, UK)


From dyaitskov at gmail.com  Wed Apr 22 05:02:01 2020
From: dyaitskov at gmail.com (Daneel Yaitskov)
Date: Tue, 21 Apr 2020 22:02:01 -0700
Subject: [Haskell-cafe] Where is Show for GHC AST?
Message-ID: <CACNT4y4mAp7eru3N60bjii2izPDv_G6uHqRb=M=jmZD47xjG8A@mail.gmail.com>

Hi,

I am trying to modify LiquidHaskell and want to see how source code
is represented in AST format.
I think I have AST i.e. HsExpr value, but there is no Show instance for that.
I noticed that GHC classes implement similar class Outputable, but
it doesn't do what I expected. It just reconstruct AST back to source code.

I could probably write a TH function generating Show instances for all
types which HsExpr depends on, but I hope there is more straight
forward way to do that.

And after all I curious what is the reason for not having Show for GHC
AST types?
It would be so convenient having Show.


-- 


Daneel S. Yaitskov
Java Developer

From marc at lamarciana.com  Wed Apr 22 09:17:54 2020
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Wed, 22 Apr 2020 11:17:54 +0200 (CEST)
Subject: [Haskell-cafe] Better names for
Message-ID: <alpine.LNX.2.21.2004221113190.18239@bolivia>

Hi there!

I've heard several times that some Haskell type classes and methods are
ill-named.

For instance, a functor can be both covariant and contravariant, while
Haskell `Functor` typeclass i just covariant. Would `Cofunctor` be a
better name for it? And what about the `fmap` method? Would it be better
to call it `comap`? How about `Bifunctor`, `Profunctor` and others?

Thanks,

Marc Busqué
http://waiting-for-dev.github.io/about/

From olf at aatal-apotheke.de  Wed Apr 22 13:17:45 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Wed, 22 Apr 2020 15:17:45 +0200
Subject: [Haskell-cafe] Better names for
Message-ID: <f4e76d6a49ce7d5ac16d821282e1423dfccabf41.camel@aatal-apotheke.de>

> I've heard several times that some Haskell type classes and methods
> are
> ill-named.
> 
> For instance, a functor can be both covariant and contravariant,
> while
> Haskell `Functor` typeclass i just covariant. Would `Cofunctor` be a
> better name for it? And what about the `fmap` method? Would it be
> better
> to call it `comap`? How about `Bifunctor`, `Profunctor` and others?

Hi Marc, 

part of the answer is: For historical reasons and to preserve backwards
compatibility. 

The term "Functor", however, comes from category theory. MacLane [1]
defines the term "Functor" to refer to covariant functors. The notion
of "contravariant" is introduced via the concept of "opposite category"
[2] which has the same objects but direction of arrows reversed. Thus a
contravariant functor F: C -> D is just an ordinary functor C -> D^op. 

Category theory has no name for the action of a functor on arrows,
Haskell had to make up a name, which ended up to be "fmap". Sometimes
the notation F(f) is used in category theory where in Haskell we write
fmap f. If I could re-define Haskell from scratch, I'd probably name
the Functor type class function 'map' and omit the map function on
lists, since it is the same as the Functor instance. 

As for your suggestion of 'comap': The prefix co- in category theory is
mostly used in conjunction with the opposite construction [3], whence a
category theorist would believe 'comap' to mean the opposite of 'map'. 

Regards,
Olaf

[1] Saunders MacLane: Categories for the Working Mathematician. ISBN 7-
5062-6008-5
[2] See Op in Data.Functor.Contravariant
[3] See categorical concepts like limit vs. colimit, cone vs. cocone. 


From mgajda at mimuw.edu.pl  Wed Apr 22 13:58:38 2020
From: mgajda at mimuw.edu.pl (Michal J Gajda)
Date: Wed, 22 Apr 2020 15:58:38 +0200
Subject: [Haskell-cafe] Where is Show for GHC AST?
Message-ID: <CACQVYRCKvdYiJcPOLmq5VsQe=033b=7nB1Ag4QhGH72uhP5EMg@mail.gmail.com>

Hi Daneel,
Did you check the `Outputable` class?
http://hackage.haskell.org/package/ghc-8.6.5/docs/Outputable.html#t:Outputable
-- 
  Cheers
    Michał

From matthewtpickering at gmail.com  Wed Apr 22 14:11:10 2020
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 22 Apr 2020 15:11:10 +0100
Subject: [Haskell-cafe] Where is Show for GHC AST?
In-Reply-To: <CACNT4y4mAp7eru3N60bjii2izPDv_G6uHqRb=M=jmZD47xjG8A@mail.gmail.com>
References: <CACNT4y4mAp7eru3N60bjii2izPDv_G6uHqRb=M=jmZD47xjG8A@mail.gmail.com>
Message-ID: <CALuQ0m_UhSZse4FxrKmjvq_rrkfmvmVXBsqHSb=P_3ejs++DZQ@mail.gmail.com>

You can use the `showAstData` function in order to view the AST. There
are also flags `-ddump-parsed-ast`, `-ddump-rn-ast` and
`-ddump-tc-ast` which can be used on the command line.

Cheers,

Matt

On Wed, Apr 22, 2020 at 6:03 AM Daneel Yaitskov <dyaitskov at gmail.com> wrote:
>
> Hi,
>
> I am trying to modify LiquidHaskell and want to see how source code
> is represented in AST format.
> I think I have AST i.e. HsExpr value, but there is no Show instance for that.
> I noticed that GHC classes implement similar class Outputable, but
> it doesn't do what I expected. It just reconstruct AST back to source code.
>
> I could probably write a TH function generating Show instances for all
> types which HsExpr depends on, but I hope there is more straight
> forward way to do that.
>
> And after all I curious what is the reason for not having Show for GHC
> AST types?
> It would be so convenient having Show.
>
>
> --
>
>
> Daneel S. Yaitskov
> Java Developer
> _______________________________________________
> 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 tonyzorman at mailbox.org  Wed Apr 22 09:50:56 2020
From: tonyzorman at mailbox.org (Tony Zorman)
Date: Wed, 22 Apr 2020 11:50:56 +0200
Subject: [Haskell-cafe] Better names for
In-Reply-To: <alpine.LNX.2.21.2004221113190.18239@bolivia>
References: <alpine.LNX.2.21.2004221113190.18239@bolivia>
Message-ID: <87lfmnalxb.fsf@tu-dresden.de>

Hi Marc,

On Wed, Apr 22 2020 11:17, Marc Busqué wrote:
> For instance, a functor can be both covariant and contravariant

Judging from personal experience, "functor" in mathematics always (for a
sufficiently small definition of always) refers to a covariant functor.
If something is contravariant you usually declare it explicitly.  These
concepts are rather related though; one may view any contravariant
functor F: C -> D as a covariant one, either by F: C^o -> D or by
F: C -> D^o.

> Would `Cofunctor` be a better name for it?

Cofunctor has some ambiguity around it.  While it might refer to a
contravariant functor it may as well refer to the dual of a functor
(which is again a functor).

Cheers,
--
Tony Zorman | PGP: 0xc927de8c7dfd57b8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200422/95ec1ad1/attachment.sig>

From vamchale at gmail.com  Wed Apr 22 15:17:52 2020
From: vamchale at gmail.com (Vanessa McHale)
Date: Wed, 22 Apr 2020 10:17:52 -0500
Subject: [Haskell-cafe] Better names for
In-Reply-To: <87lfmnalxb.fsf@tu-dresden.de>
References: <alpine.LNX.2.21.2004221113190.18239@bolivia>
 <87lfmnalxb.fsf@tu-dresden.de>
Message-ID: <DB87D33C-F493-41BE-834E-28EC21840B0D@gmail.com>

Pretty sure cofunctors are functors :p

In any case, I think the name “functor” is pretty apt, makes some sense compared to what I’d learned in algebra.

Cheers,
Vanessa McHale 

> On Apr 22, 2020, at 4:50 AM, Tony Zorman <tonyzorman at mailbox.org> wrote:
> 
> Hi Marc,
> 
> On Wed, Apr 22 2020 11:17, Marc Busqué wrote:
>> For instance, a functor can be both covariant and contravariant
> 
> Judging from personal experience, "functor" in mathematics always (for a
> sufficiently small definition of always) refers to a covariant functor.
> If something is contravariant you usually declare it explicitly.  These
> concepts are rather related though; one may view any contravariant
> functor F: C -> D as a covariant one, either by F: C^o -> D or by
> F: C -> D^o.
> 
>> Would `Cofunctor` be a better name for it?
> 
> Cofunctor has some ambiguity around it.  While it might refer to a
> contravariant functor it may as well refer to the dual of a functor
> (which is again a functor).
> 
> Cheers,
> --
> Tony Zorman | PGP: 0xc927de8c7dfd57b8
> _______________________________________________
> 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 tonyzorman at mailbox.org  Wed Apr 22 15:47:54 2020
From: tonyzorman at mailbox.org (Tony Zorman)
Date: Wed, 22 Apr 2020 17:47:54 +0200
Subject: [Haskell-cafe] Better names for
In-Reply-To: <DB87D33C-F493-41BE-834E-28EC21840B0D@gmail.com>
References: <alpine.LNX.2.21.2004221113190.18239@bolivia>
 <87lfmnalxb.fsf@tu-dresden.de>
 <DB87D33C-F493-41BE-834E-28EC21840B0D@gmail.com>
Message-ID: <87imhra5ed.fsf@mailbox.org>

On Wed, Apr 22 2020 17:17, Vanessa McHale wrote:
> Pretty sure cofunctors are functors :p
>

Indeed!  What I meant to say was that the dual of a (covariant) functor
is again a (covariant) functor, not a contravariant one and hence you
again have the confusion as to which *kind* of functor the name should
refer to.

Cheers,
--
Tony Zorman | PGP: 0xc927de8c7dfd57b8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200422/1ce9811b/attachment.sig>

From jon.fairbairn at cl.cam.ac.uk  Thu Apr 23 08:06:57 2020
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Thu, 23 Apr 2020 09:06:57 +0100
Subject: [Haskell-cafe] Better names for
References: <f4e76d6a49ce7d5ac16d821282e1423dfccabf41.camel@aatal-apotheke.de>
Message-ID: <yplry2qmiq1q.fsf@calligramme.charmers>

Olaf Klinke <olf at aatal-apotheke.de> writes:

> fmap f. If I could re-define Haskell from scratch, I'd probably name
> the Functor type class function 'map'

As it was in Haskell 1.4

> and omit the map function on
> lists, since it is the same as the Functor instance. 

-- 
Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk



From olf at aatal-apotheke.de  Thu Apr 23 14:18:59 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 23 Apr 2020 16:18:59 +0200
Subject: [Haskell-cafe] Better names for
Message-ID: <324eee3fa8434c865450ec38d5b39f178b10155d.camel@aatal-apotheke.de>

> > fmap f. If I could re-define Haskell from scratch, I'd probably
> >name
> > the Functor type class function 'map'
> 
> As it was in Haskell 1.4

That's interesting, I did not know this. Thanks for sharing. Are there
any public records as to why the decision was made to re-name 'map' to
'fmap'? I can not find any mention in the Haskell98 report(s).
There is a stackoverflow thread (#6824255) which mentions paedagogical
reasons, simplifying error messages. 

I sometimes use the current naming 'map' to specialize a polymorphic
function to work exclusively on lists where any functor could have been
used. Other than that, I can not quite see the use in keeping 'map'
around when it is equivalent to fmap. What reasons are there apart from
backwards compatibility? Are there re-write rules that make 'map's
(operational) semantics different to 'fmap'? 

Olaf


From jon.fairbairn at cl.cam.ac.uk  Fri Apr 24 09:31:16 2020
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Fri, 24 Apr 2020 10:31:16 +0100
Subject: [Haskell-cafe] Better names for
References: <324eee3fa8434c865450ec38d5b39f178b10155d.camel@aatal-apotheke.de>
Message-ID: <yplrtv19i61n.fsf@calligramme.charmers>

Olaf Klinke <olf at aatal-apotheke.de> writes:

>> > fmap f. If I could re-define Haskell from scratch, I'd probably
>> >name
>> > the Functor type class function 'map'
>> 
>> As it was in Haskell 1.4
>
> That's interesting, I did not know this. Thanks for sharing. Are there
> any public records as to why the decision was made to re-name 'map' to
> 'fmap'? I can not find any mention in the Haskell98 report(s).

Sorry, I don’t know.

> There is a stackoverflow thread (#6824255) which mentions paedagogical
> reasons, simplifying error messages. 

That is the reason that I remember, the problem being that it
makes sense to teach map on lists before teaching type classes,
so error messages mentioning classes were considered confusing.

I was against this, preferring that teaching should use a
specialised prelude, but this was rejected on the grounds that
teachers wanted to teach “the real language”. I still think this
was a mistake.

  — Jón

-- 
Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk


From permeakra at gmail.com  Fri Apr 24 11:07:18 2020
From: permeakra at gmail.com (Evgeny Permyakov)
Date: Fri, 24 Apr 2020 14:07:18 +0300
Subject: [Haskell-cafe] Does GHC recognise that CmpSymbol s1 s2 ~ EQ implies
	s1 ~ s2 ?
Message-ID: <CAG8h+ACvRzhNTPFPs7TE5_90nrBNv3tjzvVNB2dJ1YcSKnysog@mail.gmail.com>

By semantic
 CmpSymbol s1 s2 ~ EQ should be equivalent to s1 ~ s2 for s1 , s2 :: Symbol

Does GHC recognize it? If not, is there some trick to obtain evidence of
the second constraint from the first ? I'm talking about context of type
class instance declarations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200424/20555c64/attachment.html>

From rae at richarde.dev  Fri Apr 24 12:21:48 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 24 Apr 2020 13:21:48 +0100
Subject: [Haskell-cafe] Does GHC recognise that CmpSymbol s1 s2 ~ EQ
 implies s1 ~ s2 ?
In-Reply-To: <CAG8h+ACvRzhNTPFPs7TE5_90nrBNv3tjzvVNB2dJ1YcSKnysog@mail.gmail.com>
References: <CAG8h+ACvRzhNTPFPs7TE5_90nrBNv3tjzvVNB2dJ1YcSKnysog@mail.gmail.com>
Message-ID: <5E637A9C-24E1-45BF-9F25-9F99220F2DD1@richarde.dev>

No. As far as I know, GHC has no way of deducing this (although it would be safe to do so). If you need to do this, you could use (s1 :~: s2) and `unsafeCoerce Refl`. It's sad, I know.

Happy to expand more if this is too terse!

Richard

> On Apr 24, 2020, at 12:07 PM, Evgeny Permyakov <permeakra at gmail.com> wrote:
> 
> By semantic
>  CmpSymbol s1 s2 ~ EQ should be equivalent to s1 ~ s2 for s1 , s2 :: Symbol
> 
> Does GHC recognize it? If not, is there some trick to obtain evidence of the second constraint from the first ? I'm talking about context of type class instance declarations.
> _______________________________________________
> 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  Fri Apr 24 13:29:36 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Fri, 24 Apr 2020 23:29:36 +1000
Subject: [Haskell-cafe] Better names for
In-Reply-To: <yplrtv19i61n.fsf@calligramme.charmers> (Jon Fairbairn's message
 of "Fri, 24 Apr 2020 10:31:16 +0100")
References: <324eee3fa8434c865450ec38d5b39f178b10155d.camel@aatal-apotheke.de>
 <yplrtv19i61n.fsf@calligramme.charmers>
Message-ID: <87zhb1ko5b.fsf@jackkelly.name>

Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk> writes:

>>>> fmap f. If I could re-define Haskell from scratch, I'd probably name
>>>> the Functor type class function 'map'
>>> 
>>> As it was in Haskell 1.4
>>
>> There is a stackoverflow thread (#6824255) which mentions paedagogical
>> reasons, simplifying error messages. 
>
> That is the reason that I remember, the problem being that it
> makes sense to teach map on lists before teaching type classes,
> so error messages mentioning classes were considered confusing.
>
> I was against this, preferring that teaching should use a
> specialised prelude, but this was rejected on the grounds that
> teachers wanted to teach “the real language”. I still think this
> was a mistake.

I wasn't there for that discussion, but the evolution of Haskell as an
industrial tool makes this justification look worse in hindsight, now
that we have things like the Foldable/Traversable typeclasses. Both of
which are fantastic improvements for industrial use, but mean that you
see classy signatures even on straightforward list functions. Even
numeric literals induce classy type signatures if you're not careful.

I think the case for a solid teaching prelude separate from the
industrial prelude has become more compelling over time, especially now
that GHC can emit custom type error messages.

-- Jack

From permeakra at gmail.com  Fri Apr 24 13:35:28 2020
From: permeakra at gmail.com (Evgeny Permyakov)
Date: Fri, 24 Apr 2020 16:35:28 +0300
Subject: [Haskell-cafe] Need help with advanced type-level programming
Message-ID: <CAG8h+AAFsKbfRxfmp-o5x=ZDY3NAbQrjD9DPw6iV-hg++1=HNw@mail.gmail.com>

Consider following code

data Tag :: (Symbol -> Constraint) -> Symbol -> * where
 Tag :: (KnownSymbol s, con s) => Tag con s

data TagList :: (Symbol -> Constraint) -> [Symbol] -> * where
 LNil :: TagList con '[]
 LCon :: Tag con s -> TagList con ss -> TagList con (s ': ss)

data TagSet :: (Symbol -> Constraint ) -> [Symbol] -> * where
 SNil :: TagSet con '[]
 SSin :: Tag con s -> TagSet con '[s]
 SCon :: CmpSymbol ht mt ~ LT => Tag con ht -> TagSet con (mt ': ts) ->
TagSet con (ht ': mt ': ts)

How one would write a function converting a TagList into a TagSet ,
dropping duplicate tags ? I tried a few approaches, but failed. I clearly
lack understanding how to fit it into GHC type system. I know there is a
library  type-level-sets, but it isn't what I would like and I don't
understand how it fits into GHC type system, so it appears to be magical to
me.

Similarly, it would be greatly appreciated if someone could show how to
implement following typeclass

class CmpTag (s1 :: Symbol) (s2 :: Symbol) where
 cmpTag :: Tag con s1 -> Tag con s2 -> OrdTag con (CmpSymbol s1 s2) s1 s2

data OrdTag :: (Symbol -> Constraint) -> Ordering -> Symbol -> Symbol -> *
 where
 TLT ::  CmpSymbol s1 s2 ~ LT           => Tag con s1 -> Tag con s2 ->
OrdTag con LT s1 s2
 TEQ :: (CmpSymbol s1 s2 ~ EQ, s1 ~ s2) => Tag con s  -> Tag con s2 ->
OrdTag con EQ s1 s2
 TGT ::  CmpSymbol s1 s2 ~ GT           => Tag con s1 -> Tag con s2 ->
OrdTag con GT s1 s2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200424/6266227a/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Fri Apr 24 13:54:40 2020
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Fri, 24 Apr 2020 15:54:40 +0200
Subject: [Haskell-cafe] parsing Haskell expressions
Message-ID: <1a63eed7-4e4a-e7b9-b187-492f33abd64b@htwk-leipzig.de>

Dear Cafe,


for a language that has (subset-of) Haskell expression syntax,
but different global declaration syntax, we are using parseExp
from haskell-src-exts. I have two question on this.

I am asking here because
https://github.com/haskell-suite/haskell-src-exts#maintenance
says that it's no longer active.


(1) can we make parseExp self-delimiting? The type is

parseExp :: String -> ParseResult (Exp SrcSpanInfo)

but I'd want "maximum munch" and the part that was not eaten,
as in   :: String -> ParseResult (.. , String)

I tried     parseExp "x } foo bar"
ParseFailed (SrcLoc "<unknown>.hs" 1 3) "Unexpected }"

so I could extract the error location, and then re-parse that prefix.
That's feels a bit strange.


(2) perhaps we don't need (1) if we do the chunking
on the outside. E.g., we run a lexer and look for delimiters
(keywords of the host language that then are forbidden in
inner expressions). We want to use
lexTokenStream :: String -> ParseResult [Loc Token]
and then I'd want  parseExp' :: [Token] -> ...

Else, we'd have to reconstruct the slice of the original input,
which again, feels a bit strange and (because) it duplicates work.


It is suggested to use
http://hackage.haskell.org/package/ghc-lib-parser
instead.

Would this help with the above? But then of course

(3) is there a transition strategy (e.g., wrapper modules)?


Thanks - J.W.


NB: this is the issue from the project's tracker:
https://gitlab.imn.htwk-leipzig.de/waldmann/cyp/issues/45

From godzbanebane at gmail.com  Fri Apr 24 14:20:23 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Fri, 24 Apr 2020 17:20:23 +0300
Subject: [Haskell-cafe] parsing Haskell expressions
In-Reply-To: <1a63eed7-4e4a-e7b9-b187-492f33abd64b@htwk-leipzig.de>
References: <1a63eed7-4e4a-e7b9-b187-492f33abd64b@htwk-leipzig.de>
Message-ID: <CABT0e9oiWKccgSon5jj3Qh2pkvveq7=fYRWs2eOfh5v_ktXAwg@mail.gmail.com>

Hi!

I don't have direct answers to your questions, but regarding (3) - perhaps
the way hlint migrated from HSE to ghc-lib-parser might be of interest -
https://github.com/ndmitchell/hlint/issues/645 (and related issues and pull
requests)
Best of luck!

=======
Georgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200424/18da2239/attachment.html>

From ben.franksen at online.de  Fri Apr 24 21:15:47 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Fri, 24 Apr 2020 23:15:47 +0200
Subject: [Haskell-cafe] base library on hackage
Message-ID: <r7vku3$heu$1@ciao.gmane.io>

It seems the latest version uploaded there is 4.12. Where can I find
docs for later versions?


From simon.jakobi at googlemail.com  Fri Apr 24 21:46:35 2020
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Fri, 24 Apr 2020 23:46:35 +0200
Subject: [Haskell-cafe] base library on hackage
In-Reply-To: <r7vku3$heu$1@ciao.gmane.io>
References: <r7vku3$heu$1@ciao.gmane.io>
Message-ID: <CAGtp2ShnS_1FkZtNAt70c_Zq_277hP6vtPAB+QV8ez0ai2eddQ@mail.gmail.com>

Hi Ben,

Here are the haddocks for the latest release of base:
http://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.14.0.0/index.html

The documentation for all libraries released with GHC are available
via the GHC downloads: http://downloads.haskell.org/~ghc/

Hopefully Hackage will soon be updated to include the latest boot
libraries. You can find some information on the underlying issues
here:

* https://github.com/haskell-infra/hackage-trustees/issues/240
* https://github.com/haskell/hackage-server/issues/852

Cheers,
Simon

Am Fr., 24. Apr. 2020 um 23:16 Uhr schrieb Ben Franksen
<ben.franksen at online.de>:
>
> It seems the latest version uploaded there is 4.12. Where can I find
> docs for later versions?
>
> _______________________________________________
> 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  Fri Apr 24 21:49:32 2020
From: lysxia at gmail.com (Li-yao Xia)
Date: Fri, 24 Apr 2020 17:49:32 -0400
Subject: [Haskell-cafe] base library on hackage
In-Reply-To: <r7vku3$heu$1@ciao.gmane.io>
References: <r7vku3$heu$1@ciao.gmane.io>
Message-ID: <11661d46-b378-4a72-7a7d-50022ff994d3@gmail.com>

Hi Ben,

The most up-to-date docs are available through ghc.haskell.org: look up 
the latest release at the top and follow the links "Documentation > 
Libraries", which lands you here:

https://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/index.html

Li-yao

On 4/24/20 5:15 PM, Ben Franksen wrote:
> It seems the latest version uploaded there is 4.12. Where can I find
> docs for later versions?
> 
> _______________________________________________
> 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 dreixel at gmail.com  Sat Apr 25 03:22:31 2020
From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=)
Date: Sat, 25 Apr 2020 11:22:31 +0800
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
	Windows?
Message-ID: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>

Hi,

I haven't used Haskell in my personal computer in a while. I decided to
install it again. I used the Haskell Platform in the past, so I went for
that again - and a quick Google search on "install haskell windows" brings
up the HP page, so I thought I was on the right track.

At the HP page for Windows, I'm greeted with this:
[image: image.png]

In the past I'd just download an installer which would take care of things
- now it seems to be more complicated. But fine, I followed the link to
configure Chocolatey. That's where it starts getting really scary:
[image: image.png]

First, I have to subscribe to a newsletter? Really? I guess this is
entirely optional, but the instructions don't make it sound so. Then I have
to know what powershell.exe is, use an administrative prompt, and enter
scary commands in it.

I gave up at this stage. But going back to the HP page, it appears that
even this wouldn't be enough, because I would still need to follow "the
instructions at haskellstack.org to install stack". The link to
haskellstack.org takes me to a 403 Forbidden
<https://docs.haskellstack.org/en/stable/README/>.

I honestly don't want this to sound like a rant. I genuinely would like
to understand why this multi-step, multi-tool, multi-website process was
introduced, how it is superior to a single installer, and whether this is
really the process we want newcomers to the language have to follow.


Thanks,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/03d42c5d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 38769 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/03d42c5d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139353 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/03d42c5d/attachment-0003.png>

From dyaitskov at gmail.com  Sat Apr 25 04:17:29 2020
From: dyaitskov at gmail.com (Daneel Yaitskov)
Date: Fri, 24 Apr 2020 21:17:29 -0700
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
	Windows?
In-Reply-To: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
Message-ID: <CACNT4y7-8qtudOQy_UATJFMN_Je-cedp5GH0pC4JTE_hG_9Fvg@mail.gmail.com>

Hi Pedro,

I think this situation happened, because nobody, except juniors, is using
Windows platform.
As for me I installed ghc somehow within 6 month and I cannot recall
annoying problems.
I don't remember how I did that.
Probably there's alternative way.


Best regards,
Daniil


On Fri, Apr 24, 2020, 8:24 PM José Pedro Magalhães <dreixel at gmail.com>
wrote:

> Hi,
>
> I haven't used Haskell in my personal computer in a while. I decided to
> install it again. I used the Haskell Platform in the past, so I went for
> that again - and a quick Google search on "install haskell windows" brings
> up the HP page, so I thought I was on the right track.
>
> At the HP page for Windows, I'm greeted with this:
> [image: image.png]
>
> In the past I'd just download an installer which would take care of things
> - now it seems to be more complicated. But fine, I followed the link to
> configure Chocolatey. That's where it starts getting really scary:
> [image: image.png]
>
> First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so. Then I have
> to know what powershell.exe is, use an administrative prompt, and enter
> scary commands in it.
>
> I gave up at this stage. But going back to the HP page, it appears that
> even this wouldn't be enough, because I would still need to follow "the
> instructions at haskellstack.org to install stack". The link to
> haskellstack.org takes me to a 403 Forbidden
> <https://docs.haskellstack.org/en/stable/README/>.
>
> I honestly don't want this to sound like a rant. I genuinely would like
> to understand why this multi-step, multi-tool, multi-website process was
> introduced, how it is superior to a single installer, and whether this is
> really the process we want newcomers to the language have to follow.
>
>
> Thanks,
> Pedro
> _______________________________________________
> 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/20200424/14ee57a0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 38769 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200424/14ee57a0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139353 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200424/14ee57a0/attachment-0003.png>

From raoknz at gmail.com  Sat Apr 25 04:27:25 2020
From: raoknz at gmail.com (Richard O'Keefe)
Date: Sat, 25 Apr 2020 16:27:25 +1200
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
	Windows?
In-Reply-To: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
Message-ID: <CABcYAd+XZrax1TgbO4G9uB0WMVV9WavHbjyvv7ef0Wh-aFPJmg@mail.gmail.com>

I ran into the same 403 with HaskellStack.org,
but using the "Cached" link that Google offered,
the page that *should* be there has a link to a
Windows 64-bit installer for stack, and stack is
currently installing ghc-8.8.3 for me, although it
warns that stack has not been tested with GHC
versions about 8.6.

The irony is that I ran stack.exe from an Ubuntu 18
shell.

On Sat, 25 Apr 2020 at 15:24, José Pedro Magalhães <dreixel at gmail.com>
wrote:

> Hi,
>
> I haven't used Haskell in my personal computer in a while. I decided to
> install it again. I used the Haskell Platform in the past, so I went for
> that again - and a quick Google search on "install haskell windows" brings
> up the HP page, so I thought I was on the right track.
>
> At the HP page for Windows, I'm greeted with this:
> [image: image.png]
>
> In the past I'd just download an installer which would take care of things
> - now it seems to be more complicated. But fine, I followed the link to
> configure Chocolatey. That's where it starts getting really scary:
> [image: image.png]
>
> First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so. Then I have
> to know what powershell.exe is, use an administrative prompt, and enter
> scary commands in it.
>
> I gave up at this stage. But going back to the HP page, it appears that
> even this wouldn't be enough, because I would still need to follow "the
> instructions at haskellstack.org to install stack". The link to
> haskellstack.org takes me to a 403 Forbidden
> <https://docs.haskellstack.org/en/stable/README/>.
>
> I honestly don't want this to sound like a rant. I genuinely would like
> to understand why this multi-step, multi-tool, multi-website process was
> introduced, how it is superior to a single installer, and whether this is
> really the process we want newcomers to the language have to follow.
>
>
> Thanks,
> Pedro
> _______________________________________________
> 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/20200425/009be769/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 38769 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/009be769/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139353 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/009be769/attachment-0003.png>

From irfon at ambienautica.com  Sat Apr 25 05:19:30 2020
From: irfon at ambienautica.com (Irfon-Kim Ahmad)
Date: Sat, 25 Apr 2020 01:19:30 -0400
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
 Windows?
In-Reply-To: <CABcYAd+XZrax1TgbO4G9uB0WMVV9WavHbjyvv7ef0Wh-aFPJmg@mail.gmail.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <CABcYAd+XZrax1TgbO4G9uB0WMVV9WavHbjyvv7ef0Wh-aFPJmg@mail.gmail.com>
Message-ID: <d39797d4-f198-8e04-a21b-31bad8b93100@ambienautica.com>

This must be a recent development, because I installed Haskell using the 
"self-contained, all-in-one installer" only a month or two ago. The page 
on haskell.org still talks about this: "The Haskell Platform is a 
self-contained, all-in-one installer. After download, you will have 
everything necessary to build Haskell programs against a core set of 
useful libraries." (That really should be edited to reflect the current 
state of affairs.)

On 2020-04-25 12:27 a.m., Richard O'Keefe wrote:
> I ran into the same 403 with HaskellStack.org,
> but using the "Cached" link that Google offered,
> the page that *should* be there has a link to a
> Windows 64-bit installer for stack, and stack is
> currently installing ghc-8.8.3 for me, although it
> warns that stack has not been tested with GHC
> versions about 8.6.
>
> The irony is that I ran stack.exe from an Ubuntu 18
> shell.
>
> On Sat, 25 Apr 2020 at 15:24, José Pedro Magalhães <dreixel at gmail.com 
> <mailto:dreixel at gmail.com>> wrote:
>
>     Hi,
>
>     I haven't used Haskell in my personal computer in a while. I
>     decided to install it again. I used the Haskell Platform in the
>     past, so I went for that again - and a quick Google search on
>     "install haskell windows" brings up the HP page, so I thought I
>     was on the right track.
>
>     At the HP page for Windows, I'm greeted with this:
>     image.png
>
>     In the past I'd just download an installer which would take care
>     of things - now it seems to be more complicated. But fine, I
>     followed the link to configure Chocolatey. That's where it starts
>     getting really scary:
>     image.png
>
>     First, I have to subscribe to a newsletter? Really? I guess this
>     is entirely optional, but the instructions don't make it sound so.
>     Then I have to know what powershell.exe is, use an administrative
>     prompt, and enter scary commands in it.
>
>     I gave up at this stage. But going back to the HP page, it appears
>     that even this wouldn't be enough, because I would still need to
>     follow "the instructions at haskellstack.org
>     <http://haskellstack.org> to install stack". The link to
>     haskellstack.org <http://haskellstack.org> takes me to a 403
>     Forbidden <https://docs.haskellstack.org/en/stable/README/>.
>
>     I honestly don't want this to sound like a rant. I genuinely would
>     like to understand why this multi-step, multi-tool, multi-website
>     process was introduced, how it is superior to a single installer,
>     and whether this is really the process we want newcomers to the
>     language have to follow.
>
>
>     Thanks,
>     Pedro
>     _______________________________________________
>     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/20200425/5b2b0334/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 38769 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/5b2b0334/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139353 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/5b2b0334/attachment-0003.png>

From lonetiger at gmail.com  Sat Apr 25 08:59:01 2020
From: lonetiger at gmail.com (lonetiger at gmail.com)
Date: Sat, 25 Apr 2020 09:59:01 +0100
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
Message-ID: <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>

Hi Pedro,

I’m the maintainer of those chocolatey packages.

➢ First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so. 

Step 1 is completely optional and you don’t have to subscribe to any news letter.

➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

Powershell has been the standard shell in Windows for well over the past decade. Every single script from Microsoft or third parties come with powershell for automation.
It’s understandable that you may not know it since your primary platform isn’t Windows. But it’s been included in every single Windows version for the past 13 years.

An administrative prompt is nothing different than running sudo or clicking on that installer that you *assumed* not to be scary because you didn’t see the actions it was performing.
That scary looking command is nothing but a curl command allowing the one time execution of a script from a remote source. As in a script that’s not physically on your machine.

So what exactly makes this scary? Is it because

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Is more verbose than

curl -sSL https://path.to.some.script/ | sh

or because the technologies used while completely standard on Windows aren’t known to the casual user?

Thanks,
Tamar

From: José Pedro Magalhães
Sent: Saturday, April 25, 2020 04:24
To: haskell
Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?

Hi,

I haven't used Haskell in my personal computer in a while. I decided to install it again. I used the Haskell Platform in the past, so I went for that again - and a quick Google search on "install haskell windows" brings up the HP page, so I thought I was on the right track.

At the HP page for Windows, I'm greeted with this:


In the past I'd just download an installer which would take care of things - now it seems to be more complicated. But fine, I followed the link to configure Chocolatey. That's where it starts getting really scary:


First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so. Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

I gave up at this stage. But going back to the HP page, it appears that even this wouldn't be enough, because I would still need to follow "the instructions at haskellstack.org to install stack". The link to haskellstack.org takes me to a 403 Forbidden.

I honestly don't want this to sound like a rant. I genuinely would like to understand why this multi-step, multi-tool, multi-website process was introduced, how it is superior to a single installer, and whether this is really the process we want newcomers to the language have to follow.


Thanks,
Pedro

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/b3725da8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A2BD3F3BD99C40A5BF8FAEA4FCA3D1E7.png
Type: image/png
Size: 86082 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/b3725da8/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0EA46F5D4D124867AE6132A284BDE435.png
Type: image/png
Size: 132573 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/b3725da8/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139353 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/b3725da8/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139353 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/b3725da8/attachment-0007.png>

From jack at jackkelly.name  Sat Apr 25 09:15:04 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Sat, 25 Apr 2020 19:15:04 +1000
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 (lonetiger@gmail.com's message of "Sat, 25 Apr 2020 09:59:01 +0100")
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
Message-ID: <87k124kjtz.fsf@jackkelly.name>

I appreciate that these things are standard tools for Windows
developers, but it's worth noting how much harder it can make things
for completely new people (either new developers or new to Windows).

At the start of the year, I prepared install instructions for university
students who would be using Haskell as part of a first year CS
course. We needed to use GHC 8.6.5 because certain libraries were not
available for GHC 8.8.x (their base upper bounds hadn't updated, which
ruled out haskell-dev), and tried to use Chocolatey as an experiment.

It was remarkably tough to get students set up on their own machines. I
was planning on recommending the Haskell Platform installer for Semester
2 this year, and am disappointed to find that it no longer exists.

If it becomes too hard for students to install Haskell on their own
Windows machines, it may become too hard for us to use Haskell as an
educational tool, and I'd consider that a tragedy.

-- Jack

<lonetiger at gmail.com> writes:

> Hi Pedro,
>
> I’m the maintainer of those chocolatey packages.
>
> ➢ First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so.
>
> Step 1 is completely optional and you don’t have to subscribe to any news letter.
>
> ➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.
>
> Powershell has been the standard shell in Windows for well over the
> past decade. Every single script from Microsoft or third parties come
> with powershell for automation.
> It’s understandable that you may not know it since your primary
> platform isn’t Windows. But it’s been included in every single Windows
> version for the past 13 years.
>
> An administrative prompt is nothing different than running sudo or
> clicking on that installer that you *assumed* not to be scary because
> you didn’t see the actions it was performing.
> That scary looking command is nothing but a curl command allowing the
> one time execution of a script from a remote source. As in a script
> that’s not physically on your machine.
>
> So what exactly makes this scary? Is it because
>
> Set-ExecutionPolicy Bypass -Scope Process -Force;
> [System.Net.ServicePointManager]::SecurityProtocol =
> [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex
> ((New-Object
> System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
>
> Is more verbose than
>
> curl -sSL https://path.to.some.script/ | sh
>
> or because the technologies used while completely standard on Windows aren’t known to the casual user?
>
> Thanks,
> Tamar
>
> From: José Pedro Magalhães
> Sent: Saturday, April 25, 2020 04:24
> To: haskell
> Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?
>
> Hi,
>
> I haven't used Haskell in my personal computer in a while. I decided
> to install it again. I used the Haskell Platform in the past, so I
> went for that again - and a quick Google search on "install haskell
> windows" brings up the HP page, so I thought I was on the right track.
>
> At the HP page for Windows, I'm greeted with this:
>
>
> In the past I'd just download an installer which would take care of
> things - now it seems to be more complicated. But fine, I followed the
> link to configure Chocolatey. That's where it starts getting really
> scary:
>
>
> First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so. Then I
> have to know what powershell.exe is, use an administrative prompt, and
> enter scary commands in it.
>
> I gave up at this stage. But going back to the HP page, it appears
> that even this wouldn't be enough, because I would still need to
> follow "the instructions at haskellstack.org to install stack". The
> link to haskellstack.org takes me to a 403 Forbidden.
>
> I honestly don't want this to sound like a rant. I genuinely would
> like to understand why this multi-step, multi-tool, multi-website
> process was introduced, how it is superior to a single installer, and
> whether this is really the process we want newcomers to the language
> have to follow.
>
>
> Thanks,
> Pedro
>
>
>
>
>
>
>
> _______________________________________________
> 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 lonetiger at gmail.com  Sat Apr 25 09:20:25 2020
From: lonetiger at gmail.com (lonetiger at gmail.com)
Date: Sat, 25 Apr 2020 10:20:25 +0100
Subject: [Haskell-cafe] When did it become so hard to install
 HaskellonWindows?
In-Reply-To: <87k124kjtz.fsf@jackkelly.name>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com> <87k124kjtz.fsf@jackkelly.name>
Message-ID: <5ea400da.1c69fb81.1417e.073a@mx.google.com>

Hi Jack,

What made it remarkably tough for students to set up on their machines?

You can still use Haskell-dev if you want older GHCs. Just install it and then
Downgrade the ghc.

I would be quite interested to figure out what the pain points were.

Surely if they are new to Windows they would have come from a platform where
they know what a package manager is.

Would providing a binary to automate the steps work for you? I have been reluctant to
do so because I don’t want to hide what the installer is doing.

Thanks,
Tamar

Sent from Mail for Windows 10

From: Jack Kelly
Sent: Saturday, April 25, 2020 10:15
To: lonetiger at gmail.com
Cc: dreixel at gmail.com; haskell
Subject: Re: [Haskell-cafe] When did it become so hard to install HaskellonWindows?

I appreciate that these things are standard tools for Windows
developers, but it's worth noting how much harder it can make things
for completely new people (either new developers or new to Windows).

At the start of the year, I prepared install instructions for university
students who would be using Haskell as part of a first year CS
course. We needed to use GHC 8.6.5 because certain libraries were not
available for GHC 8.8.x (their base upper bounds hadn't updated, which
ruled out haskell-dev), and tried to use Chocolatey as an experiment.

It was remarkably tough to get students set up on their own machines. I
was planning on recommending the Haskell Platform installer for Semester
2 this year, and am disappointed to find that it no longer exists.

If it becomes too hard for students to install Haskell on their own
Windows machines, it may become too hard for us to use Haskell as an
educational tool, and I'd consider that a tragedy.

-- Jack

<lonetiger at gmail.com> writes:

> Hi Pedro,
>
> I’m the maintainer of those chocolatey packages.
>
> ➢ First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so.
>
> Step 1 is completely optional and you don’t have to subscribe to any news letter.
>
> ➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.
>
> Powershell has been the standard shell in Windows for well over the
> past decade. Every single script from Microsoft or third parties come
> with powershell for automation.
> It’s understandable that you may not know it since your primary
> platform isn’t Windows. But it’s been included in every single Windows
> version for the past 13 years.
>
> An administrative prompt is nothing different than running sudo or
> clicking on that installer that you *assumed* not to be scary because
> you didn’t see the actions it was performing.
> That scary looking command is nothing but a curl command allowing the
> one time execution of a script from a remote source. As in a script
> that’s not physically on your machine.
>
> So what exactly makes this scary? Is it because
>
> Set-ExecutionPolicy Bypass -Scope Process -Force;
> [System.Net.ServicePointManager]::SecurityProtocol =
> [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex
> ((New-Object
> System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
>
> Is more verbose than
>
> curl -sSL https://path.to.some.script/ | sh
>
> or because the technologies used while completely standard on Windows aren’t known to the casual user?
>
> Thanks,
> Tamar
>
> From: José Pedro Magalhães
> Sent: Saturday, April 25, 2020 04:24
> To: haskell
> Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?
>
> Hi,
>
> I haven't used Haskell in my personal computer in a while. I decided
> to install it again. I used the Haskell Platform in the past, so I
> went for that again - and a quick Google search on "install haskell
> windows" brings up the HP page, so I thought I was on the right track.
>
> At the HP page for Windows, I'm greeted with this:
>
>
> In the past I'd just download an installer which would take care of
> things - now it seems to be more complicated. But fine, I followed the
> link to configure Chocolatey. That's where it starts getting really
> scary:
>
>
> First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so. Then I
> have to know what powershell.exe is, use an administrative prompt, and
> enter scary commands in it.
>
> I gave up at this stage. But going back to the HP page, it appears
> that even this wouldn't be enough, because I would still need to
> follow "the instructions at haskellstack.org to install stack". The
> link to haskellstack.org takes me to a 403 Forbidden.
>
> I honestly don't want this to sound like a rant. I genuinely would
> like to understand why this multi-step, multi-tool, multi-website
> process was introduced, how it is superior to a single installer, and
> whether this is really the process we want newcomers to the language
> have to follow.
>
>
> Thanks,
> Pedro
>
>
>
>
>
>
>
> _______________________________________________
> 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/20200425/c8214387/attachment.html>

From lonetiger at gmail.com  Sat Apr 25 09:20:43 2020
From: lonetiger at gmail.com (lonetiger at gmail.com)
Date: Sat, 25 Apr 2020 10:20:43 +0100
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <d39797d4-f198-8e04-a21b-31bad8b93100@ambienautica.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <CABcYAd+XZrax1TgbO4G9uB0WMVV9WavHbjyvv7ef0Wh-aFPJmg@mail.gmail.com>
 <d39797d4-f198-8e04-a21b-31bad8b93100@ambienautica.com>
Message-ID: <5ea400ec.1c69fb81.95041.de9f@mx.google.com>

Yes, this was changed recently as it provides a way to manage all 3 components individually.
As in should you want to you can have any number of versions of GHC installed at the same time.

By decoupling the components it allows for quicker updates and releases and for a better user experience.
Platform was for instance still using GHC 8.6.5 and cabal 3.0.

For the record these packages aren’t new, they’re only now being recommended.

Tamar

From: Irfon-Kim Ahmad
Sent: Saturday, April 25, 2020 06:22
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] When did it become so hard to install Haskell onWindows?

This must be a recent development, because I installed Haskell using the "self-contained, all-in-one installer" only a month or two ago. The page on haskell.org still talks about this: "The Haskell Platform is a self-contained, all-in-one installer. After download, you will have everything necessary to build Haskell programs against a core set of useful libraries." (That really should be edited to reflect the current state of affairs.)
On 2020-04-25 12:27 a.m., Richard O'Keefe wrote:
I ran into the same 403 with HaskellStack.org,
but using the "Cached" link that Google offered,
the page that *should* be there has a link to a
Windows 64-bit installer for stack, and stack is
currently installing ghc-8.8.3 for me, although it
warns that stack has not been tested with GHC
versions about 8.6.

The irony is that I ran stack.exe from an Ubuntu 18
shell.

On Sat, 25 Apr 2020 at 15:24, José Pedro Magalhães <dreixel at gmail.com> wrote:
Hi, 

I haven't used Haskell in my personal computer in a while. I decided to install it again. I used the Haskell Platform in the past, so I went for that again - and a quick Google search on "install haskell windows" brings up the HP page, so I thought I was on the right track.

At the HP page for Windows, I'm greeted with this:


In the past I'd just download an installer which would take care of things - now it seems to be more complicated. But fine, I followed the link to configure Chocolatey. That's where it starts getting really scary:


First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so. Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

I gave up at this stage. But going back to the HP page, it appears that even this wouldn't be enough, because I would still need to follow "the instructions at haskellstack.org to install stack". The link to haskellstack.org takes me to a 403 Forbidden.

I honestly don't want this to sound like a rant. I genuinely would like to understand why this multi-step, multi-tool, multi-website process was introduced, how it is superior to a single installer, and whether this is really the process we want newcomers to the language have to follow.


Thanks,
Pedro
_______________________________________________
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/20200425/ee27a73b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FBEC3133172D4E9BA2AC1B425B1E81C9.png
Type: image/png
Size: 86082 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/ee27a73b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 92A36D98E6014CE3A120976712D61376.png
Type: image/png
Size: 132573 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/ee27a73b/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139353 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/ee27a73b/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139353 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200425/ee27a73b/attachment-0007.png>

From lemming at henning-thielemann.de  Sat Apr 25 09:28:45 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 25 Apr 2020 11:28:45 +0200 (CEST)
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <5ea400ec.1c69fb81.95041.de9f@mx.google.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <CABcYAd+XZrax1TgbO4G9uB0WMVV9WavHbjyvv7ef0Wh-aFPJmg@mail.gmail.com>
 <d39797d4-f198-8e04-a21b-31bad8b93100@ambienautica.com>
 <5ea400ec.1c69fb81.95041.de9f@mx.google.com>
Message-ID: <alpine.DEB.2.20.2004251127400.6560@sputnik>


On Sat, 25 Apr 2020, lonetiger at gmail.com wrote:

> Yes, this was changed recently as it provides a way to manage all 3 components individually.

Friends, could you please stop including the pictures from the original 
posts? Even more than once ...

From lonetiger at gmail.com  Sat Apr 25 09:30:36 2020
From: lonetiger at gmail.com (lonetiger at gmail.com)
Date: Sat, 25 Apr 2020 10:30:36 +0100
Subject: [Haskell-cafe] When did it become so hard to
 installHaskellonWindows?
In-Reply-To: <5ea400da.1c69fb81.1417e.073a@mx.google.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 <87k124kjtz.fsf@jackkelly.name> <5ea400da.1c69fb81.1417e.073a@mx.google.com>
Message-ID: <5ea4033d.1c69fb81.88a0b.9b73@mx.google.com>

And to be clear, if it because you don’t want to use a commandline and want an installer
Chocolatey also provides a GUI overlay, It is after all. A bog standard package manager.

https://github.com/chocolatey/ChocolateyGUI/releases/download/0.17.0/ChocolateyGUI.msi

Is the latest release. It has the familiar “Click and installer asks for UAC and magic happens in background”.

That Pedro may be looking for as well.

Afterwards you just check the box for Haskell-dev and click install.

If you want GHC 8.6.5, you click the all versions button and install that. Haskell-dev is nothing but a wrapper to
Install msys2, ghc and cabal.  Select those 3 components and you get the same thing.

So whether you install Haskell-dev and then downgrade to GHC 8.6.5 or you install GHC 8.6.5 + msys2, both should work

Tamar
From: lonetiger at gmail.com
Sent: Saturday, April 25, 2020 10:20
To: Jack Kelly
Cc: dreixel at gmail.com; haskell
Subject: RE: [Haskell-cafe] When did it become so hard to installHaskellonWindows?

Hi Jack,

What made it remarkably tough for students to set up on their machines?

You can still use Haskell-dev if you want older GHCs. Just install it and then
Downgrade the ghc.

I would be quite interested to figure out what the pain points were.

Surely if they are new to Windows they would have come from a platform where
they know what a package manager is.

Would providing a binary to automate the steps work for you? I have been reluctant to
do so because I don’t want to hide what the installer is doing.

Thanks,
Tamar

Sent from Mail for Windows 10

From: Jack Kelly
Sent: Saturday, April 25, 2020 10:15
To: lonetiger at gmail.com
Cc: dreixel at gmail.com; haskell
Subject: Re: [Haskell-cafe] When did it become so hard to install HaskellonWindows?

I appreciate that these things are standard tools for Windows
developers, but it's worth noting how much harder it can make things
for completely new people (either new developers or new to Windows).

At the start of the year, I prepared install instructions for university
students who would be using Haskell as part of a first year CS
course. We needed to use GHC 8.6.5 because certain libraries were not
available for GHC 8.8.x (their base upper bounds hadn't updated, which
ruled out haskell-dev), and tried to use Chocolatey as an experiment.

It was remarkably tough to get students set up on their own machines. I
was planning on recommending the Haskell Platform installer for Semester
2 this year, and am disappointed to find that it no longer exists.

If it becomes too hard for students to install Haskell on their own
Windows machines, it may become too hard for us to use Haskell as an
educational tool, and I'd consider that a tragedy.

-- Jack

<lonetiger at gmail.com> writes:

> Hi Pedro,
>
> I’m the maintainer of those chocolatey packages.
>
> ➢ First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so.
>
> Step 1 is completely optional and you don’t have to subscribe to any news letter.
>
> ➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.
>
> Powershell has been the standard shell in Windows for well over the
> past decade. Every single script from Microsoft or third parties come
> with powershell for automation.
> It’s understandable that you may not know it since your primary
> platform isn’t Windows. But it’s been included in every single Windows
> version for the past 13 years.
>
> An administrative prompt is nothing different than running sudo or
> clicking on that installer that you *assumed* not to be scary because
> you didn’t see the actions it was performing.
> That scary looking command is nothing but a curl command allowing the
> one time execution of a script from a remote source. As in a script
> that’s not physically on your machine.
>
> So what exactly makes this scary? Is it because
>
> Set-ExecutionPolicy Bypass -Scope Process -Force;
> [System.Net.ServicePointManager]::SecurityProtocol =
> [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex
> ((New-Object
> System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
>
> Is more verbose than
>
> curl -sSL https://path.to.some.script/ | sh
>
> or because the technologies used while completely standard on Windows aren’t known to the casual user?
>
> Thanks,
> Tamar
>
> From: José Pedro Magalhães
> Sent: Saturday, April 25, 2020 04:24
> To: haskell
> Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?
>
> Hi,
>
> I haven't used Haskell in my personal computer in a while. I decided
> to install it again. I used the Haskell Platform in the past, so I
> went for that again - and a quick Google search on "install haskell
> windows" brings up the HP page, so I thought I was on the right track.
>
> At the HP page for Windows, I'm greeted with this:
>
>
> In the past I'd just download an installer which would take care of
> things - now it seems to be more complicated. But fine, I followed the
> link to configure Chocolatey. That's where it starts getting really
> scary:
>
>
> First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so. Then I
> have to know what powershell.exe is, use an administrative prompt, and
> enter scary commands in it.
>
> I gave up at this stage. But going back to the HP page, it appears
> that even this wouldn't be enough, because I would still need to
> follow "the instructions at haskellstack.org to install stack". The
> link to haskellstack.org takes me to a 403 Forbidden.
>
> I honestly don't want this to sound like a rant. I genuinely would
> like to understand why this multi-step, multi-tool, multi-website
> process was introduced, how it is superior to a single installer, and
> whether this is really the process we want newcomers to the language
> have to follow.
>
>
> Thanks,
> Pedro
>
>
>
>
>
>
>
> _______________________________________________
> 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/20200425/d730313d/attachment.html>

From S.J.Thompson at kent.ac.uk  Sat Apr 25 09:44:29 2020
From: S.J.Thompson at kent.ac.uk (Simon Thompson)
Date: Sat, 25 Apr 2020 10:44:29 +0100
Subject: [Haskell-cafe] When did it become so hard to install
	Haskell	onWindows?
In-Reply-To: <87k124kjtz.fsf@jackkelly.name>
References: <87k124kjtz.fsf@jackkelly.name>
Message-ID: <5D63BA43-1B9B-46B4-A591-7F590255F78F@kent.ac.uk>

Jack, a saviour for me is to suggest repl.it … all in the browser, so no installation at all. Beginners can begin with the language and not the installation :-)

Simon

Sent from my iPhone

> On 25 Apr 2020, at 10:17, Jack Kelly <jack at jackkelly.name> wrote:
> 
> I appreciate that these things are standard tools for Windows
> developers, but it's worth noting how much harder it can make things
> for completely new people (either new developers or new to Windows).
> 
> At the start of the year, I prepared install instructions for university
> students who would be using Haskell as part of a first year CS
> course. We needed to use GHC 8.6.5 because certain libraries were not
> available for GHC 8.8.x (their base upper bounds hadn't updated, which
> ruled out haskell-dev), and tried to use Chocolatey as an experiment.
> 
> It was remarkably tough to get students set up on their own machines. I
> was planning on recommending the Haskell Platform installer for Semester
> 2 this year, and am disappointed to find that it no longer exists.
> 
> If it becomes too hard for students to install Haskell on their own
> Windows machines, it may become too hard for us to use Haskell as an
> educational tool, and I'd consider that a tragedy.
> 
> -- Jack
> 
> <lonetiger at gmail.com> writes:
> 
>> Hi Pedro,
>> 
>> I’m the maintainer of those chocolatey packages.
>> 
>> ➢ First, I have to subscribe to a newsletter? Really? I guess this is
>> entirely optional, but the instructions don't make it sound so.
>> 
>> Step 1 is completely optional and you don’t have to subscribe to any news letter.
>> 
>> ➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.
>> 
>> Powershell has been the standard shell in Windows for well over the
>> past decade. Every single script from Microsoft or third parties come
>> with powershell for automation.
>> It’s understandable that you may not know it since your primary
>> platform isn’t Windows. But it’s been included in every single Windows
>> version for the past 13 years.
>> 
>> An administrative prompt is nothing different than running sudo or
>> clicking on that installer that you *assumed* not to be scary because
>> you didn’t see the actions it was performing.
>> That scary looking command is nothing but a curl command allowing the
>> one time execution of a script from a remote source. As in a script
>> that’s not physically on your machine.
>> 
>> So what exactly makes this scary? Is it because
>> 
>> Set-ExecutionPolicy Bypass -Scope Process -Force;
>> [System.Net.ServicePointManager]::SecurityProtocol =
>> [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex
>> ((New-Object
>> System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
>> 
>> Is more verbose than
>> 
>> curl -sSL https://path.to.some.script/ | sh
>> 
>> or because the technologies used while completely standard on Windows aren’t known to the casual user?
>> 
>> Thanks,
>> Tamar
>> 
>> From: José Pedro Magalhães
>> Sent: Saturday, April 25, 2020 04:24
>> To: haskell
>> Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?
>> 
>> Hi,
>> 
>> I haven't used Haskell in my personal computer in a while. I decided
>> to install it again. I used the Haskell Platform in the past, so I
>> went for that again - and a quick Google search on "install haskell
>> windows" brings up the HP page, so I thought I was on the right track.
>> 
>> At the HP page for Windows, I'm greeted with this:
>> 
>> 
>> In the past I'd just download an installer which would take care of
>> things - now it seems to be more complicated. But fine, I followed the
>> link to configure Chocolatey. That's where it starts getting really
>> scary:
>> 
>> 
>> First, I have to subscribe to a newsletter? Really? I guess this is
>> entirely optional, but the instructions don't make it sound so. Then I
>> have to know what powershell.exe is, use an administrative prompt, and
>> enter scary commands in it.
>> 
>> I gave up at this stage. But going back to the HP page, it appears
>> that even this wouldn't be enough, because I would still need to
>> follow "the instructions at haskellstack.org to install stack". The
>> link to haskellstack.org takes me to a 403 Forbidden.
>> 
>> I honestly don't want this to sound like a rant. I genuinely would
>> like to understand why this multi-step, multi-tool, multi-website
>> process was introduced, how it is superior to a single installer, and
>> whether this is really the process we want newcomers to the language
>> have to follow.
>> 
>> 
>> Thanks,
>> Pedro
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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 Apr 25 10:00:19 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Sat, 25 Apr 2020 20:00:19 +1000
Subject: [Haskell-cafe] When did it become so hard to
	installHaskellonWindows?
In-Reply-To: <5ea4033d.1c69fb81.88a0b.9b73@mx.google.com>
 (lonetiger@gmail.com's message of "Sat, 25 Apr 2020 10:30:36 +0100")
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 <87k124kjtz.fsf@jackkelly.name>
 <5ea400da.1c69fb81.1417e.073a@mx.google.com>
 <5ea4033d.1c69fb81.88a0b.9b73@mx.google.com>
Message-ID: <87ftcrlwb0.fsf@jackkelly.name>

Dear Tamar,

Thanks for your response and suggestions. I'll respond pointwise:

> What made it remarkably tough for students to set up on their machines?

* The big one was students who installed ghc without msys. Installing msys
  afterwards does not make GHC aware of it. Is there an equivalent of
  dpkg-reconfigure for chocolatey?

* Some students who were repeating the course had old
  %appdata%/cabal/config files, which meant that programs failed to copy
  across.

* Some students somehow managed to wind up with cabal-install installed
  but not GHC.

* Some students somehow managed to wind up with cabal-install and ghc
  installed, but not on %path%.

* Some students hit the following error when starting GHCi:

GHCi, version 8.8.3: https://www.haskell.org/ghc/ :? for help
<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 5))
Whilst trying to load: (dynamic) pthread

* Some students seem to have computers that are straight-up haunted.

* There were also a number of minor issues around spaces in paths, or
  possibly non-Latin characters in paths, or non-Latin system
  locale. Many of these will happen regardless of installation method,
  so it's not fair to lay them at Chocolatey's feet.

Unfortunately, I can't give you more detailed information than
this. This semester was tougher than usual because of the remote
troubles with COVID-19, and on top of that many of the students who had the
really cursed problems stopped responding before we could get to the
bottom of things. Perhaps they dropped the course?

> You can still use Haskell-dev if you want older GHCs. Just install it and then
> Downgrade the ghc.

I was not aware that this was possible. Thanks for telling me.

> I would be quite interested to figure out what the pain points were.
>
> Surely if they are new to Windows they would have come from a platform where
> they know what a package manager is.

Not necessarily. These are first-year CS students, some of whom have
never programmed before, although they're computer-literate. I have
personally seen students who ask questions like "what's a terminal?" in
the first lab session pass the course with very good marks.

> Would providing a binary to automate the steps work for you? I have been reluctant to
> do so because I don’t want to hide what the installer is doing.

I think this would be extremely helpful.

> And to be clear, if it because you don’t want to use a commandline and want an installer
> Chocolatey also provides a GUI overlay, It is after all. A bog standard package manager.
>
> https://github.com/chocolatey/ChocolateyGUI/releases/download/0.17.0/ChocolateyGUI.msi
>
> Is the latest release. It has the familiar “Click and installer asks for UAC and magic happens in background”.

I was not aware that this existed. It may help, thanks for showing it to
me.

Thanks again.

Best,

-- Jack

From jack at jackkelly.name  Sat Apr 25 10:09:05 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Sat, 25 Apr 2020 20:09:05 +1000
Subject: [Haskell-cafe] When did it become so hard to install
	Haskell	onWindows?
In-Reply-To: <5D63BA43-1B9B-46B4-A591-7F590255F78F@kent.ac.uk> (Simon
 Thompson's message of "Sat, 25 Apr 2020 10:44:29 +0100")
References: <87k124kjtz.fsf@jackkelly.name>
 <5D63BA43-1B9B-46B4-A591-7F590255F78F@kent.ac.uk>
Message-ID: <87blnflvwe.fsf@jackkelly.name>

Dear Simon,

Thanks for your suggestion. I personally don't consider in-browser
solutions like repl.it suitable for this problem in this context, though
they definitely have value in other context. Major reason: many students
in this course will go on to complete an IT or CS major, which means
they have to grapple with this kind of thing at some point.

On a personal level, I am wary of browser-based or cloud-based
development environments as their acceptance accelerates the loss of
control users have over their own computers.

-- Jack

Simon Thompson <S.J.Thompson at kent.ac.uk> writes:

> Jack, a saviour for me is to suggest repl.it … all in the browser, so
> no installation at all. Beginners can begin with the language and not
> the installation :-)
>
> Simon
>
> Sent from my iPhone
>
>> On 25 Apr 2020, at 10:17, Jack Kelly <jack at jackkelly.name> wrote:
>> 
>> I appreciate that these things are standard tools for Windows
>> developers, but it's worth noting how much harder it can make things
>> for completely new people (either new developers or new to Windows).
>> 
>> At the start of the year, I prepared install instructions for university
>> students who would be using Haskell as part of a first year CS
>> course. We needed to use GHC 8.6.5 because certain libraries were not
>> available for GHC 8.8.x (their base upper bounds hadn't updated, which
>> ruled out haskell-dev), and tried to use Chocolatey as an experiment.
>> 
>> It was remarkably tough to get students set up on their own machines. I
>> was planning on recommending the Haskell Platform installer for Semester
>> 2 this year, and am disappointed to find that it no longer exists.
>> 
>> If it becomes too hard for students to install Haskell on their own
>> Windows machines, it may become too hard for us to use Haskell as an
>> educational tool, and I'd consider that a tragedy.
>> 
>> -- Jack
>> 
>> <lonetiger at gmail.com> writes:
>> 
>>> Hi Pedro,
>>> 
>>> I’m the maintainer of those chocolatey packages.
>>> 
>>> ➢ First, I have to subscribe to a newsletter? Really? I guess this is
>>> entirely optional, but the instructions don't make it sound so.
>>> 
>>> Step 1 is completely optional and you don’t have to subscribe to any news letter.
>>> 
>>> ➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.
>>> 
>>> Powershell has been the standard shell in Windows for well over the
>>> past decade. Every single script from Microsoft or third parties come
>>> with powershell for automation.
>>> It’s understandable that you may not know it since your primary
>>> platform isn’t Windows. But it’s been included in every single Windows
>>> version for the past 13 years.
>>> 
>>> An administrative prompt is nothing different than running sudo or
>>> clicking on that installer that you *assumed* not to be scary because
>>> you didn’t see the actions it was performing.
>>> That scary looking command is nothing but a curl command allowing the
>>> one time execution of a script from a remote source. As in a script
>>> that’s not physically on your machine.
>>> 
>>> So what exactly makes this scary? Is it because
>>> 
>>> Set-ExecutionPolicy Bypass -Scope Process -Force;
>>> [System.Net.ServicePointManager]::SecurityProtocol =
>>> [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex
>>> ((New-Object
>>> System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
>>> 
>>> Is more verbose than
>>> 
>>> curl -sSL https://path.to.some.script/ | sh
>>> 
>>> or because the technologies used while completely standard on Windows aren’t known to the casual user?
>>> 
>>> Thanks,
>>> Tamar
>>> 
>>> From: José Pedro Magalhães
>>> Sent: Saturday, April 25, 2020 04:24
>>> To: haskell
>>> Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?
>>> 
>>> Hi,
>>> 
>>> I haven't used Haskell in my personal computer in a while. I decided
>>> to install it again. I used the Haskell Platform in the past, so I
>>> went for that again - and a quick Google search on "install haskell
>>> windows" brings up the HP page, so I thought I was on the right track.
>>> 
>>> At the HP page for Windows, I'm greeted with this:
>>> 
>>> 
>>> In the past I'd just download an installer which would take care of
>>> things - now it seems to be more complicated. But fine, I followed the
>>> link to configure Chocolatey. That's where it starts getting really
>>> scary:
>>> 
>>> 
>>> First, I have to subscribe to a newsletter? Really? I guess this is
>>> entirely optional, but the instructions don't make it sound so. Then I
>>> have to know what powershell.exe is, use an administrative prompt, and
>>> enter scary commands in it.
>>> 
>>> I gave up at this stage. But going back to the HP page, it appears
>>> that even this wouldn't be enough, because I would still need to
>>> follow "the instructions at haskellstack.org to install stack". The
>>> link to haskellstack.org takes me to a 403 Forbidden.
>>> 
>>> I honestly don't want this to sound like a rant. I genuinely would
>>> like to understand why this multi-step, multi-tool, multi-website
>>> process was introduced, how it is superior to a single installer, and
>>> whether this is really the process we want newcomers to the language
>>> have to follow.
>>> 
>>> 
>>> Thanks,
>>> Pedro
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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 haskellcafe at futurenotfound.com  Sat Apr 25 10:17:51 2020
From: haskellcafe at futurenotfound.com (Sean Parsons)
Date: Sat, 25 Apr 2020 11:17:51 +0100
Subject: [Haskell-cafe] Getting the profile results for GHC when running in
	Cabal.
Message-ID: <4f18a6fe-0616-9830-72d8-42b05f493d32@futurenotfound.com>

Hi there.

I've built a GHC with profiling enabled as guided by the wiki and that 
works fine standalone. I found the option for specifying a certain GHC 
to Cabal. But I'm a little baffled as to how to get the results of the 
GHC profile when building a library with Cabal.

My goal is to try to get a baseline profile, then have a poke at the 
innards of GHC and then see if whatever I've changed has made an 
improvement to the build speed.

Does anyone have any idea what the best way to do that is?

Thanks,
Sean.

From lonetiger at gmail.com  Sat Apr 25 10:29:48 2020
From: lonetiger at gmail.com (lonetiger at gmail.com)
Date: Sat, 25 Apr 2020 11:29:48 +0100
Subject: [Haskell-cafe] When did it become so hard
 toinstallHaskellonWindows?
In-Reply-To: <87ftcrlwb0.fsf@jackkelly.name>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 <87k124kjtz.fsf@jackkelly.name>
 <5ea400da.1c69fb81.1417e.073a@mx.google.com>
 <5ea4033d.1c69fb81.88a0b.9b73@mx.google.com> <87ftcrlwb0.fsf@jackkelly.name>
Message-ID: <5ea4111c.1c69fb81.3d10a.332f@mx.google.com>

Hi Jack,

Thanks for this! I’ll respond in turn.

> * The big one was students who installed ghc without msys. Installing msys
>   afterwards does not make GHC aware of it. Is there an equivalent of
>   dpkg-reconfigure for chocolatey?

Yes, the msys2 detection is part of cabal not ghc, (ghc just has a dependency on cabal)
As such

choco install cabal -y --reinstall

Would have corrected it.

> * Some students who were repeating the course had old
>   %appdata%/cabal/config files, which meant that programs failed to copy
>   across.

The presence of an old cabal file itself is not an issue.  The issue is the presence of an old
broken cabal config file.  There were some circumstances (mainly to do with paths with whitespaces) where
the haskell-platform installer may create an invalid config file.

The cabal user-config command won't behave properly if the config file is syntactically damaged.
So my chocolatey packages refuse to modify it because it's not in a sane state.

This is why the Haskell platform site recommend running

cabal user-config init -f

which resets the config file to a clean state. I should however emit a warning when it can’t modify the
config file with instructions on how to fix it.

> 
> * Some students somehow managed to wind up with cabal-install installed
>   but not GHC.

cabal is a dependency of ghc, so it will always be installed after GHC, the only exception here is
if you manually install cabal first.

e.g. choco install cabal ghc.

haskell-dev prevents this by having dependencies to all three packages.

> 
> * Some students somehow managed to wind up with cabal-install and ghc
>   installed, but not on %path%.

If the install finished (because of a quirk in how Windows shells update paths) you need to
either run `refreshenv` to refresh your PATH or simply close and open a new shell.
(You really MUST use one of these two, just running cmd again from the outdated cmd won't work for instance).

chocolatey runs scripts in a separate shell then the one you're executing in, so it can't update your running
session automatically.

> 
> * Some students hit the following error when starting GHCi:
> 
> GHCi, version 8.8.3: https://www.haskell.org/ghc/ :? for help
> <command line>: user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 5))
> Whilst trying to load: (dynamic) pthread

This is an ABI issue, generally happens when you have a program installed on your computer that has put an incompatible version of pthreads on your PATH.  This is why you shouldn't put MSYS2 on your path either as
when the versions of pthread changes in msys2 it may become incompatoble with the one in GHC. The GHC 8.8.x
series is using GCC 8, and so GHC expects an ABI compatible pthreads.

We have been trying to tighten up where GHC loads dependencies from, but this is a GHC issue not a chocolatey one.

> * There were also a number of minor issues around spaces in paths, or
>   possibly non-Latin characters in paths, or non-Latin system
>   locale. Many of these will happen regardless of installation method,
>   so it's not fair to lay them at Chocolatey's feet.

Path with white spaces is indeed a general issue when using configure, The approach platform took was
using dos 8.3 short paths, I haven't taken the same approach primarily because dos short names have a
performance overhead, can be disabled and not available on all filesystems.  So the solution should be
something with how configure is invoked.

I am looking into that.  For non-latin locales we are at the mercy of the fact that GCC and binutils on
Windows can't handle them.  While we've always had tickets for them we haven't been able to do much about it.
However since we have now started experimenting with binary patch gcc we might be able to.

> > You can still use Haskell-dev if you want older GHCs. Just install it and then
> > Downgrade the ghc.
> 
> I was not aware that this was possible. Thanks for telling me.

It's also possible to install any number of GHCs concurrently. Just give chocolatey the -m flag
when installing ghc, which stands for multiple

From: Jack Kelly
Sent: Saturday, April 25, 2020 11:00
To: lonetiger at gmail.com
Cc: dreixel at gmail.com; haskell
Subject: Re: [Haskell-cafe] When did it become so hard toinstallHaskellonWindows?

Dear Tamar,

Thanks for your response and suggestions. I'll respond pointwise:

> What made it remarkably tough for students to set up on their machines?

* The big one was students who installed ghc without msys. Installing msys
  afterwards does not make GHC aware of it. Is there an equivalent of
  dpkg-reconfigure for chocolatey?

* Some students who were repeating the course had old
  %appdata%/cabal/config files, which meant that programs failed to copy
  across.

* Some students somehow managed to wind up with cabal-install installed
  but not GHC.

* Some students somehow managed to wind up with cabal-install and ghc
  installed, but not on %path%.

* Some students hit the following error when starting GHCi:

GHCi, version 8.8.3: https://www.haskell.org/ghc/ :? for help
<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 5))
Whilst trying to load: (dynamic) pthread

* Some students seem to have computers that are straight-up haunted.

* There were also a number of minor issues around spaces in paths, or
  possibly non-Latin characters in paths, or non-Latin system
  locale. Many of these will happen regardless of installation method,
  so it's not fair to lay them at Chocolatey's feet.

Unfortunately, I can't give you more detailed information than
this. This semester was tougher than usual because of the remote
troubles with COVID-19, and on top of that many of the students who had the
really cursed problems stopped responding before we could get to the
bottom of things. Perhaps they dropped the course?

> You can still use Haskell-dev if you want older GHCs. Just install it and then
> Downgrade the ghc.

I was not aware that this was possible. Thanks for telling me.

> I would be quite interested to figure out what the pain points were.
>
> Surely if they are new to Windows they would have come from a platform where
> they know what a package manager is.

Not necessarily. These are first-year CS students, some of whom have
never programmed before, although they're computer-literate. I have
personally seen students who ask questions like "what's a terminal?" in
the first lab session pass the course with very good marks.

> Would providing a binary to automate the steps work for you? I have been reluctant to
> do so because I don’t want to hide what the installer is doing.

I think this would be extremely helpful.

> And to be clear, if it because you don’t want to use a commandline and want an installer
> Chocolatey also provides a GUI overlay, It is after all. A bog standard package manager.
>
> https://github.com/chocolatey/ChocolateyGUI/releases/download/0.17.0/ChocolateyGUI.msi
>
> Is the latest release. It has the familiar “Click and installer asks for UAC and magic happens in background”.

I was not aware that this existed. It may help, thanks for showing it to
me.

Thanks again.

Best,

-- Jack

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

From a.pelenitsyn at gmail.com  Sat Apr 25 14:02:32 2020
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Sat, 25 Apr 2020 10:02:32 -0400
Subject: [Haskell-cafe] Getting the profile results for GHC when running
 in Cabal.
In-Reply-To: <4f18a6fe-0616-9830-72d8-42b05f493d32@futurenotfound.com>
References: <4f18a6fe-0616-9830-72d8-42b05f493d32@futurenotfound.com>
Message-ID: <CAPKAvQX=MrorY99hdKHiA_Lt7iHvWNmDE1opKZ5uXT_FPY0fVQ@mail.gmail.com>

Hey Sean,

You may find this recent discussion on ghc-devs relevant:

https://mail.haskell.org/pipermail/ghc-devs/2020-April/018763.html

Admittedly, it doesn't seem to answer your particular question. But it
might make you consider other ways to check performance.

--
Best, Artem


On Sat, Apr 25, 2020, 6:18 AM Sean Parsons <haskellcafe at futurenotfound.com>
wrote:

> Hi there.
>
> I've built a GHC with profiling enabled as guided by the wiki and that
> works fine standalone. I found the option for specifying a certain GHC
> to Cabal. But I'm a little baffled as to how to get the results of the
> GHC profile when building a library with Cabal.
>
> My goal is to try to get a baseline profile, then have a poke at the
> innards of GHC and then see if whatever I've changed has made an
> improvement to the build speed.
>
> Does anyone have any idea what the best way to do that is?
>
> Thanks,
> Sean.
> _______________________________________________
> 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/20200425/13bd8487/attachment.html>

From infinity0 at pwned.gg  Sat Apr 25 19:52:58 2020
From: infinity0 at pwned.gg (Ximin Luo)
Date: Sat, 25 Apr 2020 20:52:58 +0100
Subject: [Haskell-cafe] Need help with advanced type-level programming
In-Reply-To: <a6e2a68d-7811-7b84-7c69-a351f170d8c9@pwned.gg>
References: <CAG8h+AAFsKbfRxfmp-o5x=ZDY3NAbQrjD9DPw6iV-hg++1=HNw@mail.gmail.com>
 <a6e2a68d-7811-7b84-7c69-a351f170d8c9@pwned.gg>
Message-ID: <55d18338-dc6c-d550-9773-d30eff3a1974@pwned.gg>

Ximin Luo:
> [..]
> 
> As for your code below, it would be easier if you try to describe what specifically you were stuck on, what were you trying to do. When you tried to write your function converting a TagList into a TagSet, what type signature are you expecting? It may be that the signature you thought you need, doesn't fit well into how you've expressed the rest of your data types.
> 
> [..]

Ah, it was simpler than I expected, although I suspect you'll want to write more complex things.

I first made the following tweak:

 SCon :: ((ht < mt) ~ True) => Tag con ht -> TagSet con (mt ': ts) -> TagSet con (ht ': mt ': ts)

Then listToSet can be written something like this:

listToSet :: forall con ss. TagList con ss -> Either String (TagSet con ss)
listToSet LNil = Right SNil
listToSet (LCon t LNil) = Right $ SSin t
listToSet (LCon t0@(Tag :: Tag con s0) tail@(LCon (Tag :: Tag con s1) _)) = case sing @s0 %< sing @s1 of
  STrue -> SCon t0 <$> listToSet tail
  SFalse -> Left "not ordered"

This uses some singleton typeclasses (POrd/SOrd), so you'll have to import the following:

{-# LANGUAGE ConstraintKinds, DataKinds, GADTs, PolyKinds, RankNTypes, ScopedTypeVariables, TypeApplications, TypeOperators #-}

import GHC.TypeLits
import Data.Kind
import Data.Singletons (Sing, sing)
import Data.Singletons.Prelude (SBool(..))
import Data.Singletons.Prelude.Ord (POrd(..), SOrd(..))

POrd for Symbol is actually defined in terms of CmpSymbol so you might be able to get your original code to work, but I couldn't after about 5 minutes of trying. This way is visually more consistent with other singletons code, though.

To write it in a more conventional singletons manner (as I understand; perhaps someone else will correct me) you can define Tag like so:

 Tag :: con s => Sing s -> Tag con s

which allows us to drop the KnownSymbol s constraint, and use these singletons directly later, instead of type-applications on `sing`:

listToSet (LCon t0@(Tag s0) tail@(LCon (Tag s1) _)) = case s0 %< s1 of

HTH

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

From infinity0 at pwned.gg  Sat Apr 25 19:18:41 2020
From: infinity0 at pwned.gg (Ximin Luo)
Date: Sat, 25 Apr 2020 20:18:41 +0100
Subject: [Haskell-cafe] Need help with advanced type-level programming
In-Reply-To: <CAG8h+AAFsKbfRxfmp-o5x=ZDY3NAbQrjD9DPw6iV-hg++1=HNw@mail.gmail.com>
References: <CAG8h+AAFsKbfRxfmp-o5x=ZDY3NAbQrjD9DPw6iV-hg++1=HNw@mail.gmail.com>
Message-ID: <a6e2a68d-7811-7b84-7c69-a351f170d8c9@pwned.gg>

Hi Evgeny,

I've gotten into this topic recently myself and have a few broad tips, that you might find useful. My first comment is that what you seem trying to do below is non-trivial, and might well take a few days or a week if this is the first time trying to do it - it did for my first piece of non-trivial type-level code. So don't try to rush into it, try to understand the background first with some more simple examples.

- Are you aware of the singletons library? It makes life a lot easier. There is a nice introductory series of posts here: https://blog.jle.im/entry/introduction-to-singletons-1.html There are 4 parts and together they will take a couple of days to sink in.

- This is a nice talk https://www.youtube.com/watch?v=wNa3MMbhwS4 with a clarifying example near the end on how to write proofs as constraints.

- `constraints` is a library that lets you wrap constraints so you can pass instances manually around, e.g. generate an instance in a utility function (i.e. prove a theorem), and then return it so the caller can use it.

- Always switch on PolyKinds, and be prepared to use TypeApplications a lot

- case-matching on GADTs is important for GHC to deduce certain things, and this only works on the RHS of a pattern match. Sometimes it can be important to match on constructors of GADTs even if the values are unused on the term-level - this can mean the difference between a type error and no type error. And `let Pattern = ..` didn't seem to work for me at least in some cases, it had to be a `case`.

As for your code below, it would be easier if you try to describe what specifically you were stuck on, what were you trying to do. When you tried to write your function converting a TagList into a TagSet, what type signature are you expecting? It may be that the signature you thought you need, doesn't fit well into how you've expressed the rest of your data types.

X

Evgeny Permyakov:
> Consider following code
> 
> data Tag :: (Symbol -> Constraint) -> Symbol -> * where
>  Tag :: (KnownSymbol s, con s) => Tag con s
> 
> data TagList :: (Symbol -> Constraint) -> [Symbol] -> * where
>  LNil :: TagList con '[]
>  LCon :: Tag con s -> TagList con ss -> TagList con (s ': ss)
> 
> data TagSet :: (Symbol -> Constraint ) -> [Symbol] -> * where
>  SNil :: TagSet con '[]
>  SSin :: Tag con s -> TagSet con '[s]
>  SCon :: CmpSymbol ht mt ~ LT => Tag con ht -> TagSet con (mt ': ts) -> TagSet con (ht ': mt ': ts)
> 
> How one would write a function converting a TagList into a TagSet , dropping duplicate tags ? I tried a few approaches, but failed. I clearly lack understanding how to fit it into GHC type system. I know there is a library  type-level-sets, but it isn't what I would like and I don't understand how it fits into GHC type system, so it appears to be magical to me.
> 
> Similarly, it would be greatly appreciated if someone could show how to implement following typeclass 
> 
> class CmpTag (s1 :: Symbol) (s2 :: Symbol) where
>  cmpTag :: Tag con s1 -> Tag con s2 -> OrdTag con (CmpSymbol s1 s2) s1 s2
> 
> data OrdTag :: (Symbol -> Constraint) -> Ordering -> Symbol -> Symbol -> *  where
>  TLT ::  CmpSymbol s1 s2 ~ LT           => Tag con s1 -> Tag con s2 -> OrdTag con LT s1 s2
>  TEQ :: (CmpSymbol s1 s2 ~ EQ, s1 ~ s2) => Tag con s  -> Tag con s2 -> OrdTag con EQ s1 s2
>  TGT ::  CmpSymbol s1 s2 ~ GT           => Tag con s1 -> Tag con s2 -> OrdTag con GT s1 s2
> 
> 
> _______________________________________________
> 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.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

From anthony_clayden at clear.net.nz  Sun Apr 26 00:22:58 2020
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Sun, 26 Apr 2020 12:22:58 +1200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
Message-ID: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>

Remember GHC's motto is 'avoid success at all costs'. Then naturally it is
prohibitively difficult to get to use GHC.

For students/people who you want to encourage to love Haskell, especially
on Windows,
I'm astonished you're not using Hugs, especially WinHugs (2-click install).
Despite being over a dozen years unsupported it is still
orders-of-magnitude more friendly than GHC,
 and has plenty of functionality (in Hugsmode) for undergraduate level.
What's more Haskell from the intro texts just works on it;
whereas GHC throws all sorts of obscure advanced type errors.

I don't think powershell is a 'standard tool'. I use mostly Windows
machines,
I'm aware of powershell, I've never used it.

Chocolatey is an abhorence. Fortunately I've never had to use it;
I don't know why GHC would inflict it on anybody.

Increasingly, GHC HQ is a cult/elite that doesn't want any new members.
The difficulties in trying to use GHC just show how exclusive it has become.



AntC

> I appreciate that these things are standard tools for Windows
developers, but it's worth noting how much harder it can make things
for completely new people (either new developers or new to Windows).

> At the start of the year, I prepared install instructions for university
students who would be using Haskell as part of a first year CS
course. We needed to use GHC 8.6.5 because certain libraries were not
available for GHC 8.8.x (their base upper bounds hadn't updated, which
ruled out haskell-dev), and tried to use Chocolatey as an experiment.

> It was remarkably tough to get students set up on their own machines. I
was planning on recommending the Haskell Platform installer for Semester
2 this year, and am disappointed to find that it no longer exists.

> If it becomes too hard for students to install Haskell on their own
Windows machines, it may become too hard for us to use Haskell as an
educational tool, and I'd consider that a tragedy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/e8d8da5f/attachment.html>

From guthrie at miu.edu  Sun Apr 26 00:44:01 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Sun, 26 Apr 2020 00:44:01 +0000
Subject: [Haskell-cafe] When did it become so hard to install
	Haskell	onWindows?
In-Reply-To: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
References: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
Message-ID: <DM6PR03MB4331785E09CC389E8DAF291DA1AE0@DM6PR03MB4331.namprd03.prod.outlook.com>

I (cautiously?!) agree – that it is good to avoid elitism – “only newbies use Windows (or an IDE)”, “get tough. Learn emacs…), etc.

                “because nobody, except juniors, is using Windows platform…”


Too bad; If we want it to propagate, accessibility and tools are a key element.

To deprecate 77% of market share, is not growth.



       " In the area of desktop and laptop computers, Microsoft Windows is generally above 70%

        in most markets and at 77% globally, Apple's macOS is at around 13%, Google's Chrome OS

        is at about 6% (in the US) and other Linux distributions are at around 2%"



When I try to use it in some classes, students are expecting an easy install and usage for the first time entry. Spoiled? Maybe, but still an important market segment.

:-)



Dr. Gregory Guthrie

Maharishi International University

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

From anthony_clayden at clear.net.nz  Sun Apr 26 00:59:37 2020
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Sun, 26 Apr 2020 12:59:37 +1200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
Message-ID: <CAM7nRYS7mSKMCSWnBLb-urOWiUuNuwRrQDhgT=aS8euEeWZ1CQ@mail.gmail.com>

@lonetiger, I take it you've never had to support software installs on
shared machines, or students'  machines where you can't be too sure of the
config?

The reasons against using powershell and curl (or equiv) I would have
thought are pretty obvious:
you don't know what you're getting/what it might be downloading.
You might mis-type some command and cause havoc on your machine or on your
network.

With Hugs you download the packed-up .exe; you disconnect from the internet
and run virus checks; you run the install while your machine is still in
quarantine. With Hugs install you (usually) don't need to go into Admin
mode.

Just because some long-winded process is "completely standard on Windows",
doesn't mean it's fit for use.
That's a general learning about stuff from Microsoft.

AntC

➢ Then I have to know what powershell.exe is, use an administrative
prompt, and enter scary commands in it.

> Powershell has been the standard shell in Windows for well over the past decade. Every single script from Microsoft or third parties come with powershell for automation.
It’s understandable that you may not know it since your primary
platform isn’t Windows. But it’s been included in every single Windows
version for the past 13 years.

> An administrative prompt is nothing different than running sudo or clicking on that installer that you *assumed* not to be scary because you didn’t see the actions it was performing.
That scary looking command is nothing but a curl command allowing the
one time execution of a script from a remote source. As in a script
that’s not physically on your machine.

> So what exactly makes this scary? Is it because

> Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

> Is more verbose than

> curl -sSL https://path.to.some.script/ | sh

> or because the technologies used while completely standard on Windows aren’t known to the casual user?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/59cf5762/attachment.html>

From ben at smart-cactus.org  Sun Apr 26 04:51:47 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 26 Apr 2020 00:51:47 -0400
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
References: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
Message-ID: <87o8re6e8u.fsf@smart-cactus.org>

Anthony Clayden <anthony_clayden at clear.net.nz> writes:

...

> Chocolatey is an abhorence. Fortunately I've never had to use it;
> I don't know why GHC would inflict it on anybody.
>
Note that Chocolatey is just option for installing GHC. Our Chocolatey
packaging is generously maintained by Tamar as a convenient way to bring
up GHC on Windows. However, we certainly wouldn't rely on it
exclusively.

Users who don't want to use Chocolatey are encouraged to use the usual
binary distributions [1], as in the past.

I'd urge everyone to keep in mind that our Windows support exists almost
entirely due to the efforts of Tamar; we all owe Tamar a debt of
gratitude for all of the work he has done over the past years. We could
certainly use more people who are able and willing to contribute
resources to help improve GHC's Windows story.

> Increasingly, GHC HQ is a cult/elite that doesn't want any new members.

To the contrary, we both want and need new contributors! I would ask
anyone who feels that GHC development is exclusionary to please be in
touch; I am very interested to know how we can improve.

Cheers,

- Ben


[1] https://downloads.haskell.org/ghc/8.10.1/
-------------- 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/20200426/6da578c5/attachment.sig>

From fa-ml at ariis.it  Sun Apr 26 05:23:17 2020
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 26 Apr 2020 07:23:17 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <87o8re6e8u.fsf@smart-cactus.org>
References: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
 <87o8re6e8u.fsf@smart-cactus.org>
Message-ID: <20200426052317.GA31980@extensa>

On Sun, Apr 26, 2020 at 12:51:47AM -0400, Ben Gamari wrote:
> Users who don't want to use Chocolatey are encouraged to use the usual
> binary distributions [1], as in the past.

If this a working/supported option, maybe it could be advertised
on the platform page too [1] (which now sports only chocolatey).

[1] https://www.haskell.org/platform/#windows

Re: the thorny issue; it will keep being thorny as long as the survey
results look like this

[2] https://taylor.fausak.me/2019/11/16/haskell-survey-results/#s1q2

From raoknz at gmail.com  Sun Apr 26 05:34:22 2020
From: raoknz at gmail.com (Richard O'Keefe)
Date: Sun, 26 Apr 2020 17:34:22 +1200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <CAM7nRYS7mSKMCSWnBLb-urOWiUuNuwRrQDhgT=aS8euEeWZ1CQ@mail.gmail.com>
References: <CAM7nRYS7mSKMCSWnBLb-urOWiUuNuwRrQDhgT=aS8euEeWZ1CQ@mail.gmail.com>
Message-ID: <CABcYAdJigbeqSXJ8ZVUj1r54FKsamvG=9jUZRUMF=U3jL6+0hg@mail.gmail.com>

I note that I have installed several Smalltalk systems under Windows
without once having to touch PowerShell.
I further note that I installed the latest version of R (4.0.0) for Windows:
Just the usual download/run/yes installer may change things/setup clicks.
No PowerShell.
I also installed the latest SageMath.  The first choice for that is a
VirtualBox image,
but a traditional installer is one click away.
Same thing.  Clickety-clickety and no PowerShell in sight.

I tried to like PowerShell.  I really did.  Got a bunch of books, read
'em, played with it.
You'd have to use it a LOT before it started making sense, and I had
other maddened
grizzly bears to stun.

On Sun, 26 Apr 2020 at 13:01, Anthony Clayden
<anthony_clayden at clear.net.nz> wrote:
>
>
> @lonetiger, I take it you've never had to support software installs on shared machines, or students'  machines where you can't be too sure of the config?
>
> The reasons against using powershell and curl (or equiv) I would have thought are pretty obvious:
> you don't know what you're getting/what it might be downloading.
> You might mis-type some command and cause havoc on your machine or on your network.
>
> With Hugs you download the packed-up .exe; you disconnect from the internet and run virus checks; you run the install while your machine is still in quarantine. With Hugs install you (usually) don't need to go into Admin mode.
>
> Just because some long-winded process is "completely standard on Windows", doesn't mean it's fit for use.
> That's a general learning about stuff from Microsoft.
>
> AntC
>
> ➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.
>
> > Powershell has been the standard shell in Windows for well over the past decade. Every single script from Microsoft or third parties come with powershell for automation.
> It’s understandable that you may not know it since your primary platform isn’t Windows. But it’s been included in every single Windows version for the past 13 years.
>
> > An administrative prompt is nothing different than running sudo or clicking on that installer that you *assumed* not to be scary because you didn’t see the actions it was performing.
> That scary looking command is nothing but a curl command allowing the one time execution of a script from a remote source. As in a script that’s not physically on your machine.
>
> > So what exactly makes this scary? Is it because
>
> > Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
>
> > Is more verbose than
>
> > curl -sSL https://path.to.some.script/ | sh
>
> > or because the technologies used while completely standard on Windows aren’t known to the casual user?
>
>
> _______________________________________________
> 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 raoknz at gmail.com  Sun Apr 26 05:37:14 2020
From: raoknz at gmail.com (Richard O'Keefe)
Date: Sun, 26 Apr 2020 17:37:14 +1200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
References: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
Message-ID: <CABcYAdJB1+cxP-dqFSfhHczWGbO8JkDCdN0W0qoaVdpZJFVmfA@mail.gmail.com>

Dear Anthony, I was able to install 'stack' on Windows in minutes with
no PowerShell required.
And 'stack ghci' pulled in ghci.
It doesn't *have* to be hard, even for GHC.

On Sun, 26 Apr 2020 at 12:24, Anthony Clayden
<anthony_clayden at clear.net.nz> wrote:
>
> Remember GHC's motto is 'avoid success at all costs'. Then naturally it is prohibitively difficult to get to use GHC.
>
> For students/people who you want to encourage to love Haskell, especially on Windows,
> I'm astonished you're not using Hugs, especially WinHugs (2-click install).
> Despite being over a dozen years unsupported it is still orders-of-magnitude more friendly than GHC,
>  and has plenty of functionality (in Hugsmode) for undergraduate level.
> What's more Haskell from the intro texts just works on it;
> whereas GHC throws all sorts of obscure advanced type errors.
>
> I don't think powershell is a 'standard tool'. I use mostly Windows machines,
> I'm aware of powershell, I've never used it.
>
> Chocolatey is an abhorence. Fortunately I've never had to use it;
> I don't know why GHC would inflict it on anybody.
>
> Increasingly, GHC HQ is a cult/elite that doesn't want any new members.
> The difficulties in trying to use GHC just show how exclusive it has become.
>
>
>
> AntC
>
> > I appreciate that these things are standard tools for Windows
> developers, but it's worth noting how much harder it can make things
> for completely new people (either new developers or new to Windows).
>
> > At the start of the year, I prepared install instructions for university
> students who would be using Haskell as part of a first year CS
> course. We needed to use GHC 8.6.5 because certain libraries were not
> available for GHC 8.8.x (their base upper bounds hadn't updated, which
> ruled out haskell-dev), and tried to use Chocolatey as an experiment.
>
> > It was remarkably tough to get students set up on their own machines. I
> was planning on recommending the Haskell Platform installer for Semester
> 2 this year, and am disappointed to find that it no longer exists.
>
> > If it becomes too hard for students to install Haskell on their own
> Windows machines, it may become too hard for us to use Haskell as an
> educational tool, and I'd consider that a tragedy.
>
>
> _______________________________________________
> 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 lemming at henning-thielemann.de  Sun Apr 26 06:55:11 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 26 Apr 2020 08:55:11 +0200 (CEST)
Subject: [Haskell-cafe] Need help with advanced type-level programming
In-Reply-To: <a6e2a68d-7811-7b84-7c69-a351f170d8c9@pwned.gg>
References: <CAG8h+AAFsKbfRxfmp-o5x=ZDY3NAbQrjD9DPw6iV-hg++1=HNw@mail.gmail.com>
 <a6e2a68d-7811-7b84-7c69-a351f170d8c9@pwned.gg>
Message-ID: <alpine.DEB.2.20.2004260852250.5892@sputnik>


On Sat, 25 Apr 2020, Ximin Luo wrote:

> Evgeny Permyakov:
>> Consider following code
>> 
>> data Tag :: (Symbol -> Constraint) -> Symbol -> * where
>>  Tag :: (KnownSymbol s, con s) => Tag con s
>> 
>> data TagList :: (Symbol -> Constraint) -> [Symbol] -> * where
>>  LNil :: TagList con '[]
>>  LCon :: Tag con s -> TagList con ss -> TagList con (s ': ss)
>> 
>> data TagSet :: (Symbol -> Constraint ) -> [Symbol] -> * where
>>  SNil :: TagSet con '[]
>>  SSin :: Tag con s -> TagSet con '[s]
>>  SCon :: CmpSymbol ht mt ~ LT => Tag con ht -> TagSet con (mt ': ts) -> TagSet con (ht ': mt ': ts)


If your problem is about maintaining sets of constraints, that might be 
easier to achieve by just maintaining sets of constraints.

From anthony_clayden at clear.net.nz  Sun Apr 26 07:03:29 2020
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Sun, 26 Apr 2020 19:03:29 +1200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
Message-ID: <CAM7nRYSULxxSuOWB2iTSW84pe3Eqs9MH-uZNoF-wCNDGyja8mQ@mail.gmail.com>

Thank you Ben

> I'd urge everyone to keep in mind that our Windows support exists almost
entirely due to the efforts of Tamar; we all owe Tamar a debt of
gratitude for all of the work he has done over the past years. We could
certainly use more people who are able and willing to contribute
resources to help improve GHC's Windows story.

I've tried and tried, to the point where I was clearly considered a nuisance.
I've now given up. And GHC has just got worse since.

I suggest Tamar downloads/installs Hugs [*], then provides (and documents)
 something as easy as that. Wasn't there a GHC equivalent to WinHugs?
That is: something as easy for casual/recreational users/learners of Haskell,
not aimed at Microsoft afficianados.

[*] Sadly, I apologise in advance for this:
https://mail.haskell.org/pipermail/hugs-bugs/2018-July/001914.html

>>* Increasingly, GHC HQ is a cult/elite that doesn't want any new members.*

> To the contrary, we both want and need new contributors!

Not my experience. I was told in polite but unambiguous terms to stop
contributing.

> I would ask anyone who feels that GHC development is exclusionary to please be in
touch; I am very interested to know how we can improve.

I'd like to cite as evidence the survey results Francesco links to:
I don't think I ever got invited to contribute -- where would that have been?
There wasn't an invite on the Hugs-users list.
Note I don't use Reddit because I'm not a brogrammer.

The survey is kinda self-fulfilling: most people don't use GHC on Windows,
because it's too hard to install.

GHC is exclusionary against casual/recreational Haskellers (who are
more likely on Windows)
and those more interested in using it to explore PL Theory.
This is the opposite of how it was when I first grew to love Haskell
around a decade ago.
Just look at the buzz on the cafe back then.


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/40938b5a/attachment.html>

From imantc at gmail.com  Sun Apr 26 07:52:13 2020
From: imantc at gmail.com (Imants Cekusins)
Date: Sun, 26 Apr 2020 10:52:13 +0300
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <CABcYAdJigbeqSXJ8ZVUj1r54FKsamvG=9jUZRUMF=U3jL6+0hg@mail.gmail.com>
References: <CAM7nRYS7mSKMCSWnBLb-urOWiUuNuwRrQDhgT=aS8euEeWZ1CQ@mail.gmail.com>
 <CABcYAdJigbeqSXJ8ZVUj1r54FKsamvG=9jUZRUMF=U3jL6+0hg@mail.gmail.com>
Message-ID: <CAP1qinasQWFtRuMsaicJe9OFwb3tJQJr_EiOKR0cUfHbeU130w@mail.gmail.com>

A side note about powershell for the curious:

Powershell is commonly used for scripting tasks on Windows.

Dr. Tobias Weltner's book Mastering PowerShell is easily found and freely
available online.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/55a90a98/attachment.html>

From ivan.miljenovic at gmail.com  Sun Apr 26 11:28:35 2020
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun, 26 Apr 2020 19:28:35 +0800
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <CAM7nRYSULxxSuOWB2iTSW84pe3Eqs9MH-uZNoF-wCNDGyja8mQ@mail.gmail.com>
References: <CAM7nRYSULxxSuOWB2iTSW84pe3Eqs9MH-uZNoF-wCNDGyja8mQ@mail.gmail.com>
Message-ID: <CA+u6gbzEicV=j9i8=SofUhgbYkJibO64f5EQ+jKjaEVSF4+MAg@mail.gmail.com>

On Sun, 26 Apr 2020 at 15:05, Anthony Clayden <anthony_clayden at clear.net.nz>
wrote:

>
> Note I don't use Reddit because I'm not a brogrammer.
>
>
Dear Anthony,

I don't think this is a very fair label to apply, as it implies that anyone
that uses Reddit tends to be sexist, etc.  In many ways, Reddit (which, by
the way, I do *not* have an account for) is just the modern version of
forums by having a multitude of different sub-forums together rather than
needing multiple websites/accounts for each different topic of interest.

You are not helping your argument here by using such disparaging
terminology.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/db9366ec/attachment.html>

From branimir.maksimovic at gmail.com  Sun Apr 26 11:53:27 2020
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Sun, 26 Apr 2020 13:53:27 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <CA+u6gbzEicV=j9i8=SofUhgbYkJibO64f5EQ+jKjaEVSF4+MAg@mail.gmail.com>
References: <CAM7nRYSULxxSuOWB2iTSW84pe3Eqs9MH-uZNoF-wCNDGyja8mQ@mail.gmail.com>
 <CA+u6gbzEicV=j9i8=SofUhgbYkJibO64f5EQ+jKjaEVSF4+MAg@mail.gmail.com>
Message-ID: <d3657daa-9750-00a6-aa5e-b169ef9b6e34@gmail.com>

He is just frustrated because of current installation instructions on 
Windows.

Comon, Haskell was a breeze to install on Windows years ago. What happened?

I personally don't use Windows but even laiks installed it to test some 
programs.

They weren't programmers even!

Greets,

Branimir.

On 26.4.20. 1:28 по подне, Ivan Lazar Miljenovic wrote:
> On Sun, 26 Apr 2020 at 15:05, Anthony Clayden 
> <anthony_clayden at clear.net.nz <mailto:anthony_clayden at clear.net.nz>> 
> wrote:
>
>     Note I don't use Reddit because I'm not a brogrammer.
>
>
> Dear Anthony,
>
> I don't think this is a very fair label to apply, as it implies that 
> anyone that uses Reddit tends to be sexist, etc. In many ways, Reddit 
> (which, by the way, I do /not/ have an account for) is just the modern 
> version of forums by having a multitude of different sub-forums 
> together rather than needing multiple websites/accounts for each 
> different topic of interest.
>
> You are not helping your argument here by using such disparaging 
> terminology.
>
> -- 
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com <mailto:Ivan.Miljenovic at gmail.com>
> http://IvanMiljenovic.wordpress.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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/ce6a8e3f/attachment-0001.html>

From guthrie at miu.edu  Sun Apr 26 12:17:01 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Sun, 26 Apr 2020 12:17:01 +0000
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
Message-ID: <DM6PR03MB4331677C99DBBD1E4536616DA1AE0@DM6PR03MB4331.namprd03.prod.outlook.com>

Re: Windows installs
Anthony Clayden <anthony_clayden at clear.net.nz> writes:
> ...
> Users who don't want to use Chocolatey are encouraged to use the usual
> binary distributions [1], as in the past.
> [1] https://downloads.haskell.org/ghc/8.10.1/

Thanks; I didn't see any binary labelled Windows there.

Dr. Gregory Guthrie
Maharishi International University
----------------------------------------------------------------

From ben at smart-cactus.org  Sun Apr 26 14:46:39 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 26 Apr 2020 10:46:39 -0400
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <CAM7nRYSULxxSuOWB2iTSW84pe3Eqs9MH-uZNoF-wCNDGyja8mQ@mail.gmail.com>
References: <CAM7nRYSULxxSuOWB2iTSW84pe3Eqs9MH-uZNoF-wCNDGyja8mQ@mail.gmail.com>
Message-ID: <87lfmi5mpj.fsf@smart-cactus.org>

Anthony Clayden <anthony_clayden at clear.net.nz> writes:

...

>> I would ask anyone who feels that GHC development is exclusionary to please be in
> touch; I am very interested to know how we can improve.
>
> I'd like to cite as evidence the survey results Francesco links to:
> I don't think I ever got invited to contribute -- where would that have been?
> There wasn't an invite on the Hugs-users list.

For what it's worth, there was an invitation to respond to the 2019
State of Haskell Survey was sent to this very list [1]. However, I
believe there was only one such announcement so it is understandable
that it could be missed.

> Note I don't use Reddit because I'm not a brogrammer.
>
> The survey is kinda self-fulfilling: most people don't use GHC on Windows,
> because it's too hard to install.
>
Indeed the fact that most of our users use Linux or Darwin poses a
significant challenge for Windows support. We often only learn of
regressions on Windows quite late as a result.

However, of all of the problems with Windows that we might have, issues
with installation instructions should be avoidable. It sounds like your
primary concern is that we recommend Chocolatey on
https://haskell.org/platform [2]?

It would be helpful if you could describe what your precise objections
to Chocolatey are; I'll admit I'm not familiar enough with it to know
why someone might prefer to avoid it. I sounds like there may be two
possible reasons:

 * it requires elevated permissions
 * it requires PowerShell, which the user may not be familiar with

The download page [2] is trying to strike a delicate balance: On one
hand we want as few options as possible to avoid confusion; on the other
we do want to be accomodating to user preferences. Perhaps we could
amend the text to say something like:

    The recommended way to get started with Haskell on Windows is by
    using using [Chocolatey] to install `ghc` and `cabal-install` (users
    not interested in Chocolatey should refer to the [alternate Windows
    instructions]). Further details for
    Chocolatey usage are available [here].

    Users should follow the instructions at [haskellstack.org] to
    install `stack`.

    To get started perform these steps:

    1. Configure [Chocolatey] on your machine.

    2. If upgrading from the old-style `haskell-platform` installer, clean
       the cabal configuration by running:

       cabal user-config init -f 

       Then uninstall prior versions of the platform. 

    3. At an elevated command prompt, run:

       ```
       choco install haskell-dev
       refreshenv
       ```

Where [alternate Windows instructions] would describe installation from
a binary distribution. Perhaps this would be an improvement over the
status quo?

> GHC is exclusionary against casual/recreational Haskellers (who are
> more likely on Windows) and those more interested in using it to
> explore PL Theory.

This is sad to hear and a trend that we should try hard to suppress. One
of Haskell's greatest strengths is its diversity of users and
contributors.

Cheers,

- Ben


[1] https://mail.haskell.org/pipermail/haskell-cafe/2019-November/131633.html
[2] https://www.haskell.org/platform/windows.html#windows
-------------- 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/20200426/93243bbe/attachment.sig>

From naur at post11.tele.dk  Sun Apr 26 15:25:45 2020
From: naur at post11.tele.dk (Thorkil Naur)
Date: Sun, 26 Apr 2020 17:25:45 +0200
Subject: [Haskell-cafe] Please repair Hugs-for-Windows download links
Message-ID: <20200426152545.GA468@Annette-Pc2>

Dear Cafe,

Having recently had occasion to suggest the use of Hugs, I found that the
links provided for WinHugs and MinHugs on

  https://www.haskell.org/hugs/pages/downloading.htm

are broken. In the discussion "When did it become so hard to install
Haskell on Windows?"

  https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132129.html

Anthony Clayden

  https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132155.html

referred to

  https://mail.haskell.org/pipermail/hugs-bugs/2018-July/001914.html

which provides working links:

  https://www.haskell.org/hugs/downloads/2006-09/WinHugs-Sep2006.exe
  https://www.haskell.org/hugs/downloads/2006-09/MinHugs-Sep2006.exe

If someone with suitable access repaired these links, I would be very
grateful. I am an occasional user of both GHC and Hugs, and although GHC
shines when it comes to efficiency, I also often appreciate the modest
and simple Hugs.

Thanks very much in advance.

Best regards
Thorkil

From steve at donacobi.us  Sun Apr 26 15:47:38 2020
From: steve at donacobi.us (steve at donacobi.us)
Date: Sun, 26 Apr 2020 15:47:38 +0000
Subject: [Haskell-cafe] When did it become so hard to install
	Haskell	onWindows?
In-Reply-To: <87lfmi5mpj.fsf@smart-cactus.org>
References: <CAM7nRYSULxxSuOWB2iTSW84pe3Eqs9MH-uZNoF-wCNDGyja8mQ@mail.gmail.com>,
 <87lfmi5mpj.fsf@smart-cactus.org>
Message-ID: <DM6PR10MB3049824437631CCA598B48DCA0AE0@DM6PR10MB3049.namprd10.prod.outlook.com>

I think the comments regarding users' proficiency with Chocolatey or PowerShell or whatever are beside the point. The truth is that *nobody* expects that anyone would need to be familiar with those tools in order to install software on Windows. As an example of what I'm talking about, consider Microsoft Visual Studio. This is a big, complex piece of software. And, obviously, it's an application that's used by software developers, rather than ordinary end users. During installation, it runs multiple PowerShell and Cmd scripts, and, for all I know, uses Chocolatey under the hood as well. The point is, I don't have to care about any of that. I install it the same way I install any other software in Windows: I click a few buttons and make a few checkbox selections, and it just runs*.

Asking Windows users to install software in any other way is like telling Linux users that the *only* way they can upgrade to a newer version of Bash is to use a GUI installer.

I understand perfectly well the issue with resource constraints preventing the creation of a better experience for Windows users. That's okay. The same is true for other software (and for porting software in the other direction, too). And I think it's safe to assume that Microsoft has a few more resources at its disposal to support this than the Haskell community does. So you just need to be honest about it, and state up front that there isn't a simple, seamless way to install the Haskell Platform in Windows at this time, but if you want to install it anyway, here's what you need to do.

-Steve Schafer

*usually

________________________________
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Ben Gamari <ben at smart-cactus.org>
Sent: Sunday, April 26, 2020 10:46 AM
To: Anthony Clayden <anthony_clayden at clear.net.nz>; haskell-cafe at haskell.org <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] When did it become so hard to install Haskell onWindows?

Anthony Clayden <anthony_clayden at clear.net.nz> writes:

...

>> I would ask anyone who feels that GHC development is exclusionary to please be in
> touch; I am very interested to know how we can improve.
>
> I'd like to cite as evidence the survey results Francesco links to:
> I don't think I ever got invited to contribute -- where would that have been?
> There wasn't an invite on the Hugs-users list.

For what it's worth, there was an invitation to respond to the 2019
State of Haskell Survey was sent to this very list [1]. However, I
believe there was only one such announcement so it is understandable
that it could be missed.

> Note I don't use Reddit because I'm not a brogrammer.
>
> The survey is kinda self-fulfilling: most people don't use GHC on Windows,
> because it's too hard to install.
>
Indeed the fact that most of our users use Linux or Darwin poses a
significant challenge for Windows support. We often only learn of
regressions on Windows quite late as a result.

However, of all of the problems with Windows that we might have, issues
with installation instructions should be avoidable. It sounds like your
primary concern is that we recommend Chocolatey on
https://haskell.org/platform [2]?

It would be helpful if you could describe what your precise objections
to Chocolatey are; I'll admit I'm not familiar enough with it to know
why someone might prefer to avoid it. I sounds like there may be two
possible reasons:

 * it requires elevated permissions
 * it requires PowerShell, which the user may not be familiar with

The download page [2] is trying to strike a delicate balance: On one
hand we want as few options as possible to avoid confusion; on the other
we do want to be accomodating to user preferences. Perhaps we could
amend the text to say something like:

    The recommended way to get started with Haskell on Windows is by
    using using [Chocolatey] to install `ghc` and `cabal-install` (users
    not interested in Chocolatey should refer to the [alternate Windows
    instructions]). Further details for
    Chocolatey usage are available [here].

    Users should follow the instructions at [haskellstack.org] to
    install `stack`.

    To get started perform these steps:

    1. Configure [Chocolatey] on your machine.

    2. If upgrading from the old-style `haskell-platform` installer, clean
       the cabal configuration by running:

       cabal user-config init -f

       Then uninstall prior versions of the platform.

    3. At an elevated command prompt, run:

       ```
       choco install haskell-dev
       refreshenv
       ```

Where [alternate Windows instructions] would describe installation from
a binary distribution. Perhaps this would be an improvement over the
status quo?

> GHC is exclusionary against casual/recreational Haskellers (who are
> more likely on Windows) and those more interested in using it to
> explore PL Theory.

This is sad to hear and a trend that we should try hard to suppress. One
of Haskell's greatest strengths is its diversity of users and
contributors.

Cheers,

- Ben


[1] https://mail.haskell.org/pipermail/haskell-cafe/2019-November/131633.html
[2] https://www.haskell.org/platform/windows.html#windows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/ae3c597c/attachment.html>

From karel.gardas at centrum.cz  Sun Apr 26 15:47:57 2020
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun, 26 Apr 2020 17:47:57 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
 Windows?
In-Reply-To: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
Message-ID: <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>


Pedro,

what about if you do this:

1) install WSL(2) from Windows store. Read
https://docs.microsoft.com/en-us/windows/wsl/install-win10 -- err,
contains PowerShell command. :-)

2) start WSL

3) type following commands in WSL prompt:

  $ sudo apt update
  $ sudo apt upgrade
  $ sudo apt install ghc cabal-install

And viola you do have GHC installed on your Windows box, although it's
not possible to create pure windows binaries since it is technically
speaking running inside the Linux (Ubuntu).

Anyway, filesystem is shared so students may be able to use whatever
flashy editor is available for Windows and yet compile with installed GHC.

Honestly speaking PowerShell is one of the brightest Windows features.
When I dig into it last year I've been surprised how well this is
integrated with Windows. Now I'm even more surprised that someone (Ben
mentioned Tamar) from GHC community was able to make GHC install process
working with PowerShell. This is simply great!

Yes, I agree, if you are used to download installer, run it, click OK
button numerous times, then this is not what you are used to, but on the
other hand I believe that anybody even remotely considering *using*
Haskell is able to install it on his/her box. Anybody.

Cheers,
Karel

On 4/25/20 5:22 AM, José Pedro Magalhães wrote:
> Hi,
> 
> I haven't used Haskell in my personal computer in a while. I decided to
> install it again. I used the Haskell Platform in the past, so I went for
> that again - and a quick Google search on "install haskell windows"
> brings up the HP page, so I thought I was on the right track.
> 
> At the HP page for Windows, I'm greeted with this:
> image.png
> 
> In the past I'd just download an installer which would take care of
> things - now it seems to be more complicated. But fine, I followed the
> link to configure Chocolatey. That's where it starts getting really scary:
> image.png
> 
> First, I have to subscribe to a newsletter? Really? I guess this is
> entirely optional, but the instructions don't make it sound so. Then I
> have to know what powershell.exe is, use an administrative prompt, and
> enter scary commands in it.
> 
> I gave up at this stage. But going back to the HP page, it appears that
> even this wouldn't be enough, because I would still need to follow "the
> instructions at haskellstack.org <http://haskellstack.org> to install
> stack". The link to haskellstack.org <http://haskellstack.org> takes me
> to a 403 Forbidden <https://docs.haskellstack.org/en/stable/README/>.
> 
> I honestly don't want this to sound like a rant. I genuinely would like
> to understand why this multi-step, multi-tool, multi-website process was
> introduced, how it is superior to a single installer, and whether this
> is really the process we want newcomers to the language have to follow.
> 
> 
> Thanks,
> Pedro
> 
> _______________________________________________
> 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 vamchale at gmail.com  Sun Apr 26 15:55:25 2020
From: vamchale at gmail.com (Vanessa McHale)
Date: Sun, 26 Apr 2020 10:55:25 -0500
Subject: [Haskell-cafe] Please repair Hugs-for-Windows download links
In-Reply-To: <20200426152545.GA468@Annette-Pc2>
References: <20200426152545.GA468@Annette-Pc2>
Message-ID: <18742E08-5F2F-4C5A-9721-FB45CF3CAD85@gmail.com>

Isn’t hugs unmaintained? Cool stuff but definitely vintage!

Cheers,
Vanessa McHale

> On Apr 26, 2020, at 10:25 AM, Thorkil Naur via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
> Dear Cafe,
> 
> Having recently had occasion to suggest the use of Hugs, I found that the
> links provided for WinHugs and MinHugs on
> 
>  https://www.haskell.org/hugs/pages/downloading.htm
> 
> are broken. In the discussion "When did it become so hard to install
> Haskell on Windows?"
> 
>  https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132129.html
> 
> Anthony Clayden
> 
>  https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132155.html
> 
> referred to
> 
>  https://mail.haskell.org/pipermail/hugs-bugs/2018-July/001914.html
> 
> which provides working links:
> 
>  https://www.haskell.org/hugs/downloads/2006-09/WinHugs-Sep2006.exe
>  https://www.haskell.org/hugs/downloads/2006-09/MinHugs-Sep2006.exe
> 
> If someone with suitable access repaired these links, I would be very
> grateful. I am an occasional user of both GHC and Hugs, and although GHC
> shines when it comes to efficiency, I also often appreciate the modest
> and simple Hugs.
> 
> Thanks very much in advance.
> 
> Best regards
> Thorkil
> _______________________________________________
> 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 imantc at gmail.com  Sun Apr 26 16:26:37 2020
From: imantc at gmail.com (Imants Cekusins)
Date: Sun, 26 Apr 2020 19:26:37 +0300
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
	Windows?
In-Reply-To: <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>
Message-ID: <CAP1qinaH2QC8_yr1L89=kSaQuk0mvcs__Sq-_QKYmT2vm_bbEw@mail.gmail.com>

Installshield (a commercial product) could be one way to offer an easy (for
both packagers and users alike) installation experience.

I am not aware of free licenses though. Shall we inquire?

https://store.flexerasoftware.com/en/productselect.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/38ae9d3a/attachment.html>

From hexagoxel at hexagoxel.de  Sun Apr 26 18:44:21 2020
From: hexagoxel at hexagoxel.de (lennart spitzner)
Date: Sun, 26 Apr 2020 20:44:21 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <5ea400ec.1c69fb81.95041.de9f@mx.google.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <CABcYAd+XZrax1TgbO4G9uB0WMVV9WavHbjyvv7ef0Wh-aFPJmg@mail.gmail.com>
 <d39797d4-f198-8e04-a21b-31bad8b93100@ambienautica.com>
 <5ea400ec.1c69fb81.95041.de9f@mx.google.com>
Message-ID: <2cc3d031-6f23-3309-f20b-5221899648ca@hexagoxel.de>

On 25/04/2020 11:20, lonetiger at gmail.com wrote:
> Yes, this was changed recently as it provides a way to manage all 3 components individually.
> As in should you want to you can have any number of versions of GHC installed at the same time.
> 
> By decoupling the components it allows for quicker updates and releases and for a better user experience.
> Platform was for instance still using GHC 8.6.5 and cabal 3.0.
> 
> For the record these packages aren’t new, they’re only now being recommended.

How many windows haskell users
a) need multiple GHCs installed at the same time?
b) mind using ghc-8.6 and cabal-3.0?
c) are interested in quicker updates?
d) have confirmed that this change, overall, provides the better user experience?

To me this feels like a change was introduced
1) that disrupts existing workflows that have worked fine in the past
2) that nonetheless was not announced at all, really (chocolatey was mentioned once in a sidenode of a sidenote to a ghc release on the haskell mailinglist, but certainly not as a "ANNOUNCE: we (plan to) switch recommendations to this")
3) that may be a net positive, but it certainly has its trade-offs
4) without asking the relevant userbase for any sort of feedback before making the change

and then, when people give feedback after the fact, in a respectful manner, the response to me reads like this:

- "just ignore the step 1 subscribe-newsletter spam, it is optional"
- "why, don't you know how to use powershell?"
- "you can just use binary releases" (but those are not currently advertised at all from haskell.org)
- "yeah there is a ChocolateyGUI.msi" (but haskell.org is not recommending that because..?)
- "you don't like the change? then please explain in detail what is bad about Chocolatey"

No, this is not about Chocolatey! On a glance, it seems like a sensible tool, despite the dark pattern, IF you are interested in installing multiple up-to-date ghcs. But what does the userbase want?

Have the windows haskell users been asked about this via haskell(-cafe)@haskell.org (or other windows-focussed lists)? Why not?

Maybe the main answer to all of this is the sad "we don't have any volunteer time, and maintaining the installer is a time-sink. Asking users and shepherding a consensus would take even more effort. Chocolatey is the most cost-effective solution to the problem at hand, just from a maintenance perspective."

--

If this is the case, I urge you to approach the problem differently. There may be a circle of "too few contributors -> hard to communicate on problems with diverse user-groups with conflicting interests -> people complaining about breakage without contributing". But you don't break that cycle by stopping on the communication front and implementing solutions that make the most sense to you.

> Increasingly, GHC HQ is a cult/elite that doesn't want any new members.
> The difficulties in trying to use GHC just show how exclusive it has become.

Is exactly what this will feel like to those that are not enabled to influence the direction of the project. And I can fully empathise with this.

-- lennart

From steve at donacobi.us  Sun Apr 26 19:40:42 2020
From: steve at donacobi.us (Steve Schafer)
Date: Sun, 26 Apr 2020 19:40:42 +0000
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	on	Windows?
In-Reply-To: <CAP1qinaH2QC8_yr1L89=kSaQuk0mvcs__Sq-_QKYmT2vm_bbEw@mail.gmail.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>,
 <CAP1qinaH2QC8_yr1L89=kSaQuk0mvcs__Sq-_QKYmT2vm_bbEw@mail.gmail.com>
Message-ID: <DM6PR10MB304974569E4D2E72843CB997A0AE0@DM6PR10MB3049.namprd10.prod.outlook.com>

I've used Advanced Installer (https://www.advancedinstaller.com/) to create Windows installers. There is a freeware version; I don't have enough experience with it to know if it has the necessary features or not.

-Steve Schafer

________________________________
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Imants Cekusins <imantc at gmail.com>
Sent: Sunday, April 26, 2020 12:26 PM
To: haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] When did it become so hard to install Haskell on Windows?

Installshield (a commercial product) could be one way to offer an easy (for both packagers and users alike) installation experience.

I am not aware of free licenses though. Shall we inquire?

https://store.flexerasoftware.com/en/productselect.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200426/11608528/attachment.html>

From ietf-dane at dukhovni.org  Sun Apr 26 19:45:46 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 26 Apr 2020 15:45:46 -0400
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	on	Windows?
In-Reply-To: <DM6PR10MB304974569E4D2E72843CB997A0AE0@DM6PR10MB3049.namprd10.prod.outlook.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>
 <CAP1qinaH2QC8_yr1L89=kSaQuk0mvcs__Sq-_QKYmT2vm_bbEw@mail.gmail.com>
 <DM6PR10MB304974569E4D2E72843CB997A0AE0@DM6PR10MB3049.namprd10.prod.outlook.com>
Message-ID: <20200426194546.GA41308@straasha.imrryr.org>

On Sun, Apr 26, 2020 at 07:40:42PM +0000, Steve Schafer wrote:

> I've used Advanced Installer (https://www.advancedinstaller.com/) to create Windows installers. There is a freeware version; I don't have enough experience with it to know if it has the necessary features or not.

If we're talking Windows installers, Wix is free, and used by e.g.
OpenJDK to construct ".msi" click to install packages.

-- 
    Viktor.

From alec.theriault at gmail.com  Sun Apr 26 19:54:33 2020
From: alec.theriault at gmail.com (Alec Theriault)
Date: Sun, 26 Apr 2020 15:54:33 -0400
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
 Windows?
In-Reply-To: <20200426194546.GA41308@straasha.imrryr.org>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>
 <CAP1qinaH2QC8_yr1L89=kSaQuk0mvcs__Sq-_QKYmT2vm_bbEw@mail.gmail.com>
 <DM6PR10MB304974569E4D2E72843CB997A0AE0@DM6PR10MB3049.namprd10.prod.outlook.com>
 <20200426194546.GA41308@straasha.imrryr.org>
Message-ID: <56FC6BDD-463A-488E-B565-FED947BB319B@gmail.com>

I wanted to chime in with a bit of positiveness. I really appreciate the work that Tamar has put into the Chocolatey packages, and when I personally needed to debug a windows-only issue, I found the installation experience to be better than Haskell Platform (which I had previously used when in university). It was clearer to see what I was installing (and I was able to directly manage what I had installed through Chocolatey - including installing other GHC’s and Cabal's). The Chocolatey packages also make setting up CI for windows much simpler.

I can see why the new process is more complicated for university students who are accustomed to more GUIs and probably don’t have Chocolatey installed. Since there is a graphical installer for Chocolatey, couldn’t this mostly be solved by writing up more detailed setup instructions (including all the right GUI installer links and walkthrough) on the course’s home page site? The instructions could be reviewed once at the beginning of every term to make sure they are still accurate. That seems like the sort of thing that could eventually also be put on the official Haskell website.

Packaging software for windows, GHC in particular, is a pretty huge task. The volunteers who maintain this stuff are heroes, and it is disheartening that the only time this difficult work ever gets recognized is when people are angry something isn’t working as expected. 

Alec

From gershomb at gmail.com  Sun Apr 26 21:16:18 2020
From: gershomb at gmail.com (Gershom B)
Date: Sun, 26 Apr 2020 17:16:18 -0400
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
 Windows?
In-Reply-To: <56FC6BDD-463A-488E-B565-FED947BB319B@gmail.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>
 <CAP1qinaH2QC8_yr1L89=kSaQuk0mvcs__Sq-_QKYmT2vm_bbEw@mail.gmail.com>
 <DM6PR10MB304974569E4D2E72843CB997A0AE0@DM6PR10MB3049.namprd10.prod.outlook.com>
 <20200426194546.GA41308@straasha.imrryr.org>
 <56FC6BDD-463A-488E-B565-FED947BB319B@gmail.com>
Message-ID: <etPan.5ea5fa22.6805373d.149@gmail.com>

Hi all. This is largely due to changes I made. I thought I had signposted chocolatey subsuming binary platform installers better, but looking at my message history I hadn’t. So apologies for the switch being more abrupt than I intended. We have gradually been moving the platform away from binary installers and towards wrappers for the ghc team provided bindists. This is on the whole a technically more sound approach that involves less infrastructure, faster turnarounds (so we can keep up with the ghc release schedule), and has fewer rough edges and corner cases. So we moved to ghcup on linux and then later macos. Moving to chocolatey for windows was the next step in this evolution. There are a lot of issues that involved configuring the system that were very difficult to manage with the old NSIS based install infrastructure, and this approach has lifted their burden. (Yes, there are problems getting things to work well with msys2 now, but they’re actually much more straightforward than the issues we had before!)

That said, it is clear that the user experience of chocolatey can be a bit daunting, and it would be nice to wrap it up in something more graphical and ghc-specific to improve things, and also maybe just to improve the install instructions. Maybe progress can be made in this regard, and it would be nice if people who want to improve the windows experience chipped in here.

Best,
Gershom


On April 26, 2020 at 3:55:40 PM, Alec Theriault (alec.theriault at gmail.com) wrote:

I wanted to chime in with a bit of positiveness. I really appreciate the work that Tamar has put into the Chocolatey packages, and when I personally needed to debug a windows-only issue, I found the installation experience to be better than Haskell Platform (which I had previously used when in university). It was clearer to see what I was installing (and I was able to directly manage what I had installed through Chocolatey - including installing other GHC’s and Cabal's). The Chocolatey packages also make setting up CI for windows much simpler.

I can see why the new process is more complicated for university students who are accustomed to more GUIs and probably don’t have Chocolatey installed. Since there is a graphical installer for Chocolatey, couldn’t this mostly be solved by writing up more detailed setup instructions (including all the right GUI installer links and walkthrough) on the course’s home page site? The instructions could be reviewed once at the beginning of every term to make sure they are still accurate. That seems like the sort of thing that could eventually also be put on the official Haskell website.

Packaging software for windows, GHC in particular, is a pretty huge task. The volunteers who maintain this stuff are heroes, and it is disheartening that the only time this difficult work ever gets recognized is when people are angry something isn’t working as expected.  

Alec
_______________________________________________
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/20200426/d7fe24b1/attachment.html>

From ben at smart-cactus.org  Sun Apr 26 22:35:51 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 26 Apr 2020 18:35:51 -0400
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <2cc3d031-6f23-3309-f20b-5221899648ca@hexagoxel.de>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <CABcYAd+XZrax1TgbO4G9uB0WMVV9WavHbjyvv7ef0Wh-aFPJmg@mail.gmail.com>
 <d39797d4-f198-8e04-a21b-31bad8b93100@ambienautica.com>
 <5ea400ec.1c69fb81.95041.de9f@mx.google.com>
 <2cc3d031-6f23-3309-f20b-5221899648ca@hexagoxel.de>
Message-ID: <874kt56fjy.fsf@smart-cactus.org>

I'll give my perspective below. Not being intimately familiar with the
Platform's Windows packaging effort, some of this may not be spot-on.
However, I do think I have some context that 

lennart spitzner <hexagoxel at hexagoxel.de> writes:

> On 25/04/2020 11:20, lonetiger at gmail.com wrote:
>> Yes, this was changed recently as it provides a way to manage all 3 components individually.
>> As in should you want to you can have any number of versions of GHC installed at the same time.
>> 
>> By decoupling the components it allows for quicker updates and releases and for a better user experience.
>> Platform was for instance still using GHC 8.6.5 and cabal 3.0.
>> 
>> For the record these packages aren’t new, they’re only now being recommended.
>

[snip]

Having looked at the Chocolatey installation instructions, I will agree
that they are a bit rough, particularly in the case of a user without
administrative access. However, the benefits of piggy-backing on
Chocolatey seem significant:

 * having worked on projects which were locked to a particular GHC
   version, I can attest that multiple side-by-side compilers is a need
   that many industrial users certainly have.

 * our previous Windows installer infrastructure [1] is essentially
   unmaintained. It would take time and effort on the part of someone to
   bring it into a working state. Moreover, even when it "worked" it had
   serious issues (%PATH% issues were a constant headache, the msys
   installation could be easily broken by the user), was not built on
   the MSI installer subsystem officially sanctioned by Microsoft, and
   imposed a significant maintenance overhead (building a functional
   distribution required no small amount of luck)

 * the Windows developer community seems to have largely consolidated
   around nuGet and Chocolatey; following this trend seems wise given
   how tricky (proper) packaging for Windows tends to be

My sense is that Chocolatey is the right approach here. We simply need
to make it more accessible. After a long discussion with Tamar, I think
we have a plan that could move us in this direction. I have documented
this plan in #18104 [2].

While it's possible that Tamar or I could get to working on this
eventually, it would be much better if we could get help from the
broader community since there is little GHC-specific knowledge
necessary. In general we have precious few developer-hours looking
at GHC Windows issues; it would be a shame to have to spend them on
packaging issues.

If you are interesting in contributing please comment on the ticket.

Cheers,

- Ben


[1] https://github.com/haskell/haskell-platform/blob/master/windows-platform.sh
[2] https://gitlab.haskell.org/ghc/ghc/issues/18104

-------------- 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/20200426/e4cd3acd/attachment.sig>

From jack at jackkelly.name  Sun Apr 26 23:39:22 2020
From: jack at jackkelly.name (Jack Kelly)
Date: Mon, 27 Apr 2020 09:39:22 +1000
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
	Windows?
In-Reply-To: <56FC6BDD-463A-488E-B565-FED947BB319B@gmail.com> (Alec
 Theriault's message of "Sun, 26 Apr 2020 15:54:33 -0400")
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>
 <CAP1qinaH2QC8_yr1L89=kSaQuk0mvcs__Sq-_QKYmT2vm_bbEw@mail.gmail.com>
 <DM6PR10MB304974569E4D2E72843CB997A0AE0@DM6PR10MB3049.namprd10.prod.outlook.com>
 <20200426194546.GA41308@straasha.imrryr.org>
 <56FC6BDD-463A-488E-B565-FED947BB319B@gmail.com>
Message-ID: <87lfmhizpx.fsf@jackkelly.name>

While I did email Tamar off-list, I should probably also thank him
publicly. Packaging is a frustrating and often thankless part of Free
Software development, and I appreciate that I can help a university
teach Haskell to first-year students _at all_.

We do refresh the installation instructions each semester, and re-test
them before each run of the course to make sure they're up-to-date. Even
with direct links to installers and explicit step-by-step instructions,
I have been very surprised by the knots some students have managed to
tie their computers into, and while Chocolatey has given us teething
issues it also gives us a single set of commands to install
GHC/cabal-install/MSYS2 and a decent text editor.

-- Jack

Alec Theriault <alec.theriault at gmail.com> writes:

> I wanted to chime in with a bit of positiveness. I really appreciate
> the work that Tamar has put into the Chocolatey packages, and when I
> personally needed to debug a windows-only issue, I found the
> installation experience to be better than Haskell Platform (which I
> had previously used when in university). It was clearer to see what I
> was installing (and I was able to directly manage what I had installed
> through Chocolatey - including installing other GHC’s and
> Cabal's). The Chocolatey packages also make setting up CI for windows
> much simpler.
>
> I can see why the new process is more complicated for university
> students who are accustomed to more GUIs and probably don’t have
> Chocolatey installed. Since there is a graphical installer for
> Chocolatey, couldn’t this mostly be solved by writing up more detailed
> setup instructions (including all the right GUI installer links and
> walkthrough) on the course’s home page site? The instructions could be
> reviewed once at the beginning of every term to make sure they are
> still accurate. That seems like the sort of thing that could
> eventually also be put on the official Haskell website.
>
> Packaging software for windows, GHC in particular, is a pretty huge
> task. The volunteers who maintain this stuff are heroes, and it is
> disheartening that the only time this difficult work ever gets
> recognized is when people are angry something isn’t working as
> expected.
>
> Alec
> _______________________________________________
> 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 jgbm at acm.org  Sun Apr 26 23:54:24 2020
From: jgbm at acm.org (J. Garrett Morris)
Date: Sun, 26 Apr 2020 18:54:24 -0500
Subject: [Haskell-cafe] When did it become so hard to install Haskell on
	Windows?
In-Reply-To: <87lfmhizpx.fsf@jackkelly.name>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <a000e512-308e-ca5c-7f34-51f0ede33b31@centrum.cz>
 <CAP1qinaH2QC8_yr1L89=kSaQuk0mvcs__Sq-_QKYmT2vm_bbEw@mail.gmail.com>
 <DM6PR10MB304974569E4D2E72843CB997A0AE0@DM6PR10MB3049.namprd10.prod.outlook.com>
 <20200426194546.GA41308@straasha.imrryr.org>
 <56FC6BDD-463A-488E-B565-FED947BB319B@gmail.com>
 <87lfmhizpx.fsf@jackkelly.name>
Message-ID: <CALqZiMzDmA6Q4u5F0QCTA3TW+R80Dqmh3fg+ZfSs6ZaCwq3F2g@mail.gmail.com>

On Sun, Apr 26, 2020 at 6:39 PM Jack Kelly <jack at jackkelly.name> wrote:
> While I did email Tamar off-list, I should probably also thank him
> publicly. Packaging is a frustrating and often thankless part of Free
> Software development, and I appreciate that I can help a university
> teach Haskell to first-year students _at all_.

Let me publicly second this.  I appreciate the work Tamar is doing,
and I appreciate that it's taking advantage of modern Windows.

 /g

From mikhail.glushenkov at gmail.com  Mon Apr 27 03:46:54 2020
From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov)
Date: Mon, 27 Apr 2020 04:46:54 +0100
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <87o8re6e8u.fsf@smart-cactus.org>
References: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
 <87o8re6e8u.fsf@smart-cactus.org>
Message-ID: <CA+tcxkAJS6dbmtqXn848bN7AYX6d6gqbZT23UE_UAcpMoH7aYQ@mail.gmail.com>

Hi *,

On Sun, 26 Apr 2020, 05:52 Ben Gamari

> Note that Chocolatey is just option for installing GHC. Our Chocolatey
> packaging is generously maintained by Tamar as a convenient way to bring
> up GHC on Windows. However, we certainly wouldn't rely on it
> exclusively.
>
> Users who don't want to use Chocolatey are encouraged to use the usual
> binary distributions [1], as in the past.
>

Just wanted to let everyone know that cabal-install also doesn't require
Chocolatey to be installed on Windows: you can just download a binary from
https://www.haskell.org/cabal/download.html.

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

From ietf-dane at dukhovni.org  Mon Apr 27 08:26:18 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 27 Apr 2020 04:26:18 -0400
Subject: [Haskell-cafe] Installing haddock, cabal-install,
 ... when building GHC from git source
Message-ID: <20200427082618.GE41308@straasha.imrryr.org>

The GHC source tree includes sources for haddock, cabal, ... which I
expected to be able to somehow install as part of "make install" or
"make binary-dist" and installing from that, ...

But I've so far failed to find the right set of incantations.

Is it possible to install the additional libraries and utilities
included with the source when building GHC from source?

-- 
    Viktor.

From ben.franksen at online.de  Mon Apr 27 09:15:46 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 11:15:46 +0200
Subject: [Haskell-cafe] how can we fix our license?
Message-ID: <r867s3$drb$1@ciao.gmane.io>

After uploading a new release i found that this and all our earlier
release show on hackage as "GPL-2.0-only". What we have in our
darcs.cabal is "GPL-2". This was always intended to mean "or later".

I wanted to fix this and upload a new release that uses the new variant
"GPL-2.0-or-later" that I read about in the docs. But this isn't
accepted by hackage. The upload candidate page responds with

darcs-2.14.4/darcs.cabal:0:0: version with tags

and cabal check says

Warning: These warnings may cause trouble when distributing the package:
Warning: 'license: GPL-2.0' is not a known version of that license. The
known
versions are 2, 3. If this is not a mistake and you think it should be a
known
version then please file a ticket.
Warning: darcs.cabal:4:33: version with tags

Note we have

cabal-version: 1.24

in the cabal file, otherwise we could not support older ghc versions (we
currently support ghc-8.0 and later).

How can I fix this?


From dxld at darkboxed.org  Mon Apr 27 09:28:30 2020
From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=)
Date: Mon, 27 Apr 2020 11:28:30 +0200
Subject: [Haskell-cafe] how can we fix our license?
In-Reply-To: <r867s3$drb$1@ciao.gmane.io>
References: <r867s3$drb$1@ciao.gmane.io>
Message-ID: <20200427092829.GB47086@janet.servers.dxld.at>

Hi,

On Mon, Apr 27, 2020 at 11:15:46AM +0200, Ben Franksen wrote:
> After uploading a new release i found that this and all our earlier
> release show on hackage as "GPL-2.0-only". What we have in our
> darcs.cabal is "GPL-2". This was always intended to mean "or later".

This is an unfortunate artifact of Cabal's overly careful translation of
old-style licenses to SPDX ones on Hackage server. I've also been annoyed
by this in the past and did some investigating but IIRC there just isn't
any way to fix it on the server side at this point.

> I wanted to fix this and upload a new release that uses the new variant
> "GPL-2.0-or-later" that I read about in the docs. But this isn't
> accepted by hackage. [...]
>
> Note we have
>
> cabal-version: 1.24
>
> in the cabal file, otherwise we could not support older ghc versions (we
> currently support ghc-8.0 and later).

Yup and that's your problem, there just is no way to specify the new SPDX
license id without upping your cabal-version, I don't remember what version
that was introduced in though.

Note that while a higher cabal-version does mean the user has to build with
a more recent Cabal that's usually fine since even recent Cabal release'
support for older GHC versions goes quite a ways back. It does mean they
have to upgrade their cabal-install though.

--Daniel

From adam at ahri.net  Mon Apr 27 09:30:59 2020
From: adam at ahri.net (Adam)
Date: Mon, 27 Apr 2020 10:30:59 +0100
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
References: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
Message-ID: <CAHVMtHZaN=ir7GG_duMFJPmMzwJuYHKRu1=_=0tpn8MFMHYGZA@mail.gmail.com>

Hi Anthony,

I'll quickly say that I don't approve of the tone of your email; it is
needlessly inflammatory ("abhorrence", really?), and indeed incorrect:
PowerShell _is_ a standard Windows tool as already addressed in this email
chain. I personally don't like it as a tool, but that doesn't make it any
less standard. With that said, I'll move on:

If you're not a fan of Chocolately (me either!) there's another tool called
Scoop that gives you a package manager for Windows but avoids global
installation. If on the other hand you're simply not a fan of package
managers in Windows, see Richard O'Keefe and Mikhail Glushenkov's replies
regarding installing Stack/Cabal respectively in a more direct fashion.

I do think you highlight an important oversight that I think is especially
important for new users: each additional step required before having a
working Haskell environment will exponentially reduce the number of people
exposed to the language in a meaningful and helpful way - it's a problem of
UX more than technology, but a very important problem nonetheless.

Richard O'Keefe mentioned using Stack, which I find is a very easy route to
running Haskell as it gets the compiler and (helpfully) restricts the
package list to packages that interoperate, thus allowing students new to
the language to avoid any superfluous problems while trying to focus on
learning. https://tech.fpcomplete.com/haskell/get-started/windows should
have you covered. In an ideal world we wouldn't need even that extra Stack
step in between plain Windows and Windows+Haskell, but that ideal world
would be ignoring the meta-problem of package compatibility that can be
thorny, so it seems like a decent trade for now. What are your thoughts on
this?

With regards GHC error messages versus Hugs I'm not familiar with the
latter, but do struggle with the former, especially when compared to other
(albeit simpler) languages like Elm. I recently saw an article on a (fairly
recent?) capability to tune the error messages that GHC emits:
https://kodimensional.dev/type-errors - and I hope that as more people take
this on the ecosystem as a whole will become a bit friendlier and easier
for me to understand :) I wonder whether Hugs was able to emit friendlier
errors because the language was simpler then, or whether it's just that
we're in an inconvenient time in-between having both a more powerful set of
abstractions/inference and having human readable errors!

One thing I find that helps whenever an error message has type variables in
it (`a1` etc.) is to enable `{-# LANGUAGE ScopedTypeVariables #-}` and tell
the compiler what I _think_ the type should be in a few instances, and that
tends to iron out my misunderstandings.

Cheers,
Adam

On Sun, 26 Apr 2020 at 01:23, Anthony Clayden <anthony_clayden at clear.net.nz>
wrote:

> Remember GHC's motto is 'avoid success at all costs'. Then naturally it is
> prohibitively difficult to get to use GHC.
>
> For students/people who you want to encourage to love Haskell, especially
> on Windows,
> I'm astonished you're not using Hugs, especially WinHugs (2-click install).
> Despite being over a dozen years unsupported it is still
> orders-of-magnitude more friendly than GHC,
>  and has plenty of functionality (in Hugsmode) for undergraduate level.
> What's more Haskell from the intro texts just works on it;
> whereas GHC throws all sorts of obscure advanced type errors.
>
> I don't think powershell is a 'standard tool'. I use mostly Windows
> machines,
> I'm aware of powershell, I've never used it.
>
> Chocolatey is an abhorence. Fortunately I've never had to use it;
> I don't know why GHC would inflict it on anybody.
>
> Increasingly, GHC HQ is a cult/elite that doesn't want any new members.
> The difficulties in trying to use GHC just show how exclusive it has
> become.
>
>
>
> AntC
>
> > I appreciate that these things are standard tools for Windows
> developers, but it's worth noting how much harder it can make things
> for completely new people (either new developers or new to Windows).
>
> > At the start of the year, I prepared install instructions for university
> students who would be using Haskell as part of a first year CS
> course. We needed to use GHC 8.6.5 because certain libraries were not
> available for GHC 8.8.x (their base upper bounds hadn't updated, which
> ruled out haskell-dev), and tried to use Chocolatey as an experiment.
>
> > It was remarkably tough to get students set up on their own machines. I
> was planning on recommending the Haskell Platform installer for Semester
> 2 this year, and am disappointed to find that it no longer exists.
>
> > If it becomes too hard for students to install Haskell on their own
> Windows machines, it may become too hard for us to use Haskell as an
> educational tool, and I'd consider that a tragedy.
>
>
> _______________________________________________
> 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/20200427/3ca2dee9/attachment.html>

From ben.franksen at online.de  Mon Apr 27 09:48:29 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 11:48:29 +0200
Subject: [Haskell-cafe] how can we fix our license?
In-Reply-To: <20200427092829.GB47086@janet.servers.dxld.at>
References: <r867s3$drb$1@ciao.gmane.io>
 <20200427092829.GB47086@janet.servers.dxld.at>
Message-ID: <r869pd$14ue$1@ciao.gmane.io>

Hi Daniel

thanks for your reply.

Am 27.04.20 um 11:28 schrieb Daniel Gröber:
> Note that while a higher cabal-version does mean the user has to build with
> a more recent Cabal that's usually fine since even recent Cabal release'
> support for older GHC versions goes quite a ways back. It does mean they
> have to upgrade their cabal-install though.

I have been working a few days on getting the package to build cleanly
with all ghc versions from 8.0 up to 8.10. During that time I have
played with cabal-version settings a lot and I found that 1.24 is be the
only one that allows clean (warning-free) builds for all supported ghc
versions. This is despite the fact that I am using cabal-install-3.2;
there is some magic going on that switches the cabal file parser back to
1.24 for ghc-8.0, no matter whether cabal-version specifies newer.

The following approach might work:

It seems hackage allows me to change the package description in a
revision. So I could make a revision that adds a line or two to the
package description to point out the difference between the license
displayed by hackage and the one intended.


From dxld at darkboxed.org  Mon Apr 27 10:04:16 2020
From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=)
Date: Mon, 27 Apr 2020 12:04:16 +0200
Subject: [Haskell-cafe] how can we fix our license?
In-Reply-To: <r869pd$14ue$1@ciao.gmane.io>
References: <r867s3$drb$1@ciao.gmane.io>
 <20200427092829.GB47086@janet.servers.dxld.at>
 <r869pd$14ue$1@ciao.gmane.io>
Message-ID: <20200427100416.GC47086@janet.servers.dxld.at>

Hi Ben,

On Mon, Apr 27, 2020 at 11:48:29AM +0200, Ben Franksen wrote:
> [..] I found that 1.24 is be the
> only one that allows clean (warning-free) builds for all supported ghc
> versions. [...]
> there is some magic going on that switches the cabal file parser back to
> 1.24 for ghc-8.0, no matter whether cabal-version specifies newer.

Are we talking about GHC or Cabal warnings? If Cabal that sounds really
weird. Technically speaking it isn't possible for Cabal to switch to a
different parser based on the ghc version as the cabal-version specifies
the grammer of the cabal file and GHC version detection happens after the
cabal file has long been parsed.

Can you elaborate on the type of warnings you're getting?

> This is despite the fact that I am using cabal-install-3.2;

Personally I find 2.4 much more stable than 3.2, maybe this is just a
cabal-install bug or something. I just checked and SPDX was introduced in
[cabal-version: 2.2] so maybe you can try with that and see if you get the
weird behaviour on ghc-8.0?

I'd really like to get to the root of the problem here because the way
Cabal format evolution works we really want people being able to use newer
versions with older GHCs.

[cabal-version: 2.2]: https://www.haskell.org/cabal/users-guide/file-format-changelog.html#cabal-version-2-2

> The following approach might work:
>
> It seems hackage allows me to change the package description in a
> revision. So I could make a revision that adds a line or two to the
> package description to point out the difference between the license
> displayed by hackage and the one intended.

Honestly if you have appropriate GPL headers in your source files anyone
who cares about the distinction between v2-only and v2-or-later will be
able to tell what's going on. A comment sure couldn't hurt though.

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

From ben.franksen at online.de  Mon Apr 27 10:32:19 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 12:32:19 +0200
Subject: [Haskell-cafe] how can we fix our license?
In-Reply-To: <20200427100416.GC47086@janet.servers.dxld.at>
References: <r867s3$drb$1@ciao.gmane.io>
 <20200427092829.GB47086@janet.servers.dxld.at> <r869pd$14ue$1@ciao.gmane.io>
 <20200427100416.GC47086@janet.servers.dxld.at>
Message-ID: <r86cbk$3dc4$1@ciao.gmane.io>

Am 27.04.20 um 12:04 schrieb Daniel Gröber:
> I'd really like to get to the root of the problem here because the way
> Cabal format evolution works we really want people being able to use newer
> versions with older GHCs.

If I specify "cabal-version: 2.2" I get:

>cabal build --enable-tests --disable-optimization
--with-compiler=/opt/ghc/8.0.2/bin/ghc
Resolving dependencies...
Build profile: -w ghc-8.0.2 -O0
In order, the following will be built (use -v for more details):
 - darcs-2.14.3 (lib:darcs, exe:darcs, test:darcs-test) (first run)
Warning: darcs.cabal: Unknown fields: autogen-modules (line 363)
Fields allowed in this section:
exposed-modules, reexported-modules, required-signatures,
exposed-signatures, exposed, buildable, build-tools, build-depends,
cpp-options, cc-options, ld-options, pkgconfig-depends, frameworks,
extra-framework-dirs, c-sources, js-sources, default-language,
other-languages, default-extensions, other-extensions, extensions,
extra-libraries, extra-ghci-libraries, extra-lib-dirs, includes,
install-includes, include-dirs, hs-source-dirs, other-modules,
ghc-prof-options, ghcjs-prof-options, ghc-shared-options,
ghcjs-shared-options, ghc-options, ghcjs-options, jhc-options,
hugs-options, nhc98-options
Configuring darcs-2.14.3...
setup: This package description follows version 2.2 of the Cabal
specification. This tool only supports up to version 1.24.2.0.

The warning is okay, I get that in any case, but the last line is an
error. The problem here seems to be that we have a custom Setup.hs.

BTW, the "cabal-version:" has been added precisely to allow forward
compatibility, so that a newer cabal version can still handle the old
syntax. See

https://www.haskell.org/cabal/users-guide/developing-packages.html#pkg-field-cabal-version

>> It seems hackage allows me to change the package description in a
>> revision. So I could make a revision that adds a line or two to the
>> package description to point out the difference between the license
>> displayed by hackage and the one intended.
> 
> Honestly if you have appropriate GPL headers in your source files anyone
> who cares about the distinction between v2-only and v2-or-later will be
> able to tell what's going on. A comment sure couldn't hurt though.

Agreed, so I guess this is what I'll do then.

Cheers
Ben


From jo at durchholz.org  Mon Apr 27 10:36:26 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 27 Apr 2020 12:36:26 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
Message-ID: <b157c61c-f654-f8bd-75c1-514bc5ca1a09@durchholz.org>

Just to add the data points I can contribute...

>   * First, I have to subscribe to a newsletter? Really? I guess this is
>     entirely optional, but the instructions don't make it sound so. 
> 
> Step 1 is completely optional and you don’t have to subscribe to any 
> news letter.

It's a bit surprising to see this as the first option.
It's also not saying the consequences of subscribing: How much mail will 
you get, are you going to be bombarded with useless spam or just with 
information about bug fixes.

So it's the classical downturner: Asking permission for something that 
isn't clearly described.
Plus not clearly stating that it's optional, which has a whiff of the 
stink of manipulativeness.
For people that have already been subjected to such maneuvers, it's 
framing the whole remaining process as "they are trying to manipulate me 
into stuff I probably don't want", and that sets the tone where people 
start writing rants even if they don't want to. (It's the typical 
outcome of A/B testing. A/B testing will tell you how people click, not 
how they feel.)

>   * Then I have to know what powershell.exe is, use an administrative
>     prompt, and enter scary commands in it.
> 
> Powershell has been the standard shell in Windows for well over the past 
> decade. Every single script from Microsoft or third parties come with 
> powershell for automation.
> 
> It’s understandable that you may not know it since your primary platform 
> isn’t Windows. But it’s been included in every single Windows version 
> for the past 13 years.
> 
> An administrative prompt is nothing different than running sudo or 
> clicking on that installer that you **assumed** not to be scary because 
> you didn’t see the actions it was performing.
> 
> That scary looking command is nothing but a curl command allowing the 
> one time execution of a script from a remote source. As in a script 
> that’s not physically on your machine.
> 
> So what exactly makes this scary? Is it because
> 
> Set-ExecutionPolicy Bypass -Scope Process -Force; 
> [System.Net.ServicePointManager]::SecurityProtocol = 
> [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex 
> ((New-Object 
> System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
> 
> Is more verbose than
> 
> |curl -sSL https://path.to.some.script/ | sh|
> 
> or because the technologies used while completely standard on Windows 
> aren’t known to the casual user?

Part of the problem is indeed that you don't know what the commands are 
actually doing, and the process is exposing that scary part.
For me (as a hardcore developer), it's that I don't know what this is 
doing, so I'll be extra cautious, and extra watchful about additional 
red flags.

However, the approach is also raising a big red flag.
An installer requires a certificate signed by Microsoft (otherwise it 
will complain that the publisher isn't known and the software can damage 
your computer).
The thing about this is: Microsoft has a track record of no complaints 
(otherwise they would have revoked the certificate). This helps assure 
the users that the publisher is trustworthy, both for his intentions and 
his technical competence.
Asking people to use an admin shell (regardless of whether it's 
Powershell or good ol' cmd.exe) is eliminating these mechanisms.

Note that Microsoft's installer certificate is mostly security circus, 
with pretty little real value.
However, it does help, a bit.
And adhering to it is a signal to your users that you are indeed going 
out of your way to reassure them.
It's a bit like with a car mechanic. If the workplace is grubby, people 
start questioning the attention to detail, and overall competence; they 
may still send cars for repair, but they will be more intent on finding 
issues, sometimes asking about things that don't matter (but they don't 
know this), sometimes being overly suspicious (but they don't really 
know how much suspicion is appropriate). If the workplace is clean, the 
standard assumption is that in this shop, there's attention to detail 
and they don't have to check every detail on their own.

Just my 2 cents, in the hope that they are helping.
I also agree that packaging is typical background work that's always 
underappreciated, and gets attention only if it doesn't work. Thanks for 
doing it!

Regards,
Jo

From ben.franksen at online.de  Mon Apr 27 10:55:57 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 12:55:57 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <b157c61c-f654-f8bd-75c1-514bc5ca1a09@durchholz.org>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 <b157c61c-f654-f8bd-75c1-514bc5ca1a09@durchholz.org>
Message-ID: <r86dnu$2kon$1@ciao.gmane.io>

Am 27.04.20 um 12:36 schrieb Joachim Durchholz:
> It's a bit like with a car mechanic. If the workplace is grubby, people
> start questioning the attention to detail, and overall competence; they
> may still send cars for repair, but they will be more intent on finding
> issues, sometimes asking about things that don't matter (but they don't
> know this), sometimes being overly suspicious (but they don't really
> know how much suspicion is appropriate). If the workplace is clean, the
> standard assumption is that in this shop, there's attention to detail
> and they don't have to check every detail on their own.

Funny, for me it's exactly the other way around: when I see a repair
shop which is dirty and with tools and parts strewn around I think: They
are doing acual work here. When I see a clean and orderly shop I tend to
think: They care about appearances, rather than getting the work done.

This very much differs from how I view the /result/ of the work: here I
regard everything that has not been done in a clean and orderly fashion
as deficient. (And that goes for software, too, especially if it is mature.)

Cheers
Ben


From dxld at darkboxed.org  Mon Apr 27 11:30:54 2020
From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=)
Date: Mon, 27 Apr 2020 13:30:54 +0200
Subject: [Haskell-cafe] how can we fix our license?
In-Reply-To: <r86cbk$3dc4$1@ciao.gmane.io>
References: <r867s3$drb$1@ciao.gmane.io>
 <20200427092829.GB47086@janet.servers.dxld.at>
 <r869pd$14ue$1@ciao.gmane.io>
 <20200427100416.GC47086@janet.servers.dxld.at>
 <r86cbk$3dc4$1@ciao.gmane.io>
Message-ID: <20200427113054.GD47086@janet.servers.dxld.at>

Hi Ben,

On Mon, Apr 27, 2020 at 12:32:19PM +0200, Ben Franksen wrote:
> If I specify "cabal-version: 2.2" I get:
>
> >cabal build --enable-tests --disable-optimization
> --with-compiler=/opt/ghc/8.0.2/bin/ghc
> [...]
> setup: This package description follows version 2.2 of the Cabal
> specification. This tool only supports up to version 1.24.2.0.

Ah yeah, but see that's because you're running cabal-install 1.24. Like I
said you need a more recent cabal-install but cabal-install-2.2 or 2.4
should build just fine even with ghc-8.0 so that's not really a problem for
users usually.

> The warning is okay, I get that in any case, but the last line is an
> error.

So this is in fact an error then, right? Cabal doesn't just try to carry on
with a .cabal file it can't parse properly, since that would be very
surprising.

> The problem here seems to be that we have a custom Setup.hs.

I don't think that's related. The problem is that the cabal-install version
is the upper bound for the `cabal-version:` you can build with it. If you
want to build a package with cabal-version:2.2 you need at least
cabal-install-2.2.*.

--Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200427/78d40dcb/attachment.sig>

From ben.franksen at online.de  Mon Apr 27 11:52:38 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 13:52:38 +0200
Subject: [Haskell-cafe] how can we fix our license?
In-Reply-To: <20200427113054.GD47086@janet.servers.dxld.at>
References: <r867s3$drb$1@ciao.gmane.io>
 <20200427092829.GB47086@janet.servers.dxld.at> <r869pd$14ue$1@ciao.gmane.io>
 <20200427100416.GC47086@janet.servers.dxld.at> <r86cbk$3dc4$1@ciao.gmane.io>
 <20200427113054.GD47086@janet.servers.dxld.at>
Message-ID: <r86h27$1ut1$1@ciao.gmane.io>

Am 27.04.20 um 13:30 schrieb Daniel Gröber:
> On Mon, Apr 27, 2020 at 12:32:19PM +0200, Ben Franksen wrote:
>> If I specify "cabal-version: 2.2" I get:
>>
>>> cabal build --enable-tests --disable-optimization
>> --with-compiler=/opt/ghc/8.0.2/bin/ghc
>> [...]
>> setup: This package description follows version 2.2 of the Cabal
>> specification. This tool only supports up to version 1.24.2.0.
> 
> Ah yeah, but see that's because you're running cabal-install 1.24.

No, I don't:

>cabal --version
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library

Cheers
Ben


From ben.franksen at online.de  Mon Apr 27 12:38:40 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 14:38:40 +0200
Subject: [Haskell-cafe] Windows Haskell CI
Message-ID: <r86jog$gk7$1@ciao.gmane.io>

Like ghc itself, we (the Darcs team) also have trouble providing
adequate support for Windows. I personally haven't (seriously) used
Windows for decades. So I thought we could at least do some automated
building and testing for Windows on some CI system, perhaps even
automatically build Windows binaries.

Is there a free CI service that you could recommend that ideally
supports at least Windows, MacOS, and Linux and that has good support
for Haskell programs, i.e. some recent ghc and cabal pre-installed? If
not, what could be an alternative solution?

Any kind of comments or hints are appreciated.

Cheers
Ben


From fa-ml at ariis.it  Mon Apr 27 12:57:49 2020
From: fa-ml at ariis.it (Francesco Ariis)
Date: Mon, 27 Apr 2020 14:57:49 +0200
Subject: [Haskell-cafe] Windows Haskell CI
In-Reply-To: <r86jog$gk7$1@ciao.gmane.io>
References: <r86jog$gk7$1@ciao.gmane.io>
Message-ID: <20200427125749.GB15031@extensa>

Hello Ben,
    I have a daring (and probably) proposal.

On Mon, Apr 27, 2020 at 02:38:40PM +0200, Ben Franksen wrote:
> Like ghc itself, we (the Darcs team) also have trouble providing
> adequate support for Windows. I personally haven't (seriously) used
> Windows for decades. So I thought we could at least do some automated
> building and testing for Windows on some CI system, perhaps even
> automatically build Windows binaries.

Recently I was contacted by a user of a small script of mine [1].
He downloaded the (x86_64) binary and used it on Windows (10?) via
«Windows Subsystem of Linux».

     $ uname -a
     Linux DESKTOP-AHPUUO5 4.4.0-18362-Microsoft #476-Microsoft Fri Nov 01
     16:53:00 PST 2019 x86_64 x86_64
     x86_64 GNU/Linux

I found this fantastic as I loathe dealing with Wine of Virtual Machines
to provide Win users with a binary.

I have not touched Windows since XP, but how feasible is it to call it
a day and tell Win users: «From now on, Darcs will be available on
Windows via WSL»?
-F


[1] https://hackage.haskell.org/package/gscholar-rss


From ben.franksen at online.de  Mon Apr 27 13:09:42 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 15:09:42 +0200
Subject: [Haskell-cafe] Windows Haskell CI
In-Reply-To: <20200427125749.GB15031@extensa>
References: <r86jog$gk7$1@ciao.gmane.io> <20200427125749.GB15031@extensa>
Message-ID: <r86lim$mr2$1@ciao.gmane.io>

Hi Franceso

Am 27.04.20 um 14:57 schrieb Francesco Ariis:
> Recently I was contacted by a user of a small script of mine [1].
> He downloaded the (x86_64) binary and used it on Windows (10?) via
> «Windows Subsystem of Linux».
> 
>      $ uname -a
>      Linux DESKTOP-AHPUUO5 4.4.0-18362-Microsoft #476-Microsoft Fri Nov 01
>      16:53:00 PST 2019 x86_64 x86_64
>      x86_64 GNU/Linux
> 
> I found this fantastic as I loathe dealing with Wine of Virtual Machines
> to provide Win users with a binary.
> 
> I have not touched Windows since XP, but how feasible is it to call it
> a day and tell Win users: «From now on, Darcs will be available on
> Windows via WSL»?

It is tempting. But it feels a bit like defeat. Large parts of the
Haskell ecosystem work perfectly fine on Windows; a lot of effort has
been spent to make standard IO actions work there. I think it would be a
waste not to use that infrastructure and build native Windows binaries.

Still, thanks for mentioning the possibility. We may come back to it as
a last resort.

Cheers
Ben


From irfon at ambienautica.com  Mon Apr 27 15:10:29 2020
From: irfon at ambienautica.com (Irfon-Kim Ahmad)
Date: Mon, 27 Apr 2020 11:10:29 -0400
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <CAHVMtHZaN=ir7GG_duMFJPmMzwJuYHKRu1=_=0tpn8MFMHYGZA@mail.gmail.com>
References: <CAM7nRYS6SkWf72tCe9n2kGef8_h-SpE9Ut5UuyMPF2_qgysVCQ@mail.gmail.com>
 <CAHVMtHZaN=ir7GG_duMFJPmMzwJuYHKRu1=_=0tpn8MFMHYGZA@mail.gmail.com>
Message-ID: <f20a815d-18dd-2cda-d174-e7c423e11837@ambienautica.com>

I think that one thing that's come up repeatedly but seems to not be 
getting enough attention is this:

The existence of (any number of) simpler ways to install the software is 
entirely moot in terms of the new-user experience if the typical new 
user is unaware of them. In short, when considering attracting new users 
to the platform, the ONLY method is whatever the download-for-Windows 
instructions on haskell.org displays. All other methods do not exist.

This is where I think some of the sense of elitism can come from: A lot 
of responses assume that everybody at every level of exposure has full 
access to all the knowledge embodied in the community. Furthermore, the 
goals as they were laid out early in the discussion (make it easy to 
have multiple versions installed at the same time, make it easy to 
update the components separately) are things that matter only to 
experienced Haskell developers, not new users, and those experiences 
Haskell developers are both more likely to know about alternate methods 
available and more likely to be able to manage to figure this stuff out 
on their own.

Given that, I believe basically the complaint (and I'm here paraphrasing 
for others, so correct me if I'm wrong) is that the method that appears 
front and centre on the download-for-Windows instructions on haskell.org 
should always be the simplest method for entirely new users with 
minimal-to-zero knowledge of Haskell to use. (Of course, there's no harm 
in having a link to "advanced" instructions for those that want them.)

Think about Python, as an example of a language that has tremendous 
outreach, is often recommended as a great first language to learn, and 
garners new adherents daily. If you go to Python.org and mouse over 
"Downloads", it says "Download for Windows" and there's a single button 
labelled "Python 3.8.2" clicking that gives you an executable installer 
that you run, click next a bunch of times, and you're done. They don't 
even bother asking if you want 32 or 64 bit up-front. It's as easy as 
installing a game. Anyone who's used Python knows that there are myriad 
other ways of getting and updating it, myriad other components you can 
also install, etc., etc. But that's left to advanced instructions or for 
people who know where to find those resources. The core "get you started 
as a new user" experience is something that anybody can navigate trivially.


On 2020-04-27 5:30 a.m., Adam wrote:
> Hi Anthony,
>
> I'll quickly say that I don't approve of the tone of your email; it is 
> needlessly inflammatory ("abhorrence", really?), and indeed incorrect: 
> PowerShell _is_ a standard Windows tool as already addressed in this 
> email chain. I personally don't like it as a tool, but that doesn't 
> make it any less standard. With that said, I'll move on:
>
> If you're not a fan of Chocolately (me either!) there's another tool 
> called Scoop that gives you a package manager for Windows but avoids 
> global installation. If on the other hand you're simply not a fan of 
> package managers in Windows, see Richard O'Keefe and Mikhail 
> Glushenkov's replies regarding installing Stack/Cabal respectively in 
> a more direct fashion.
>
> I do think you highlight an important oversight that I think is 
> especially important for new users: each additional step required 
> before having a working Haskell environment will exponentially reduce 
> the number of people exposed to the language in a meaningful and 
> helpful way - it's a problem of UX more than technology, but a very 
> important problem nonetheless.
>
> Richard O'Keefe mentioned using Stack, which I find is a very easy 
> route to running Haskell as it gets the compiler and (helpfully) 
> restricts the package list to packages that interoperate, thus 
> allowing students new to the language to avoid any superfluous 
> problems while trying to focus on learning. 
> https://tech.fpcomplete.com/haskell/get-started/windows should have 
> you covered. In an ideal world we wouldn't need even that extra Stack 
> step in between plain Windows and Windows+Haskell, but that ideal 
> world would be ignoring the meta-problem of package compatibility that 
> can be thorny, so it seems like a decent trade for now. What are your 
> thoughts on this?
>
> With regards GHC error messages versus Hugs I'm not familiar with the 
> latter, but do struggle with the former, especially when compared to 
> other (albeit simpler) languages like Elm. I recently saw an article 
> on a (fairly recent?) capability to tune the error messages that GHC 
> emits: https://kodimensional.dev/type-errors - and I hope that as more 
> people take this on the ecosystem as a whole will become a bit 
> friendlier and easier for me to understand :) I wonder whether Hugs 
> was able to emit friendlier errors because the language was simpler 
> then, or whether it's just that we're in an inconvenient time 
> in-between having both a more powerful set of abstractions/inference 
> and having human readable errors!
>
> One thing I find that helps whenever an error message has type 
> variables in it (`a1` etc.) is to enable `{-# LANGUAGE 
> ScopedTypeVariables #-}` and tell the compiler what I _think_ the type 
> should be in a few instances, and that tends to iron out my 
> misunderstandings.
>
> Cheers,
> Adam
>
> On Sun, 26 Apr 2020 at 01:23, Anthony Clayden 
> <anthony_clayden at clear.net.nz <mailto:anthony_clayden at clear.net.nz>> 
> wrote:
>
>     Remember GHC's motto is 'avoid success at all costs'. Then
>     naturally it is prohibitively difficult to get to use GHC.
>
>     For students/people who you want to encourage to love Haskell,
>     especially on Windows,
>     I'm astonished you're not using Hugs, especially WinHugs (2-click
>     install).
>     Despite being over a dozen years unsupported it is still
>     orders-of-magnitude more friendly than GHC,
>      and has plenty of functionality (in Hugsmode) for undergraduate
>     level.
>     What's more Haskell from the intro texts just works on it;
>     whereas GHC throws all sorts of obscure advanced type errors.
>
>     I don't think powershell is a 'standard tool'. I use mostly
>     Windows machines,
>     I'm aware of powershell, I've never used it.
>
>     Chocolatey is an abhorence. Fortunately I've never had to use it;
>     I don't know why GHC would inflict it on anybody.
>
>     Increasingly, GHC HQ is a cult/elite that doesn't want any new
>     members.
>     The difficulties in trying to use GHC just show how exclusive it
>     has become.
>
>
>
>     AntC
>
>     > I appreciate that these things are standard tools for Windows
>     developers, but it's worth noting how much harder it can make things
>     for completely new people (either new developers or new to Windows).
>
>     > At the start of the year, I prepared install instructions for university
>     students who would be using Haskell as part of a first year CS
>     course. We needed to use GHC 8.6.5 because certain libraries were not
>     available for GHC 8.8.x (their base upper bounds hadn't updated, which
>     ruled out haskell-dev), and tried to use Chocolatey as an experiment.
>
>     > It was remarkably tough to get students set up on their own machines. I
>     was planning on recommending the Haskell Platform installer for Semester
>     2 this year, and am disappointed to find that it no longer exists.
>
>     > If it becomes too hard for students to install Haskell on their own
>     Windows machines, it may become too hard for us to use Haskell as an
>     educational tool, and I'd consider that a tragedy.
>
>
>     _______________________________________________
>     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/20200427/83879006/attachment.html>

From jo at durchholz.org  Mon Apr 27 15:34:47 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 27 Apr 2020 17:34:47 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <r86dnu$2kon$1@ciao.gmane.io>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 <b157c61c-f654-f8bd-75c1-514bc5ca1a09@durchholz.org>
 <r86dnu$2kon$1@ciao.gmane.io>
Message-ID: <8f0bbda7-0e0a-45a7-2f6c-ab0225db0075@durchholz.org>

Am 27.04.20 um 12:55 schrieb Ben Franksen:
> Funny, for me it's exactly the other way around: when I see a repair
> shop which is dirty and with tools and parts strewn around I think: They
> are doing acual work here. When I see a clean and orderly shop I tend to
> think: They care about appearances, rather than getting the work done.

That used to be a useful guidelines a few decades ago, but that changed 
a lot in the last 10, 20 years.
Of course, if it's an old-school mechanis, this may be the best workshop 
ever - it will just go away when the current owner retires.

> This very much differs from how I view the /result/ of the work: here I
> regard everything that has not been done in a clean and orderly fashion
> as deficient. (And that goes for software, too, especially if it is mature.)

Sure, but how do you judge that work if you're not an expert?
With old-style cars, you could inspect the machinery, even if you 
weren't fully educated you could see if there was grime in the gears or 
not. With today's cars and their electronics, and today's 
millions-of-lines software, that kind of check has become impossible.

From siddu.druid at gmail.com  Mon Apr 27 16:41:25 2020
From: siddu.druid at gmail.com (Siddharth Bhat)
Date: Mon, 27 Apr 2020 22:11:25 +0530
Subject: [Haskell-cafe] Hugs sources WITH TESTS?
Message-ID: <CAPipc=0QgkC-dqTiOavSndsiO3kGSscoYmFOpzqta0A76eB=FA@mail.gmail.com>

Hello,

I got interested in hugs thanks to the surrounding discussion and went
spelunking in their codebase. Weirdly, I can't find a test suite!
- The November 2003 version
<https://github.com/bollu/hugs/blob/master/src/Makefile.in#L280> has a rule
in the makefile to cd ../tests . However, such a folder does not exist in
the source tree.
- the September 2006 version
<https://github.com/haskell-implementations/hugs/blob/master/src/Makefile.in>,
doesn't have a test / check rule at all.

I find this baffling. Where did the tests go?!

If you have access to them --- or if you the story behind where the tests
are, please do let me know!

Thanks a lot,
~Siddharth

-- 
https://bollu.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200427/08252a15/attachment.html>

From lemming at henning-thielemann.de  Mon Apr 27 16:28:00 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 27 Apr 2020 18:28:00 +0200 (CEST)
Subject: [Haskell-cafe] Windows Haskell CI
In-Reply-To: <r86jog$gk7$1@ciao.gmane.io>
References: <r86jog$gk7$1@ciao.gmane.io>
Message-ID: <alpine.DEB.2.20.2004271825270.4160@sputnik>


On Mon, 27 Apr 2020, Ben Franksen wrote:

> Is there a free CI service that you could recommend that ideally
> supports at least Windows, MacOS, and Linux and that has good support
> for Haskell programs, i.e. some recent ghc and cabal pre-installed? If
> not, what could be an alternative solution?

I only know of AppVeyor. I think it's Windows only, but I had no success 
to build something, so far. :-(


>From time to time Windows users asked me to make my 
MIDI-to-music-box-stripe converter available for Windows:
    https://hackage.haskell.org/package/midi-music-box

From ben.franksen at online.de  Mon Apr 27 16:40:25 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 18:40:25 +0200
Subject: [Haskell-cafe] Windows Haskell CI
In-Reply-To: <CALqZiMwCzNBn+MwydnYq4vuiiwD=WPqPRJE3QdBBF3anKHbR7A@mail.gmail.com>
References: <r86jog$gk7$1@ciao.gmane.io>
 <CALqZiMwCzNBn+MwydnYq4vuiiwD=WPqPRJE3QdBBF3anKHbR7A@mail.gmail.com>
Message-ID: <be177d29-861d-99cf-2425-2b49117aeaf1@online.de>

Am 27.04.20 um 15:26 schrieb J. Garrett Morris:
> You might find Tamar's post on Windows packaging of GHC useful. He
> includes CI support as one of the motivations:
> 
> https://hub.zhox.com/posts/introducing-haskell-dev/

Yes, very useful indeed. Thanks!

Cheers
Ben

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

From ben.franksen at online.de  Mon Apr 27 17:32:57 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 27 Apr 2020 19:32:57 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <8f0bbda7-0e0a-45a7-2f6c-ab0225db0075@durchholz.org>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 <b157c61c-f654-f8bd-75c1-514bc5ca1a09@durchholz.org>
 <r86dnu$2kon$1@ciao.gmane.io>
 <8f0bbda7-0e0a-45a7-2f6c-ab0225db0075@durchholz.org>
Message-ID: <r87509$1fre$1@ciao.gmane.io>

Am 27.04.20 um 17:34 schrieb Joachim Durchholz:
> Am 27.04.20 um 12:55 schrieb Ben Franksen:
>> This very much differs from how I view the /result/ of the work: here I
>> regard everything that has not been done in a clean and orderly fashion
>> as deficient. (And that goes for software, too, especially if it is
>> mature.)
> 
> Sure, but how do you judge that work if you're not an expert?
> With old-style cars, you could inspect the machinery, even if you
> weren't fully educated you could see if there was grime in the gears or
> not. With today's cars and their electronics, and today's
> millions-of-lines software, that kind of check has become impossible.

Which is why I dislike modern cars. If I ever happen to buy another one
in my lifetime it will be an oldtimer.

Cheers
Ben


From leah at vuxu.org  Mon Apr 27 17:44:41 2020
From: leah at vuxu.org (Leah Neukirchen)
Date: Mon, 27 Apr 2020 19:44:41 +0200
Subject: [Haskell-cafe] Munich Virtual Haskell Meeting, 2020-04-30 @ 19:30
Message-ID: <871ro8x1py.fsf@vuxu.org>

Dear all,

This week, our monthly Munich Haskell Meeting will take place again on
Thursday, April 30.

**Due to curfew in Bavaria, this meeting will take place online!**

For details see here:

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

A Google Meet link to join the room will be provided on Thursday.

Everybody is welcome, especially the Haskellers from Bavaria that do
not usually come to our Munich meetings due to travel distance!

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

From dominik.schrempf at gmail.com  Mon Apr 27 19:36:35 2020
From: dominik.schrempf at gmail.com (Dominik Schrempf)
Date: Mon, 27 Apr 2020 21:36:35 +0200
Subject: [Haskell-cafe] Problem with publishing project/packages
Message-ID: <87wo60oh4s.fsf@gmail.com>

Hello,

I am not sure if this is the right place to report/discuss the following issue,
but I have been fiddling around with properly publishing a project I am
developing in Haskell for quite some time now. I have encountered various
difficulties that I would like to share and hear your opinion about, and also
your suggestions about what I could improve, and probably also, how the Haskell
ecosystem could be improved.

First, I use Stack+Hpack to manage `.cabal` files. I know, that this combination
has summoned many controversies, but I don't want to spend hours fiddling around
in my `.cabal` files and on the version bounds, so decided for this option. I
use strict PVP bounds (--pvp-bounds both options), so that at least compilation
should be reproducible, albeit only allowing the specific set of library
versions present in the Stack resolver.

My project does heavy numerical calculations, so I was awaiting the support of
LLVM9.0, which will come with GHC 8.10, for a long time. In the meantime, I
tried to compile and publish my project in its current state with the newest
Stack resolver 15.x with GHC 8.8.3. On my local machine, compilation and the
development cycle work reasonably well, but as soon as I try to publish my work,
I have serious trouble.

First, I encountered an issue with auto generated modules of the packages
causing trouble in the `.cabal` files generated by Hpack [1]. I think this is
because the Cabal specification was improved (i.e., has changed), and new
specifications have to be honored. I try to work around the issue by directly
specifying the newest Cabal specification 3.0 and by tinkering around with the
flags, until Hpack produces files compatible with the newest version of Cabal.
Finally, I can create source tarballs with `stack sdist --pvp-bounds both`.
However, I cannot upload these tarballs, because somehow, the created `.cabal`
files in the source tarballs include dependencies of the following form:
`base : {} >= x.y, <= z.a` (or something similar), and Hackage chokes on this
form (is this a new syntax? or is it just a bug?). So I think, maybe this is
caused by an incompatibility of Stack with my Cabal or cabal-install version,
which are newer than the newest ones officially supported by Stack. I had
already lost one day of working time at this point.

I did not give up, but decided to install a Cabal version officially supported
by Stack. Also, I removed all my dependencies on auto-generated modules from the
packages and the `.cabal` files, I reverted other changes I had implemented
because of the Cabal specification change (for example, reverting all license
identifiers). I managed to compile and publish my project on Hackage. However,
Hackage is not able to compile the packages and show the documentation (which is
what I need most). Because I am going the easy route, and use strict PVP bounds,
Hackage cannot compile my packages because they depend on base >= 4.13, and
Cabal version 3.0. It took me another hour or so, to find out that the official
package repository of Haskell does not support the official base library which
has been published over six months ago. From a users point of view, this is
unacceptable. I have found some resources about this issue now, but I was not
aware of this discrepancy before experiencing it.

So my next thought is: "Let's just put it on Stackage, because the best days of
Hackage seem to be over...". However, I cannot do that, because my project needs
to compile on Hackage in order to be put on Stackage...

I guess all this is consequence of using an operating system with up-to-date
packages (Arch Linux), and my inherent demand to use the newest compiler, and so
on. However, I feel that it is not entirely my fault, the new compiler with the
new base libraries should be supported by the official repository, and in a
coherent way by the most widely used build tools Cabal and Stack (which uses
Hpack by default, by the way).

I sincerely apologize for being so harsh, but I am angry at the ecosystem, and
angry at myself, because, obviously, I don't know enough to get things done.

Thanks for your feedback, it is appreciated!

Dominik Schrempf

References:
[1] https://github.com/sol/hpack/issues/384
[2] In case of interest, the project I am developing is a set of
    libraries/binaries to be used in evolutionary biology
    https://github.com/dschrempf/elynx


From lemming at henning-thielemann.de  Mon Apr 27 21:43:16 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 27 Apr 2020 23:43:16 +0200 (CEST)
Subject: [Haskell-cafe] Problem with publishing project/packages
In-Reply-To: <87wo60oh4s.fsf@gmail.com>
References: <87wo60oh4s.fsf@gmail.com>
Message-ID: <alpine.DEB.2.20.2004272338490.4160@sputnik>


On Mon, 27 Apr 2020, Dominik Schrempf wrote:

> So my next thought is: "Let's just put it on Stackage, because the best 
> days of Hackage seem to be over...". However, I cannot do that, because 
> my project needs to compile on Hackage in order to be put on Stackage...

You only need to _release_ your package on Hackage, it is not required 
that the Hackage server can build it. Stackage builds packages on its own.

If Hackage fails to build your documentation, you can create it yourself 
and upload it manually:

$ cabal haddock --for-hackage --hyperlink-source
$ cabal upload --documentation --publish dist/pkg-0.1-docs.tar.gz

From raoknz at gmail.com  Tue Apr 28 04:10:35 2020
From: raoknz at gmail.com (Richard O'Keefe)
Date: Tue, 28 Apr 2020 16:10:35 +1200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
In-Reply-To: <DM6PR03MB4331677C99DBBD1E4536616DA1AE0@DM6PR03MB4331.namprd03.prod.outlook.com>
References: <DM6PR03MB4331677C99DBBD1E4536616DA1AE0@DM6PR03MB4331.namprd03.prod.outlook.com>
Message-ID: <CABcYAd+k+AtiT1MXO1nis7C1jU4roUExzcvk3+kyEp93GgkLpw@mail.gmail.com>

For another data point, I just installed Java SE 14 on a Windows laptop.
Bing search for Download JDK 14 for Windows, select page, clickety
clickety, all pretty obvious, long wait, click Run, clickety clickety, done.
I never had to leave Edge except to say yes to the installer.
Someone who has never programmed in any language on any machine
but can use a web browser can get started with their
"Noob's Guide to Learning Java in 21 Days for Dummies Explained".
The only real challenge was "Do I want Java SE or OpenJDK?" which
required reading the part where it said Java SE is still free for
personal use.

The first and most obvious way to install Haskell on Windows ought to
be one that someone with no previous knowledge of Windows programming
can install just like other programming language kits.

On Mon, 27 Apr 2020 at 00:18, Gregory Guthrie <guthrie at miu.edu> wrote:
>
> Re: Windows installs
> Anthony Clayden <anthony_clayden at clear.net.nz> writes:
> > ...
> > Users who don't want to use Chocolatey are encouraged to use the usual
> > binary distributions [1], as in the past.
> > [1] https://downloads.haskell.org/ghc/8.10.1/
>
> Thanks; I didn't see any binary labelled Windows there.
>
> Dr. Gregory Guthrie
> Maharishi International University
> ----------------------------------------------------------------
> _______________________________________________
> 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 saurabhnanda at gmail.com  Tue Apr 28 05:16:35 2020
From: saurabhnanda at gmail.com (Saurabh Nanda)
Date: Tue, 28 Apr 2020 10:46:35 +0530
Subject: [Haskell-cafe] Questions: Using Hackage as a package maintainer?
Message-ID: <CAPz=2oGaJySpnkN9WC4yPw7RxgqW42=kQqzYWox9Q2LkMyWScw@mail.gmail.com>

Hi,

I seem to be struggling with Hackage [1], specifically package candidates.
Is this the right place to ask the following questions:

   - Does Hackage generate docs for package candidates? How long does it
   take. I have waited for 12+ hours and can't seem to find any docs.
   - If building docs fails, where is the error displayed? (especially for
   package candidates)
   - Do **warnings** affect this process? I see the following warning once
   I upload a package candidate:     'ghc-options: -main-is' is not portable.
   - Once I upload a package candidate, shouldn't it show-up on this page
   automatically - https://hackage.haskell.org/packages/candidates/ ? (my
   package is not showing-up here)
   - Is there a page which shows all the packages that have been uploaded
   by my Hackage user account?

[1]
https://stackoverflow.com/questions/61463139/does-hackage-generate-haddocks-for-package-candidates

-- Saurabh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200428/9031d5fe/attachment.html>

From fa-ml at ariis.it  Tue Apr 28 05:27:17 2020
From: fa-ml at ariis.it (Francesco Ariis)
Date: Tue, 28 Apr 2020 07:27:17 +0200
Subject: [Haskell-cafe] Questions: Using Hackage as a package maintainer?
In-Reply-To: <CAPz=2oGaJySpnkN9WC4yPw7RxgqW42=kQqzYWox9Q2LkMyWScw@mail.gmail.com>
References: <CAPz=2oGaJySpnkN9WC4yPw7RxgqW42=kQqzYWox9Q2LkMyWScw@mail.gmail.com>
Message-ID: <20200428052717.GA6033@extensa>

Hello Saurabh,
    not sure about the other questions but:

On Tue, Apr 28, 2020 at 10:46:35AM +0530, Saurabh Nanda wrote:
>    - Is there a page which shows all the packages that have been uploaded
>    by my Hackage user account?

Yup, a substitute fffaa with your account handle

    https://hackage.haskell.org/user/fffaaa

From saurabhnanda at gmail.com  Tue Apr 28 06:04:33 2020
From: saurabhnanda at gmail.com (Saurabh Nanda)
Date: Tue, 28 Apr 2020 11:34:33 +0530
Subject: [Haskell-cafe] Questions: Using Hackage as a package maintainer?
In-Reply-To: <20200428052717.GA6033@extensa>
References: <CAPz=2oGaJySpnkN9WC4yPw7RxgqW42=kQqzYWox9Q2LkMyWScw@mail.gmail.com>
 <20200428052717.GA6033@extensa>
Message-ID: <CAPz=2oGosm0T+fThzXbtMxquU3RWrM-z+c0LCevi7TsQHdSHiA@mail.gmail.com>

>     https://hackage.haskell.org/user/fffaaa

Thanks, Francesco! Where in the Hackage UI did you find this link?





On Tue, Apr 28, 2020 at 10:58 AM Francesco Ariis <fa-ml at ariis.it> wrote:

> Hello Saurabh,
>     not sure about the other questions but:
>
> On Tue, Apr 28, 2020 at 10:46:35AM +0530, Saurabh Nanda wrote:
> >    - Is there a page which shows all the packages that have been uploaded
> >    by my Hackage user account?
>
> Yup, a substitute fffaa with your account handle
>
>     https://hackage.haskell.org/user/fffaaa
> _______________________________________________
> 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.



-- 
http://www.saurabhnanda.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200428/aa5f50bd/attachment.html>

From fa-ml at ariis.it  Tue Apr 28 06:12:42 2020
From: fa-ml at ariis.it (Francesco Ariis)
Date: Tue, 28 Apr 2020 08:12:42 +0200
Subject: [Haskell-cafe] Questions: Using Hackage as a package maintainer?
In-Reply-To: <CAPz=2oGosm0T+fThzXbtMxquU3RWrM-z+c0LCevi7TsQHdSHiA@mail.gmail.com>
References: <CAPz=2oGaJySpnkN9WC4yPw7RxgqW42=kQqzYWox9Q2LkMyWScw@mail.gmail.com>
 <20200428052717.GA6033@extensa>
 <CAPz=2oGosm0T+fThzXbtMxquU3RWrM-z+c0LCevi7TsQHdSHiA@mail.gmail.com>
Message-ID: <20200428061242.GA29124@extensa>

On Tue, Apr 28, 2020 at 11:34:33AM +0530, Saurabh Nanda wrote:
> >     https://hackage.haskell.org/user/fffaaa
> 
> Thanks, Francesco! Where in the Hackage UI did you find this link?

In every package page there is an «Uploaded by» section with an
(almost always) clickable nick.

From lemming at henning-thielemann.de  Tue Apr 28 06:21:35 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 28 Apr 2020 08:21:35 +0200 (CEST)
Subject: [Haskell-cafe] Questions: Using Hackage as a package maintainer?
In-Reply-To: <CAPz=2oGaJySpnkN9WC4yPw7RxgqW42=kQqzYWox9Q2LkMyWScw@mail.gmail.com>
References: <CAPz=2oGaJySpnkN9WC4yPw7RxgqW42=kQqzYWox9Q2LkMyWScw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2004280813400.4586@sputnik>


On Tue, 28 Apr 2020, Saurabh Nanda wrote:

> I seem to be struggling with Hackage [1], specifically package candidates. Is this the right place to ask the
> following questions:
>  *  Does Hackage generate docs for package candidates? How long does it take. I have waited for 12+ hours and
>     can't seem to find any docs.

Don't know. At least you can upload package documentation candidates with
   cabal upload --documentation dist/yourpkg-3.1.4-docs.tar.gz

>  *  If building docs fails, where is the error displayed? (especially for package candidates)
>  *  Do **warnings** affect this process? I see the following warning once I upload a package candidate:    
>     'ghc-options: -main-is' is not portable.

Warnings do not block release.

However, "ghc-options: -main-is" should be replaced by the Cabal field 
"Main-Is:"

>  *  Once I upload a package candidate, shouldn't it show-up on this page automatically -
>     https://hackage.haskell.org/packages/candidates/ ? (my package is not showing-up here)

I thought so, but Hackage seems to limit the list to some of the first 
hits.

The candidate would have the URL:
    https://hackage.haskell.org/package/yourpkg-3.1.4/candidate

But Hackage shows this URL if you have successfully uploaded a candidate.

From ben.franksen at online.de  Tue Apr 28 07:23:17 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Tue, 28 Apr 2020 09:23:17 +0200
Subject: [Haskell-cafe] Problem with publishing project/packages
In-Reply-To: <alpine.DEB.2.20.2004272338490.4160@sputnik>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik>
Message-ID: <r88ll5$38m0$1@ciao.gmane.io>

Am 27.04.20 um 23:43 schrieb Henning Thielemann:
>> So my next thought is: "Let's just put it on Stackage, because the
>> best days of Hackage seem to be over...". However, I cannot do that,
>> because my project needs to compile on Hackage in order to be put on
>> Stackage...
> 
> You only need to _release_ your package on Hackage, it is not required
> that the Hackage server can build it. Stackage builds packages on its own.
> 
> If Hackage fails to build your documentation, you can create it yourself
> and upload it manually:
> 
> $ cabal haddock --for-hackage --hyperlink-source
> $ cabal upload --documentation --publish dist/pkg-0.1-docs.tar.gz

Thanks Henning, this was helpful for me as well. I just uploaded the
docs for darcs-2.14.3 using your recipe.

Note however that for newer cabal-install versions the option names have
changed to --haddock-for-hackage and --haddock-hyperlink-source.

Cheers
Ben


From dominik.schrempf at gmail.com  Tue Apr 28 10:57:20 2020
From: dominik.schrempf at gmail.com (Dominik Schrempf)
Date: Tue, 28 Apr 2020 12:57:20 +0200
Subject: [Haskell-cafe] Problem with publishing project/packages
In-Reply-To: <r88ll5$38m0$1@ciao.gmane.io>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
Message-ID: <87lfmf6fov.fsf@gmail.com>

Thank you, I also didn't know that a package release is enough to be added to
Stackage. I was also not aware of the cabal commands creating the documentation
for Hackage.

Nevertheless, I believe that we should improve on developer-friendliness. In the
end, we --- the developers and users --- create and maintain the libraries and
the ecosystem, and we depend on a healthy Haskell ecosystem.

Dominik

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

> Am 27.04.20 um 23:43 schrieb Henning Thielemann:
>>> So my next thought is: "Let's just put it on Stackage, because the
>>> best days of Hackage seem to be over...". However, I cannot do that,
>>> because my project needs to compile on Hackage in order to be put on
>>> Stackage...
>> 
>> You only need to _release_ your package on Hackage, it is not required
>> that the Hackage server can build it. Stackage builds packages on its own.
>> 
>> If Hackage fails to build your documentation, you can create it yourself
>> and upload it manually:
>> 
>> $ cabal haddock --for-hackage --hyperlink-source
>> $ cabal upload --documentation --publish dist/pkg-0.1-docs.tar.gz
>
> Thanks Henning, this was helpful for me as well. I just uploaded the
> docs for darcs-2.14.3 using your recipe.
>
> Note however that for newer cabal-install versions the option names have
> changed to --haddock-for-hackage and --haddock-hyperlink-source.
>
> 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.


From dominik.schrempf at gmail.com  Tue Apr 28 11:17:12 2020
From: dominik.schrempf at gmail.com (Dominik Schrempf)
Date: Tue, 28 Apr 2020 13:17:12 +0200
Subject: [Haskell-cafe] Problem with publishing project/packages
In-Reply-To: <87lfmf6fov.fsf@gmail.com>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com>
Message-ID: <87imhj6err.fsf@gmail.com>

By the way, I just failed building the documentation. This is all wrong :|.

    Resolving dependencies...
    Build profile: -w ghc-8.8.3 -O1
    In order, the following will be built (use -v for more details):
     - matrices-0.5.0 (lib) (requires build)
     - storable-complex-0.2.3.0 (lib:storable-complex) (requires build)
     - hmatrix-0.20.0.0 (lib) (requires build)
     - elynx-tools-0.2.2 (lib) (first run)
    Starting     storable-complex-0.2.3.0 (all, legacy fallback)
    Starting     matrices-0.5.0 (lib)
    Building     storable-complex-0.2.3.0 (all, legacy fallback)
    Building     matrices-0.5.0 (lib)

    Failed to build matrices-0.5.0.
    Build log (
    /home/dominik/.cabal/logs/ghc-8.8.3/matrices-0.5.0-fad3378ef6f4b9b628fbbd797b7c85b4d66179cdfbce76fdac9c0e095f6cd439.log
    ):
    Configuring library for matrices-0.5.0..
    Preprocessing library for matrices-0.5.0..
    Building library for matrices-0.5.0..
    [ 1 of 13] Compiling Data.Matrix.Class.Mutable ( src/Data/Matrix/Class/Mutable.hs, dist/build/Data/Matrix/Class/Mutable.o )

    src/Data/Matrix/Class/Mutable.hs:10:1: error:
        Could not find module ‘Control.Monad.Primitive’
        There are files missing in the ‘primitive-0.7.0.1’ package,
        try running 'ghc-pkg check'.
        Use -v (or `:set -v` in ghci) to see a list of the files searched for.
       |
    10 | import           Control.Monad.Primitive     (PrimMonad, PrimState)
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    src/Data/Matrix/Class/Mutable.hs:11:1: error:
        Could not find module ‘Data.Vector.Generic.Mutable’
        There are files missing in the ‘vector-0.12.1.2’ package,
        try running 'ghc-pkg check'.
        Use -v (or `:set -v` in ghci) to see a list of the files searched for.
       |
    11 | import qualified Data.Vector.Generic.Mutable as GM
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Dominik Schrempf <dominik.schrempf at gmail.com> writes:

> Thank you, I also didn't know that a package release is enough to be added to
> Stackage. I was also not aware of the cabal commands creating the documentation
> for Hackage.
>
> Nevertheless, I believe that we should improve on developer-friendliness. In the
> end, we --- the developers and users --- create and maintain the libraries and
> the ecosystem, and we depend on a healthy Haskell ecosystem.
>
> Dominik
>
> Ben Franksen <ben.franksen at online.de> writes:
>
>> Am 27.04.20 um 23:43 schrieb Henning Thielemann:
>>>> So my next thought is: "Let's just put it on Stackage, because the
>>>> best days of Hackage seem to be over...". However, I cannot do that,
>>>> because my project needs to compile on Hackage in order to be put on
>>>> Stackage...
>>> 
>>> You only need to _release_ your package on Hackage, it is not required
>>> that the Hackage server can build it. Stackage builds packages on its own.
>>> 
>>> If Hackage fails to build your documentation, you can create it yourself
>>> and upload it manually:
>>> 
>>> $ cabal haddock --for-hackage --hyperlink-source
>>> $ cabal upload --documentation --publish dist/pkg-0.1-docs.tar.gz
>>
>> Thanks Henning, this was helpful for me as well. I just uploaded the
>> docs for darcs-2.14.3 using your recipe.
>>
>> Note however that for newer cabal-install versions the option names have
>> changed to --haddock-for-hackage and --haddock-hyperlink-source.
>>
>> 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.


From ben.franksen at online.de  Tue Apr 28 11:57:59 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Tue, 28 Apr 2020 13:57:59 +0200
Subject: [Haskell-cafe] Problem with publishing project/packages
In-Reply-To: <87imhj6err.fsf@gmail.com>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com> <87imhj6err.fsf@gmail.com>
Message-ID: <r895o7$9j6$1@ciao.gmane.io>

Am 28.04.20 um 13:17 schrieb Dominik Schrempf:
> By the way, I just failed building the documentation. This is all wrong :|.
> 
>     src/Data/Matrix/Class/Mutable.hs:10:1: error:
>         Could not find module ‘Control.Monad.Primitive’
>         There are files missing in the ‘primitive-0.7.0.1’ package,
>         try running 'ghc-pkg check'.
>         Use -v (or `:set -v` in ghci) to see a list of the files searched for.
>        |
>     10 | import           Control.Monad.Primitive     (PrimMonad, PrimState)
>        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yes, this is either 'cabal haddock' or just 'haddock' doing a front-end
compile phase, give or take. This can be extremely annoying when all you
want to have are the docs.

But it's strange that you can cabal build but not cabal haddock if you
get such errors.

Which cabal-install version is this?

I agree that in general there are some things that could go smoother. I
think part of the problem is that the addition of the backpack support
has made cabal even more complicated than it already was, while at the
same time the newstyle commands were implemented. Both are extremely
valuable features but maintaining such a monster must be hard. I am not
involved in cabal development at all and know almost nothing about its
internal workings, but perhaps things could be improved by making it a
bit more modular; i.e. strive for the traditional Unix approach of "do
one thing and do it well". Probably easier said then done, though.

Today I ran again into a problem I had several times before: compiling
Cabal-3.2.* (the library) with ghc-8.2.2 and cabal with default options
(including jobs: $ncpu, though it actually used only one cpu) eats all
the memory on my machine (8GB, but I had a tor browser and another
browser and thunderbird running) so that it completely freezes (no
mouse, no keyboard). Had to reboot using sysrq escape hatch. Not funny.
I think this is due to use of ghc --make and some very large modules.
Thankfully memory use has improved with later ghc versions.

Cheers
Ben


From lemming at henning-thielemann.de  Tue Apr 28 12:04:11 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 28 Apr 2020 14:04:11 +0200 (CEST)
Subject: [Haskell-cafe] Problem with publishing project/packages
In-Reply-To: <87imhj6err.fsf@gmail.com>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com> <87imhj6err.fsf@gmail.com>
Message-ID: <alpine.DEB.2.20.2004281357070.4586@sputnik>


On Tue, 28 Apr 2020, Dominik Schrempf wrote:

> By the way, I just failed building the documentation. This is all wrong :|.
>
>    Resolving dependencies...
>    Build profile: -w ghc-8.8.3 -O1
>    In order, the following will be built (use -v for more details):
>     - matrices-0.5.0 (lib) (requires build)
>     - storable-complex-0.2.3.0 (lib:storable-complex) (requires build)
>     - hmatrix-0.20.0.0 (lib) (requires build)
>     - elynx-tools-0.2.2 (lib) (first run)
>    Starting     storable-complex-0.2.3.0 (all, legacy fallback)
>    Starting     matrices-0.5.0 (lib)
>    Building     storable-complex-0.2.3.0 (all, legacy fallback)
>    Building     matrices-0.5.0 (lib)
>
>    Failed to build matrices-0.5.0.
>    Build log (
>    /home/dominik/.cabal/logs/ghc-8.8.3/matrices-0.5.0-fad3378ef6f4b9b628fbbd797b7c85b4d66179cdfbce76fdac9c0e095f6cd439.log
>    ):
>    Configuring library for matrices-0.5.0..
>    Preprocessing library for matrices-0.5.0..
>    Building library for matrices-0.5.0..
>    [ 1 of 13] Compiling Data.Matrix.Class.Mutable ( src/Data/Matrix/Class/Mutable.hs, dist/build/Data/Matrix/Class/Mutable.o )
>
>    src/Data/Matrix/Class/Mutable.hs:10:1: error:
>        Could not find module ‘Control.Monad.Primitive’
>        There are files missing in the ‘primitive-0.7.0.1’ package,
>        try running 'ghc-pkg check'.
>        Use -v (or `:set -v` in ghci) to see a list of the files searched for.
>       |
>    10 | import           Control.Monad.Primitive     (PrimMonad, PrimState)
>       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>


What cabal-install version did you use for this build and what 'build' 
method did you use, v1-build or v2-build?

The message could mean that you are building with profiling but some 
'primitive' was installed without profiling. With 'cabal v2-build' 
(new-build) there should not be a problem, because Cabal should simply 
build profiling objects when needed. However, for building the 
documentation you do not need profiling. But then again, profiling was 
just a guess.

It's best you show us your actual command-line and used Cabal version and 
the package (e.g. repository) that you try to upload.

From lemming at henning-thielemann.de  Tue Apr 28 12:12:18 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 28 Apr 2020 14:12:18 +0200 (CEST)
Subject: [Haskell-cafe] exceeding resources with GHC compiling (Was: Problem
 with publishing project/packages)
In-Reply-To: <r895o7$9j6$1@ciao.gmane.io>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com> <87imhj6err.fsf@gmail.com>
 <r895o7$9j6$1@ciao.gmane.io>
Message-ID: <alpine.DEB.2.20.2004281405240.4586@sputnik>


On Tue, 28 Apr 2020, Ben Franksen wrote:

> Today I ran again into a problem I had several times before: compiling
> Cabal-3.2.* (the library) with ghc-8.2.2 and cabal with default options
> (including jobs: $ncpu, though it actually used only one cpu) eats all
> the memory on my machine (8GB, but I had a tor browser and another
> browser and thunderbird running) so that it completely freezes (no
> mouse, no keyboard). Had to reboot using sysrq escape hatch. Not funny.
> I think this is due to use of ghc --make and some very large modules.
> Thankfully memory use has improved with later ghc versions.

That's why I never use 'jobs: $ncpu' and also oppose to use this as the 
default setting. [1] There are some modules in packages that frequently 
eat up all my resources, e.g. I know that building "Cabal the library" is 
such a package. I remember that I can save memory by aborting compilation 
and restart it. It seems that GHC may cache too much. But continuing an 
aborted compilation is not possible for imported packages when using 
'cabal install'. Other packages contain big modules automatically created 
by Template Haskell.



[1] https://github.com/haskell/cabal/issues/5776

From olf at aatal-apotheke.de  Tue Apr 28 12:14:57 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Tue, 28 Apr 2020 14:14:57 +0200
Subject: [Haskell-cafe] Problem with publishing project/packages
Message-ID: <3f88a44969163b886ba2c816b0b2c4e49693ac2c.camel@aatal-apotheke.de>

> $ cabal haddock --for-hackage --hyperlink-source
> $ cabal upload --documentation --publish dist/pkg-0.1-docs.tar.gz

I also have projects where the normal build is fine but `stack haddock`
fails on some dependency. I resorted to
`stack haddock --no-haddock-deps`
and at least obtained documentation for _my_ package, but with
missing/broken links to the dependencies. 

Olaf


From ben.franksen at online.de  Tue Apr 28 12:25:12 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Tue, 28 Apr 2020 14:25:12 +0200
Subject: [Haskell-cafe] exceeding resources with GHC compiling
In-Reply-To: <alpine.DEB.2.20.2004281405240.4586@sputnik>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com> <87imhj6err.fsf@gmail.com>
 <r895o7$9j6$1@ciao.gmane.io> <alpine.DEB.2.20.2004281405240.4586@sputnik>
Message-ID: <r897b8$3viu$1@ciao.gmane.io>

Am 28.04.20 um 14:12 schrieb Henning Thielemann:
>> Today I ran again into a problem I had several times before: compiling
>> Cabal-3.2.* (the library) with ghc-8.2.2 and cabal with default options
>> (including jobs: $ncpu, though it actually used only one cpu) eats all
>> the memory on my machine (8GB, but I had a tor browser and another
>> browser and thunderbird running) so that it completely freezes (no
>> mouse, no keyboard). Had to reboot using sysrq escape hatch. Not funny.
>> I think this is due to use of ghc --make and some very large modules.
>> Thankfully memory use has improved with later ghc versions.
> 
> That's why I never use 'jobs: $ncpu' and also oppose to use this as the
> default setting.

Yeah, right. On the other hand, I had a job running that compiles and
runs all the tests for darcs for 5 different ghc versions. You want all
the cores to run at max in this case to get results before sunset!
(Darcs itself is not a small project and takes quite a while to compile
with optimizations. I also I did not expect cabal-3.2 to be re-built for
ghc-8.2, that was a mistake I made in the cabal file; if I had I would
have closely monitored memory use to be ready to kill it).

> [1] There are some modules in packages that frequently
> eat up all my resources, e.g. I know that building "Cabal the library"
> is such a package. I remember that I can save memory by aborting
> compilation and restart it. It seems that GHC may cache too much. But
> continuing an aborted compilation is not possible for imported packages
> when using 'cabal install'. Other packages contain big modules
> automatically created by Template Haskell.

Yes. In the past I also had difficulty with vector and with aeson.

Cheers
Ben


From lemming at henning-thielemann.de  Tue Apr 28 12:31:03 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 28 Apr 2020 14:31:03 +0200 (CEST)
Subject: [Haskell-cafe] exceeding resources with GHC compiling
In-Reply-To: <r897b8$3viu$1@ciao.gmane.io>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com> <87imhj6err.fsf@gmail.com>
 <r895o7$9j6$1@ciao.gmane.io> <alpine.DEB.2.20.2004281405240.4586@sputnik>
 <r897b8$3viu$1@ciao.gmane.io>
Message-ID: <alpine.DEB.2.20.2004281430300.4586@sputnik>


On Tue, 28 Apr 2020, Ben Franksen wrote:

> Am 28.04.20 um 14:12 schrieb Henning Thielemann:
>
>> [1] There are some modules in packages that frequently
>> eat up all my resources, e.g. I know that building "Cabal the library"
>> is such a package. I remember that I can save memory by aborting
>> compilation and restart it. It seems that GHC may cache too much. But
>> continuing an aborted compilation is not possible for imported packages
>> when using 'cabal install'. Other packages contain big modules
>> automatically created by Template Haskell.
>
> Yes. In the past I also had difficulty with vector and with aeson.

I remember those, too.

From fa-ml at ariis.it  Tue Apr 28 12:39:26 2020
From: fa-ml at ariis.it (Francesco Ariis)
Date: Tue, 28 Apr 2020 14:39:26 +0200
Subject: [Haskell-cafe] exceeding resources with GHC compiling
In-Reply-To: <alpine.DEB.2.20.2004281430300.4586@sputnik>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik>
 <r88ll5$38m0$1@ciao.gmane.io> <87lfmf6fov.fsf@gmail.com>
 <87imhj6err.fsf@gmail.com> <r895o7$9j6$1@ciao.gmane.io>
 <alpine.DEB.2.20.2004281405240.4586@sputnik>
 <r897b8$3viu$1@ciao.gmane.io>
 <alpine.DEB.2.20.2004281430300.4586@sputnik>
Message-ID: <20200428123926.GA24058@extensa>

On Tue, Apr 28, 2020 at 02:31:03PM +0200, Henning Thielemann wrote:
> > Yes. In the past I also had difficulty with vector and with aeson.
> 
> I remember those, too.

One word: pandoc.

From ivanperezdominguez at gmail.com  Tue Apr 28 12:38:45 2020
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Tue, 28 Apr 2020 08:38:45 -0400
Subject: [Haskell-cafe] exceeding resources with GHC compiling (Was:
 Problem with publishing project/packages)
In-Reply-To: <alpine.DEB.2.20.2004281405240.4586@sputnik>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik>
 <r88ll5$38m0$1@ciao.gmane.io> <87lfmf6fov.fsf@gmail.com>
 <87imhj6err.fsf@gmail.com>
 <r895o7$9j6$1@ciao.gmane.io> <alpine.DEB.2.20.2004281405240.4586@sputnik>
Message-ID: <CACZKWEK5w7FeK3=pD-ZLbotG_nxW48Cs5dei_dHuVHJ_4XKsWw@mail.gmail.com>

On Tue, 28 Apr 2020 at 08:13, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Tue, 28 Apr 2020, Ben Franksen wrote:
>
> > I remember that I can save memory by aborting compilation
> and restart it. It seems that GHC may cache too much.


I've also experienced this multiple times (e.g., with Qt, which is huge,
and with yesod apps).

Could this also be indicative of a leak?

I sometimes wonder if the developers behind some libraries operate with
resources that are far beyond what any of us have or can afford.

Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200428/692dd192/attachment.html>

From jo at durchholz.org  Tue Apr 28 12:59:33 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 28 Apr 2020 14:59:33 +0200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
 onWindows?
In-Reply-To: <r87509$1fre$1@ciao.gmane.io>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 <b157c61c-f654-f8bd-75c1-514bc5ca1a09@durchholz.org>
 <r86dnu$2kon$1@ciao.gmane.io>
 <8f0bbda7-0e0a-45a7-2f6c-ab0225db0075@durchholz.org>
 <r87509$1fre$1@ciao.gmane.io>
Message-ID: <7b904337-b16c-bf49-44d6-03eb573ce7ce@durchholz.org>

Am 27.04.20 um 19:32 schrieb Ben Franksen:
> Am 27.04.20 um 17:34 schrieb Joachim Durchholz:
>> Am 27.04.20 um 12:55 schrieb Ben Franksen:
>>> This very much differs from how I view the /result/ of the work: here I
>>> regard everything that has not been done in a clean and orderly fashion
>>> as deficient. (And that goes for software, too, especially if it is
>>> mature.)
>>
>> Sure, but how do you judge that work if you're not an expert?
>> With old-style cars, you could inspect the machinery, even if you
>> weren't fully educated you could see if there was grime in the gears or
>> not. With today's cars and their electronics, and today's
>> millions-of-lines software, that kind of check has become impossible.
> 
> Which is why I dislike modern cars. If I ever happen to buy another one
> in my lifetime it will be an oldtimer.

And that's the rub: you won't get a silent, safer, low-emission car, 
you'll be stuck with louder, unsafe, high-emission choices.
And building and maintaining a car that has all of these things and 
still isn't beyond the pay grade of most people is simply beyond what a 
grubby mechanic could do, or a layman could understand. Too complicated, 
too complex.

I agree that much of the non-repairability modern cars is just lock-in, 
not by necessity.
That's where the analogy breaks down: some things in software are too 
complicated for the casual user by necessity.
Though... it's not that much of a break-down actually: Some OS vendors 
are indeed known for their persistent attempts to lock their users in, 
and making stuff needlessly complicated to that end.

From ben.franksen at online.de  Tue Apr 28 13:23:34 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Tue, 28 Apr 2020 15:23:34 +0200
Subject: [Haskell-cafe] Off-topic: complexity of technology [was: When did
 it become so hard to install Haskell onWindows?]
In-Reply-To: <7b904337-b16c-bf49-44d6-03eb573ce7ce@durchholz.org>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com>
 <5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com>
 <b157c61c-f654-f8bd-75c1-514bc5ca1a09@durchholz.org>
 <r86dnu$2kon$1@ciao.gmane.io>
 <8f0bbda7-0e0a-45a7-2f6c-ab0225db0075@durchholz.org>
 <r87509$1fre$1@ciao.gmane.io>
 <7b904337-b16c-bf49-44d6-03eb573ce7ce@durchholz.org>
Message-ID: <r89aon$3uct$1@ciao.gmane.io>

Am 28.04.20 um 14:59 schrieb Joachim Durchholz:
> Am 27.04.20 um 19:32 schrieb Ben Franksen:
>> Am 27.04.20 um 17:34 schrieb Joachim Durchholz:
>>> Am 27.04.20 um 12:55 schrieb Ben Franksen:
>>>> This very much differs from how I view the /result/ of the work: here I
>>>> regard everything that has not been done in a clean and orderly fashion
>>>> as deficient. (And that goes for software, too, especially if it is
>>>> mature.)
>>>
>>> Sure, but how do you judge that work if you're not an expert?
>>> With old-style cars, you could inspect the machinery, even if you
>>> weren't fully educated you could see if there was grime in the gears or
>>> not. With today's cars and their electronics, and today's
>>> millions-of-lines software, that kind of check has become impossible.
>>
>> Which is why I dislike modern cars. If I ever happen to buy another one
>> in my lifetime it will be an oldtimer.
> 
> And that's the rub: you won't get a silent, safer, low-emission car,

More silent: Okay, I'll give you that one.

Safer: Physically, yes. OTOH, the manufacturer will constantly spy on
you and some evil hacker may remotely control your car & crash it. Just
like your "smart home" devices & the "smart health" devices. No, thank you.

Low-emission: Ever heard of the rebound effect? Modern cars could indeed
have much lower emission if that wasn't over-compensated by featurism
and added weight. Production side must also be taken into account, but I
have no numbers for that.

After all, what I miss mostly is being in control of the machine,
instead of the machine (or its vendor) controlling me. This also readily
translates to (pure) software / operating systems. Call me
old-fashioned, if you will.

> I agree that much of the non-repairability modern cars is just lock-in,
> not by necessity.
> That's where the analogy breaks down: some things in software are too
> complicated for the casual user by necessity.
> Though... it's not that much of a break-down actually: Some OS vendors
> are indeed known for their persistent attempts to lock their users in,
> and making stuff needlessly complicated to that end.

Yeah, first Microsoft/Windows, now quite similarly IBM/systemd.

Cheers
Ben


From dominik.schrempf at gmail.com  Tue Apr 28 13:38:19 2020
From: dominik.schrempf at gmail.com (Dominik Schrempf)
Date: Tue, 28 Apr 2020 15:38:19 +0200
Subject: [Haskell-cafe] Problem with publishing project/packages
In-Reply-To: <alpine.DEB.2.20.2004281357070.4586@sputnik>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com> <87imhj6err.fsf@gmail.com>
 <alpine.DEB.2.20.2004281357070.4586@sputnik>
Message-ID: <874kt3rar8.fsf@gmail.com>

Maybe I should have been more specific. I can compile the package with `stack
build`, but never built with cabal directly.

My cabal versions are:
    + cabal --version
    cabal-install version 3.0.0.0
    compiled using version 3.0.1.0 of the Cabal library

The command I use is
    cabal build
or
    cabal haddock --haddock-for-hackage --haddock-hyperlink-source

v2-build and new-build fail with the error I posted below.

v1-build fails with 
    Resolving dependencies...
    Warning: solver failed to find a solution:
    Could not resolve dependencies:
    [__0] trying: elynx-tools-0.2.2 (user goal)
    [__1] unknown package: matrices (dependency of elynx-tools)
    [__1] fail (backjumping, conflict set: elynx-tools, matrices)
    After searching the rest of the dependency tree exhaustively, these were the
    goals I've had most trouble fulfilling: elynx-tools, matrices
    Trying configure anyway.
    Configuring elynx-tools-0.2.2...
    cabal: Encountered missing or private dependencies:
    hmatrix -any, matrices -any

The package I try to compile can be found here:
https://github.com/dschrempf/elynx/tree/master/elynx-tools

Thank you for your help!
Dominik

Henning Thielemann <lemming at henning-thielemann.de> writes:

> On Tue, 28 Apr 2020, Dominik Schrempf wrote:
>
>> By the way, I just failed building the documentation. This is all wrong :|.
>>
>>    Resolving dependencies...
>>    Build profile: -w ghc-8.8.3 -O1
>>    In order, the following will be built (use -v for more details):
>>     - matrices-0.5.0 (lib) (requires build)
>>     - storable-complex-0.2.3.0 (lib:storable-complex) (requires build)
>>     - hmatrix-0.20.0.0 (lib) (requires build)
>>     - elynx-tools-0.2.2 (lib) (first run)
>>    Starting     storable-complex-0.2.3.0 (all, legacy fallback)
>>    Starting     matrices-0.5.0 (lib)
>>    Building     storable-complex-0.2.3.0 (all, legacy fallback)
>>    Building     matrices-0.5.0 (lib)
>>
>>    Failed to build matrices-0.5.0.
>>    Build log (
>>    /home/dominik/.cabal/logs/ghc-8.8.3/matrices-0.5.0-fad3378ef6f4b9b628fbbd797b7c85b4d66179cdfbce76fdac9c0e095f6cd439.log
>>    ):
>>    Configuring library for matrices-0.5.0..
>>    Preprocessing library for matrices-0.5.0..
>>    Building library for matrices-0.5.0..
>>    [ 1 of 13] Compiling Data.Matrix.Class.Mutable ( src/Data/Matrix/Class/Mutable.hs, dist/build/Data/Matrix/Class/Mutable.o )
>>
>>    src/Data/Matrix/Class/Mutable.hs:10:1: error:
>>        Could not find module ‘Control.Monad.Primitive’
>>        There are files missing in the ‘primitive-0.7.0.1’ package,
>>        try running 'ghc-pkg check'.
>>        Use -v (or `:set -v` in ghci) to see a list of the files searched for.
>>       |
>>    10 | import           Control.Monad.Primitive     (PrimMonad, PrimState)
>>       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>
>
> What cabal-install version did you use for this build and what 'build' 
> method did you use, v1-build or v2-build?
>
> The message could mean that you are building with profiling but some 
> 'primitive' was installed without profiling. With 'cabal v2-build' 
> (new-build) there should not be a problem, because Cabal should simply 
> build profiling objects when needed. However, for building the 
> documentation you do not need profiling. But then again, profiling was 
> just a guess.
>
> It's best you show us your actual command-line and used Cabal version and 
> the package (e.g. repository) that you try to upload.


From donn at avvanta.com  Tue Apr 28 14:35:30 2020
From: donn at avvanta.com (Donn Cave)
Date: Tue, 28 Apr 2020 07:35:30 -0700 (PDT)
Subject: [Haskell-cafe] Off-topic: complexity of technology
In-Reply-To: <r89aon$3uct$1@ciao.gmane.io>
References: <CA+ZFbn_SMX-0eZq2JiX0YUmhnN+uqN=vabtotTrXiDEdy=Jdxg@mail.gmail.com><5ea3fbd7.1c69fb81.7c9a7.8870@mx.google.com><b157c61c-f654-f8bd-75c1-514bc5ca1a09@durchholz.org><r86dnu$2kon$1@ciao.gmane.io><8f0bbda7-0e0a-45a7-2f6c-ab0225db0075@durchholz.org><r87509$1fre$1@ciao.gmane.io><7b904337-b16c-bf49-44d6-03eb573ce7ce@durchholz.org><r89aon$3uct$1@ciao.gmane.io>
Message-ID: <20200428143530.7051B93C2E@mail.avvanta.com>

>> That's where the analogy breaks down: some things in software are too
>> complicated for the casual user by necessity.

My theory is that it's inherent in the species.  When you've become
something of an expert in some technology, you will start to prefer
increased complexity.  It's more mentally engaging, it cements your
lead in expertise and thus your security in your position, it's just
more of everything good.  Operating systems, programming languages,
anything that's by nature complex at all.  Few will seriously complain,
and never anyone who matters.

	Donn

From ben.franksen at online.de  Tue Apr 28 14:38:22 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Tue, 28 Apr 2020 16:38:22 +0200
Subject: [Haskell-cafe] Problem with publishing project/packages
In-Reply-To: <874kt3rar8.fsf@gmail.com>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com> <87imhj6err.fsf@gmail.com>
 <alpine.DEB.2.20.2004281357070.4586@sputnik> <874kt3rar8.fsf@gmail.com>
Message-ID: <r89f4u$2g3q$1@ciao.gmane.io>

Am 28.04.20 um 15:38 schrieb Dominik Schrempf:
> Maybe I should have been more specific. I can compile the package with `stack
> build`, but never built with cabal directly.
> 
> My cabal versions are:
>     + cabal --version
>     cabal-install version 3.0.0.0
>     compiled using version 3.0.1.0 of the Cabal library
> 
> The command I use is
>     cabal build
> or
>     cabal haddock --haddock-for-hackage --haddock-hyperlink-source
> 
> v2-build and new-build fail with the error I posted below.

By default cabal uses the ghc that it finds in your PATH. My guess is
that this is a different version than that in your stack setup, which
means cabal may select some older or newer dependencies as a result.

If you have the same ghc, you could look at the versions of the
libraries that cabal selects and that give you trouble. Compare them to
what your working stack setup uses and adapt the version bounds
accordingly in your cabal file. Or perhaps stack can be convinced to
write a cabal file that freezes the versions to exactly the set
supported by that setup?

Cheers
Ben


From lemming at henning-thielemann.de  Tue Apr 28 14:53:18 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 28 Apr 2020 16:53:18 +0200 (CEST)
Subject: [Haskell-cafe] exceeding resources with GHC compiling (Was:
 Problem with publishing project/packages)
In-Reply-To: <CACZKWEK5w7FeK3=pD-ZLbotG_nxW48Cs5dei_dHuVHJ_4XKsWw@mail.gmail.com>
References: <87wo60oh4s.fsf@gmail.com>
 <alpine.DEB.2.20.2004272338490.4160@sputnik> <r88ll5$38m0$1@ciao.gmane.io>
 <87lfmf6fov.fsf@gmail.com> <87imhj6err.fsf@gmail.com>
 <r895o7$9j6$1@ciao.gmane.io> <alpine.DEB.2.20.2004281405240.4586@sputnik>
 <CACZKWEK5w7FeK3=pD-ZLbotG_nxW48Cs5dei_dHuVHJ_4XKsWw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2004281651490.4586@sputnik>


On Tue, 28 Apr 2020, Ivan Perez wrote:

> On Tue, 28 Apr 2020 at 08:13, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>
>       On Tue, 28 Apr 2020, Ben Franksen wrote:
>
>       > I remember that I can save memory by aborting compilation
>       and restart it. It seems that GHC may cache too much.
> 
> 
> I've also experienced this multiple times (e.g., with Qt, which is huge, and with yesod apps).
> 
> Could this also be indicative of a leak?

sure

> I sometimes wonder if the developers behind some libraries operate with 
> resources that are far beyond what any of us have or can afford.

Not only that. Sometimes I want to compile a library on the Raspberry and 
I cannot add memory to that board.

From anthony_clayden at clear.net.nz  Wed Apr 29 05:58:04 2020
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Wed, 29 Apr 2020 17:58:04 +1200
Subject: [Haskell-cafe] Please repair Hugs-for-Windows download links
Message-ID: <CAM7nRYQuov1UsCJxk1PcZTRqzNzwNV0CvBSTWpo_fUUqVr7SZQ@mail.gmail.com>

Hi Vanessa, Thorkil,

Yes I'm afraid Hugs is unmaintained. If you look at that Hugs-Bugs thread,
Neil was kind enough to reply, but it seems everyone is locked out of
maintaining the site.

> Isn’t hugs unmaintained? Cool stuff but definitely vintage!

(Nearly) gone, but not forgotten. There's a few people over the years

have built from source, there's a few repos on github.


With a bit of time on my hands lately ...

I've built the wonderful WinHugs from source,

so that I can fix a long-standing bit of bogusness in GHC.

(GHC's behaviour is just not worth trying to make sense of.)

And ref the discussion of GHC's awkwardness wrt Windows,

WinHugs is just so nicely Windows-y, with a few-clicks install.


Persuading (Win)Hugs to compile wasn't plain sailing,

and there's a few of the libraries/packages have bitrotted beyond repair.

But it is sooooo worth it, compared to the ugly GHC experience;

plus you get a half-decent records system with Trex.

(I've just been adding field label puns to it, to catch up with GHC.)


AntC

>* On Apr 26, 2020, at 10:25 AM, Thorkil Naur via Haskell-Cafe <haskell-cafe at haskell.org <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote:
*> >* Dear Cafe,
*> >* Having recently had occasion to suggest the use of Hugs, I found that the
*>* links provided for WinHugs and MinHugs on
*> >*  https://www.haskell.org/hugs/pages/downloading.htm
<https://www.haskell.org/hugs/pages/downloading.htm>
*> >* are broken. In the discussion "When did it become so hard to install
*>* Haskell on Windows?"
*> >*  https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132129.html
<https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132129.html>
*> >* Anthony Clayden
*> >*  https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132155.html
<https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132155.html>
*> >* referred to
*> >*  https://mail.haskell.org/pipermail/hugs-bugs/2018-July/001914.html
<https://mail.haskell.org/pipermail/hugs-bugs/2018-July/001914.html>
*> >* which provides working links:
*> >*  https://www.haskell.org/hugs/downloads/2006-09/WinHugs-Sep2006.exe
<https://www.haskell.org/hugs/downloads/2006-09/WinHugs-Sep2006.exe>
*>*  https://www.haskell.org/hugs/downloads/2006-09/MinHugs-Sep2006.exe
<https://www.haskell.org/hugs/downloads/2006-09/MinHugs-Sep2006.exe>
*> >* If someone with suitable access repaired these links, I would be very
*>* grateful. I am an occasional user of both GHC and Hugs, and although GHC
*>* shines when it comes to efficiency, I also often appreciate the modest
*>* and simple Hugs.
*> >* Thanks very much in advance.
*> >* Best regards
*>* Thorkil
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200429/999f3f05/attachment.html>

From anthony_clayden at clear.net.nz  Wed Apr 29 06:09:07 2020
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Wed, 29 Apr 2020 18:09:07 +1200
Subject: [Haskell-cafe] Hugs sources WITH TESTS?
Message-ID: <CAM7nRYS3cpbX92pNDmke-=rpCAOqEYefoczehsCkaPEAVnU2uw@mail.gmail.com>

Hi Siddharth,

Hugs dates from a different age, when testing was something of an
afterthought.

I can suggest some places to look:

* The hugs-bugs mailing list is the only way to (possibly) contact the
original developers.

* There's a couple of repos on github: Franklin Chen, Chris Done.
   Franklin has also grabbed the 2009 developer snapshot.

But I suspect the answer is: there are no tests/never were.

AntC

> I got interested in hugs thanks to the surrounding discussion and went
spelunking in their codebase. Weirdly, I can't find a test suite!
- The November 2003 version
<https://github.com/bollu/hugs/blob/master/src/Makefile.in#L280> has a rule
in the makefile to cd ../tests . However, such a folder does not exist in
the source tree.
- the September 2006 version
<https://github.com/haskell-implementations/hugs/blob/master/src/Makefile.in>,
doesn't have a test / check rule at all.

I find this baffling. Where did the tests go?!

If you have access to them --- or if you the story behind where the tests
are, please do let me know!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200429/cfa2bdf6/attachment.html>

From anthony_clayden at clear.net.nz  Wed Apr 29 09:54:42 2020
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Wed, 29 Apr 2020 21:54:42 +1200
Subject: [Haskell-cafe] When did it become so hard to install Haskell
	onWindows?
Message-ID: <CAM7nRYSZeJFczmxKG3mTkpPzbqsR1VxQG=A8=yNWcqSNwrr-yQ@mail.gmail.com>

> I think the comments regarding users' proficiency with Chocolatey or PowerShell or whatever are beside the point. The truth is that *nobody* expects that anyone would need to be familiar with those tools in order to install software on Windows. As an example of what I'm talking about, consider Microsoft Visual Studio. This is a big, complex piece of software. And, obviously, it's an application that's used by software developers, rather than ordinary end users. During installation, it runs multiple PowerShell and Cmd scripts, and, for all I know, uses Chocolatey under the hood as well. The point is, I don't have to care about any of that. I install it the same way I install any other software in Windows: I click a few buttons and make a few checkbox selections, and it just runs*.

Indeed, my experience too. Furthermore MSVC/Visual Studio upgraded the
source distro 'Solution' for Hugs/WinHugs from 2006; and I could go
ahead and build that with less than a dozen patches to bitrotted code
and config. No sight of a command line needed. In comparison, building
the Unixy bits was a nightmare. (And I think little of that was
Windows-specific or mixed-platform specific.)

> I understand perfectly well the issue with resource constraints preventing the creation of a better experience for Windows users. ...

I don't understand. SLPJ is at *Microsoft*; his homepage is at
*Microsoft*; his email address is *@Microsoft*. It's ironic that half
of the threads Simon starts on ghc-devs relate to crashes/failed
builds on *Windows*.

And here we are (not for the first time) using up disproportionate
airspace on Windows.

I appreciate the sponsorship (in effect) the GHC community gets from
Microsoft. Could their help provide a little more practical benefit?:
there are surely Microsofters who know the tools and have the skills
to deliver a few-clicks installer for GHC(?)


> And I think it's safe to assume that Microsoft has a few more resources at its disposal to support this than the Haskell community does. So you just need to be honest about it, and state up front that there isn't a simple, seamless way to install the Haskell Platform in Windows at this time, but if you want to install it anyway, here's what you need to do.


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200429/43f6c83c/attachment.html>

From naur at post11.tele.dk  Wed Apr 29 18:44:51 2020
From: naur at post11.tele.dk (Thorkil Naur)
Date: Wed, 29 Apr 2020 20:44:51 +0200
Subject: [Haskell-cafe] Please repair Hugs-for-Windows download links
In-Reply-To: <CAM7nRYQuov1UsCJxk1PcZTRqzNzwNV0CvBSTWpo_fUUqVr7SZQ@mail.gmail.com>
References: <CAM7nRYQuov1UsCJxk1PcZTRqzNzwNV0CvBSTWpo_fUUqVr7SZQ@mail.gmail.com>
Message-ID: <20200429184450.GA417@Annette-Pc2>

On Wed, Apr 29, 2020 at 05:58:04PM +1200, Anthony Clayden wrote:
> ...
> On Sun, Apr 26, 2020 at 10:55:25AM -0500, Vanessa McHale wrote:
> > Isn’t hugs unmaintained? ...

Hm, what does "unmaintained" mean? Sure, long time (more than 10 years)
no updates. Nevertheless, there doesn't seem to be a large number of
requests for changes or corrections that are left without response. You
may say, there are no users, hence no problems. You may also say that
the users are simply quietly satisfied.

And there are a few users, as witnessed by Doug's

  https://mail.haskell.org/pipermail/hugs-users/2018-July/000902.html

and Anthony's

  https://mail.haskell.org/pipermail/hugs-users/2018-July/000900.html

a bit further along in the same thread.

When I started using Haskell in 2003, inspired by my use of Miranda in a
course some 10 years before that, haskell.org had a "Implementation"
button with Hugs, nhc, and GHC (of course) and perhaps more, Helium,
jhc, uhc, lhc come to mind, I am not sure. Even on top of just wishing
the Hugs links repaired, that list would also be high on my wish list.

To be sure, I would never recommend any unmaintained program, such that
Hugs very clearly labels itself on https://www.haskell.org/hugs (the
wording is "no longer in development"), for any "serious" use.
Nevertheless, it seems a waste not to maintain these references to
valuable material, whether for educational, historical or just
entertainment reasons. One valuable development, not particularly recent
but worth mentioning, is Andy Gill's hpc, Haskell Program Coverage, that
took place initially, as I understand, using nhc with Malcolm Wallace
guidance.

And Hugs installations are not entirely unavailable: Fedora Linux
presently has a working hugs98. And there is a FreeBSD hugs98 port, but
it didn't work for me. And, of course, the WinHugs installation proceeds
smoothly, recently tried on a Windows 10 machine, thanks Neil Mitchell.

I have used both Hugs and GHC extensively over the years and still do:
Recently to debug code to calculate ln() in double precision in an Algol
system for a 40/42-bit Danish computer, the GIER, from 1962:

  https://datamuseum.dk/wiki/GIER/GAIII_DPA_double_ln()_fejls%C3%B8gning

(In danish, I'm afraid, the english translate.google.com version is
fair.) So when the verdict is

> > ... Cool stuff but definitely vintage!

, I can only agree.

I have also tried other Haskell implementations, mainly for fun, but not
kept up their use, for various reasons.

> ...

Just re-stating my original wish for corrected Hugs links, whether
considered unmaintained or not.

Best
Thorkil

From manny at fpcomplete.com  Wed Apr 29 19:02:15 2020
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Wed, 29 Apr 2020 12:02:15 -0700
Subject: [Haskell-cafe] ANN: stack-2.3.1
Message-ID: <CACGj5vJeTpvkQFdf+Y0ptw=TKJEN_Jdu1AzmBFa5GJSZYduwgg@mail.gmail.com>

See https://haskellstack.org/ for installation and upgrade instructions.

Release notes:

   -

   We have reduced the number of platforms that we support with binary
   releases.
   The reason behind this is that we've been slowed down in our release
   process
   until now with issues trying to build binaries for less common
   platforms. In
   order to make sure we can address issues more quickly (like supporting
   new
   GHC versions), we're limiting support from the Stack team to:
   - Linux 64-bit (static)
      - macOS
      - Windows 64-bit

   If others want to provide additional binaries, we will definitely be
   happy
   for the support. But since our CI system is currently able to produce
   these
   three bindists only, that's what we will be providing with the next
   release.
   -

   Since we no longer have dynamically linked Linux binaries, we are
   removing
   removing the -static suffix from the static Linux binaries. If you have
   scripts to download the latest stable Linux binary, update them to use
   linux-x86_64 instead of linux-x86_64-static (if you are already using the
   former, nothing needs to change). For this release, both are supported,
   but
   the next release will no longer have the -static variant.
   -

   We are also deprecating the download links at https://stackage.org/stack.
   See this page for the current installation instructions:
   https://docs.haskellstack.org/en/stable/install_and_upgrade/.
   -

   These are the canonical locations to download the latest stable binaries
   from, and will continue to be supported going forward:
   - Linux 64-bit (static):
      https://get.haskellstack.org/stable/linux-x86_64.tar.gz
      - macOS: https://get.haskellstack.org/stable/osx-x86_64.tar.gz
      - Windows 64-bit:
      https://get.haskellstack.org/stable/windows-x86_64.zip

   As always, binaries for specific versions are available from the Github
   releases: https://github.com/commercialhaskell/stack/releases.

*Changes since v2.1.3.1*

Major changes:

   -

   setup-info-locations yaml configuration now allows overwriting the
   default locations of stack-setup-2.yaml.
   #5031 <https://github.com/commercialhaskell/stack/pull/5031>
   #2983 <https://github.com/commercialhaskell/stack/issues/2983>
   #2913 <https://github.com/commercialhaskell/stack/issues/2913>
   -

   The setup-info configuration key now allows overwriting parts of the
   default setup-info
   -

   The --setup-info-yaml command line flag now may be used in all stack
   commands such as stack build, and not only in stack setup
   -

   The --setup-info-yaml may specify multiple locations for stack-setup.yaml
   files.
   -

   The stack upload can read first reads environment Variable
   $HACKAGE_USERNAME and $HACKAGE_PASSWORD if they are missing only then
   asks for username or password
   -

   Fully remove GHCJS support.
   -

   Remove the freeze command. It has been replaced by lock files.

Behavior changes:

   -

   Remove the deprecated --stack-setup-yaml command line argument in favor
   of --setup-info-yaml
   #2647 <https://github.com/commercialhaskell/stack/issues/2647>
   -

   We now recommend checking in generated cabal files for repos. When
   generating lock files for
   extra-deps that only include package.yaml files, a deprecation warning
   will be generated.
   Also, those packages will no longer be included in the generated lock
   files.
   See #5210 <https://github.com/commercialhaskell/stack/issues/5210>.

Other enhancements:

   -

   Add build-output-timestamps flag in yaml. Setting it to true
   prefixes each build log output line with a timestamp.
   -

   Show warning about local-programs-path with spaces on windows
   when running scripts. See
   #5013 <https://github.com/commercialhaskell/stack/pull/5013>
   -

   Add ls dependencies json which will print dependencies as JSON.
   ls dependencies --tree is now ls dependencies tree. See
   #4424 <https://github.com/commercialhaskell/stack/pull/4424>
   -

   Remove warning for using Stack with GHC 8.8-8.10, and Cabal 3.0-3.2.
   -

   Allow relative paths in --setup-info-yaml and tool paths
   #3394 <https://github.com/commercialhaskell/stack/issues/3394>
   -

   Added the --only-locals flag. See
   #5272 <https://github.com/commercialhaskell/stack/issues/5272>

Bug fixes:

   -

   Upgrade pantry: module mapping insertions into the database are now
   atomic.
   Previously, if you SIGTERMed at the wrong time while running a script,
   you
   could end up with an inconsistent database state.
   -

   --resolver global doesn't retrieve snapshots list from the internet
   beause doesn't need it. See #5103
   <https://github.com/commercialhaskell/stack/issues/5103>
   -

   Fix using relative links in haddocks output. See
   #4971 <https://github.com/commercialhaskell/stack/issues/4971>.
   -

   Do not include generated cabal file information in lock files. See
   #5045 <https://github.com/commercialhaskell/stack/issues/5045>.
   -

   Use proper Hoogle executable path when installed automatically. See
   #4905 <https://github.com/commercialhaskell/stack/issues/4905>
   -

   Fix GHC version for batched package unregistration. See
   #4951 <https://github.com/commercialhaskell/stack/issues/4951>
   -

   Use Hoogle from the snapshot used and not the latest version. See
   #4905 <https://github.com/commercialhaskell/stack/issues/4905>
   -

   Resolve "'stty' is not recognized". See
   #4901 <https://github.com/commercialhaskell/stack/issues/4901>
   -

   Fix missing reconfigure check causing errors when a package gets
   used in multiple projects. See
   #5147 <https://github.com/commercialhaskell/stack/issues/5147>

*Thanks to all our contributors for this release:*

   - Adam McCullough
   - Akshay Mankar
   - Brian Wignall
   - Cheah Jer Fei
   - Chris Done
   - David Baynard
   - davit nalchevanidze
   - Dino Morelli
   - Emanuel Borsboom
   - Felix Yan
   - flip111
   - Flowers Safety
   - Fred Miller
   - Fyrbll
   - gdziadkiewicz
   - Good boy
   - Hypnoes.Liu
   - Iisus
   - Iustin Pop
   - ivanbakel
   - Javier Neira
   - Jeff Happily
   - jeffhappily
   - jneira
   - Justin Le
   - Kirill Zaborsky
   - Leif Metcalf
   - Leonhard Markert
   - Lokesh Mohanty
   - Matt Audesse
   - Michael Snoyman
   - Mihai Maruseac
   - NightRa
   - Phil Ruffwind
   - qinzhenlong
   - Robert Hensing
   - Sasha Bogicevic
   - Sibi
   - Sibi Prabakaran
   - Simon Michael
   - Steve Mao
   - Vlad Ki
   - Xia Li-yao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200429/32e22c79/attachment.html>

From simon.jakobi at googlemail.com  Wed Apr 29 19:32:54 2020
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Wed, 29 Apr 2020 21:32:54 +0200
Subject: [Haskell-cafe] ANN: stack-2.3.1
In-Reply-To: <CACGj5vJeTpvkQFdf+Y0ptw=TKJEN_Jdu1AzmBFa5GJSZYduwgg@mail.gmail.com>
References: <CACGj5vJeTpvkQFdf+Y0ptw=TKJEN_Jdu1AzmBFa5GJSZYduwgg@mail.gmail.com>
Message-ID: <CAGtp2Si8LN9nDeO1kn35Mf8V39YpSR+y=AYc8TTi99jNYNJLEg@mail.gmail.com>

Hi Manny,

I just gave "stack upgrade" a try:

$ stack upgrade
> Current Stack version: 2.1.3, available download version: 2.3.1
> Newer version detected, downloading
> Querying for archive location for platform: linux-x86_64-static
> Downloading from:
> https://github.com/commercialhaskell/stack/releases/download/v2.3.1/stack-2.3.1-linux-x86_64-static.tar.gz
> Warning: Exception occured when trying to perform binary upgrade:
>          Stack executable "stack-2.3.1-linux-x86_64-static/stack" not
> found in archive from
> https://github.com/commercialhaskell/stack/releases/download/v2.3.1/stack-2.3.1-linux-x86_64-static.tar.gz
> CallStack (from HasCallStack):
>   error, called at src/Stack/Setup.hs:2012:33 in
> stack-2.1.3-HEoMsL9gvgt2vNexTWWwGx:Stack.Setup
>
>          Falling back to source upgrade


I'd rather not recompile stack myself. Is the problem with the archive
something that could be fixed?

Thanks,
Simon




Am Mi., 29. Apr. 2020 um 21:05 Uhr schrieb Emanuel Borsboom <
manny at fpcomplete.com>:

> See https://haskellstack.org/ for installation and upgrade instructions.
>
> Release notes:
>
>    -
>
>    We have reduced the number of platforms that we support with binary
>    releases.
>    The reason behind this is that we've been slowed down in our release
>    process
>    until now with issues trying to build binaries for less common
>    platforms. In
>    order to make sure we can address issues more quickly (like supporting
>    new
>    GHC versions), we're limiting support from the Stack team to:
>    - Linux 64-bit (static)
>       - macOS
>       - Windows 64-bit
>
>    If others want to provide additional binaries, we will definitely be
>    happy
>    for the support. But since our CI system is currently able to produce
>    these
>    three bindists only, that's what we will be providing with the next
>    release.
>    -
>
>    Since we no longer have dynamically linked Linux binaries, we are
>    removing
>    removing the -static suffix from the static Linux binaries. If you have
>    scripts to download the latest stable Linux binary, update them to use
>    linux-x86_64 instead of linux-x86_64-static (if you are already using
>    the
>    former, nothing needs to change). For this release, both are
>    supported, but
>    the next release will no longer have the -static variant.
>    -
>
>    We are also deprecating the download links at
>    https://stackage.org/stack.
>    See this page for the current installation instructions:
>    https://docs.haskellstack.org/en/stable/install_and_upgrade/.
>    -
>
>    These are the canonical locations to download the latest stable
>    binaries
>    from, and will continue to be supported going forward:
>    - Linux 64-bit (static):
>       https://get.haskellstack.org/stable/linux-x86_64.tar.gz
>       - macOS: https://get.haskellstack.org/stable/osx-x86_64.tar.gz
>       - Windows 64-bit:
>       https://get.haskellstack.org/stable/windows-x86_64.zip
>
>    As always, binaries for specific versions are available from the Github
>    releases: https://github.com/commercialhaskell/stack/releases.
>
> *Changes since v2.1.3.1*
>
> Major changes:
>
>    -
>
>    setup-info-locations yaml configuration now allows overwriting the
>    default locations of stack-setup-2.yaml.
>    #5031 <https://github.com/commercialhaskell/stack/pull/5031>
>    #2983 <https://github.com/commercialhaskell/stack/issues/2983>
>    #2913 <https://github.com/commercialhaskell/stack/issues/2913>
>    -
>
>    The setup-info configuration key now allows overwriting parts of the
>    default setup-info
>    -
>
>    The --setup-info-yaml command line flag now may be used in all stack
>    commands such as stack build, and not only in stack setup
>    -
>
>    The --setup-info-yaml may specify multiple locations for
>    stack-setup.yaml files.
>    -
>
>    The stack upload can read first reads environment Variable
>    $HACKAGE_USERNAME and $HACKAGE_PASSWORD if they are missing only then
>    asks for username or password
>    -
>
>    Fully remove GHCJS support.
>    -
>
>    Remove the freeze command. It has been replaced by lock files.
>
> Behavior changes:
>
>    -
>
>    Remove the deprecated --stack-setup-yaml command line argument in
>    favor of --setup-info-yaml
>    #2647 <https://github.com/commercialhaskell/stack/issues/2647>
>    -
>
>    We now recommend checking in generated cabal files for repos. When
>    generating lock files for
>    extra-deps that only include package.yaml files, a deprecation warning
>    will be generated.
>    Also, those packages will no longer be included in the generated lock
>    files.
>    See #5210 <https://github.com/commercialhaskell/stack/issues/5210>.
>
> Other enhancements:
>
>    -
>
>    Add build-output-timestamps flag in yaml. Setting it to true
>    prefixes each build log output line with a timestamp.
>    -
>
>    Show warning about local-programs-path with spaces on windows
>    when running scripts. See
>    #5013 <https://github.com/commercialhaskell/stack/pull/5013>
>    -
>
>    Add ls dependencies json which will print dependencies as JSON.
>    ls dependencies --tree is now ls dependencies tree. See
>    #4424 <https://github.com/commercialhaskell/stack/pull/4424>
>    -
>
>    Remove warning for using Stack with GHC 8.8-8.10, and Cabal 3.0-3.2.
>    -
>
>    Allow relative paths in --setup-info-yaml and tool paths
>    #3394 <https://github.com/commercialhaskell/stack/issues/3394>
>    -
>
>    Added the --only-locals flag. See
>    #5272 <https://github.com/commercialhaskell/stack/issues/5272>
>
> Bug fixes:
>
>    -
>
>    Upgrade pantry: module mapping insertions into the database are now
>    atomic.
>    Previously, if you SIGTERMed at the wrong time while running a script,
>    you
>    could end up with an inconsistent database state.
>    -
>
>    --resolver global doesn't retrieve snapshots list from the internet
>    beause doesn't need it. See #5103
>    <https://github.com/commercialhaskell/stack/issues/5103>
>    -
>
>    Fix using relative links in haddocks output. See
>    #4971 <https://github.com/commercialhaskell/stack/issues/4971>.
>    -
>
>    Do not include generated cabal file information in lock files. See
>    #5045 <https://github.com/commercialhaskell/stack/issues/5045>.
>    -
>
>    Use proper Hoogle executable path when installed automatically. See
>    #4905 <https://github.com/commercialhaskell/stack/issues/4905>
>    -
>
>    Fix GHC version for batched package unregistration. See
>    #4951 <https://github.com/commercialhaskell/stack/issues/4951>
>    -
>
>    Use Hoogle from the snapshot used and not the latest version. See
>    #4905 <https://github.com/commercialhaskell/stack/issues/4905>
>    -
>
>    Resolve "'stty' is not recognized". See
>    #4901 <https://github.com/commercialhaskell/stack/issues/4901>
>    -
>
>    Fix missing reconfigure check causing errors when a package gets
>    used in multiple projects. See
>    #5147 <https://github.com/commercialhaskell/stack/issues/5147>
>
> *Thanks to all our contributors for this release:*
>
>    - Adam McCullough
>    - Akshay Mankar
>    - Brian Wignall
>    - Cheah Jer Fei
>    - Chris Done
>    - David Baynard
>    - davit nalchevanidze
>    - Dino Morelli
>    - Emanuel Borsboom
>    - Felix Yan
>    - flip111
>    - Flowers Safety
>    - Fred Miller
>    - Fyrbll
>    - gdziadkiewicz
>    - Good boy
>    - Hypnoes.Liu
>    - Iisus
>    - Iustin Pop
>    - ivanbakel
>    - Javier Neira
>    - Jeff Happily
>    - jeffhappily
>    - jneira
>    - Justin Le
>    - Kirill Zaborsky
>    - Leif Metcalf
>    - Leonhard Markert
>    - Lokesh Mohanty
>    - Matt Audesse
>    - Michael Snoyman
>    - Mihai Maruseac
>    - NightRa
>    - Phil Ruffwind
>    - qinzhenlong
>    - Robert Hensing
>    - Sasha Bogicevic
>    - Sibi
>    - Sibi Prabakaran
>    - Simon Michael
>    - Steve Mao
>    - Vlad Ki
>    - Xia Li-yao
>
> _______________________________________________
> 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/20200429/7e361389/attachment.html>

From mail at joachim-breitner.de  Wed Apr 29 21:43:12 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 29 Apr 2020 23:43:12 +0200
Subject: [Haskell-cafe] Windows Haskell CI
In-Reply-To: <20200427125749.GB15031@extensa>
References: <r86jog$gk7$1@ciao.gmane.io> <20200427125749.GB15031@extensa>
Message-ID: <063f39587e3e404334c2412b7f4ff2eddb194612.camel@joachim-breitner.de>

Hi,

Am Montag, den 27.04.2020, 14:57 +0200 schrieb Francesco Ariis:
> Recently I was contacted by a user of a small script of mine [1].
> He downloaded the (x86_64) binary and used it on Windows (10?) via
> «Windows Subsystem of Linux».
> 
>      $ uname -a
>      Linux DESKTOP-AHPUUO5 4.4.0-18362-Microsoft #476-Microsoft Fri Nov 01
>      16:53:00 PST 2019 x86_64 x86_64
>      x86_64 GNU/Linux
> 
> I found this fantastic as I loathe dealing with Wine of Virtual Machines
> to provide Win users with a binary.

for my tttool project, I have long used wine to make the Windows
release, but lately I have switch to cross compilation via nix. It took
some experimentation to set up, but now I can produce a single release
zip file that works on Windows, Linux and OSX, all on fairly standard
CI (Travis, but Github Actions would also work):

https://travis-ci.org/github/entropia/tip-toi-reveng
https://github.com/entropia/tip-toi-reveng/blob/master/.travis.yml
https://github.com/entropia/tip-toi-reveng/tree/master/nix

Happy to explain more if people have questions.

It doesn't help for people who want to develop _on_ windows, but at
least releasing _for_ windows is prettty painless this way.

Cheers,
Joachim




-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From ben.franksen at online.de  Wed Apr 29 22:20:00 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Thu, 30 Apr 2020 00:20:00 +0200
Subject: [Haskell-cafe] Windows Haskell CI
In-Reply-To: <063f39587e3e404334c2412b7f4ff2eddb194612.camel@joachim-breitner.de>
References: <r86jog$gk7$1@ciao.gmane.io> <20200427125749.GB15031@extensa>
 <063f39587e3e404334c2412b7f4ff2eddb194612.camel@joachim-breitner.de>
Message-ID: <r8cuih$um2$1@ciao.gmane.io>

Am 29.04.20 um 23:43 schrieb Joachim Breitner:
> for my tttool project, I have long used wine to make the Windows
> release, but lately I have switch to cross compilation via nix. It took
> some experimentation to set up, but now I can produce a single release
> zip file that works on Windows, Linux and OSX, all on fairly standard
> CI (Travis, but Github Actions would also work):
> 
> https://travis-ci.org/github/entropia/tip-toi-reveng
> https://github.com/entropia/tip-toi-reveng/blob/master/.travis.yml
> https://github.com/entropia/tip-toi-reveng/tree/master/nix
> 
> Happy to explain more if people have questions.
> 
> It doesn't help for people who want to develop _on_ windows, but at
> least releasing _for_ windows is prettty painless this way.

Indeed, developing on Windows is something we'd very much like to avoid.
But what we definitely need is to be able to run our test suite on
Windows; and a significant part of that are a couple hundred bash
scripts. If your approach could handle that, I'd be interested to know more.

Cheers
Ben


From merijn at inconsistent.nl  Thu Apr 30 14:21:47 2020
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Thu, 30 Apr 2020 16:21:47 +0200
Subject: [Haskell-cafe] A quick poll about GHC's -with-rtsopts flag
Message-ID: <27EDFCD9-049A-4D34-97BD-2776FE7C1893@inconsistent.nl>

Who here is:
1) Aware that multiple invocations of -with-rtsopts clobber each other, and
2) Actually relies on this behaviour?

This quick and informal poll in relation to this GHC issue: https://gitlab.haskell.org/ghc/ghc/issues/18117

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/20200430/35f901d8/attachment.sig>

From vamchale at gmail.com  Thu Apr 30 14:43:52 2020
From: vamchale at gmail.com (Vanessa McHale)
Date: Thu, 30 Apr 2020 09:43:52 -0500
Subject: [Haskell-cafe] A quick poll about GHC's -with-rtsopts flag
In-Reply-To: <27EDFCD9-049A-4D34-97BD-2776FE7C1893@inconsistent.nl>
References: <27EDFCD9-049A-4D34-97BD-2776FE7C1893@inconsistent.nl>
Message-ID: <0D2DDF45-B1E1-472E-A044-84EEA8360A8D@gmail.com>

I’m aware of it because I’ve run into it :p

I do not rely on such behavior, though having it be consistently wonky across GHCs might be good...

Cheers,
Vanessa McHale

> On Apr 30, 2020, at 9:21 AM, Merijn Verstraaten <merijn at inconsistent.nl> wrote:
> 
> Who here is:
> 1) Aware that multiple invocations of -with-rtsopts clobber each other, and
> 2) Actually relies on this behaviour?
> 
> This quick and informal poll in relation to this GHC issue: https://gitlab.haskell.org/ghc/ghc/issues/18117
> 
> Cheers,
> Merijn
> _______________________________________________
> 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 hcc.olemiss at gmail.com  Thu Apr 30 15:56:31 2020
From: hcc.olemiss at gmail.com (Conrad Cunningham)
Date: Thu, 30 Apr 2020 10:56:31 -0500
Subject: [Haskell-cafe] Please repair Hugs-for-Windows download links
In-Reply-To: <20200429184450.GA417@Annette-Pc2>
References: <CAM7nRYQuov1UsCJxk1PcZTRqzNzwNV0CvBSTWpo_fUUqVr7SZQ@mail.gmail.com>
 <20200429184450.GA417@Annette-Pc2>
Message-ID: <CAFAZ_7MPR3Y2Gn-b+=OnSuJZNdTMsJ6kc8TumhN+2pc0D+UGuQ@mail.gmail.com>

I used Mark Jones's HUGS (or its predecessor Gofer) in my elective
functional programming course from 1993 through 2010. It worked quite
nicely in that context. At some point after 2010, I switched to using GHC
to make sure I did not depend on unmaintained software and to be compatible
with Haskell 2010 and Simon Thompson's textbook.

In recent years, I used Haskell extensively in a required course on
programming language organization. Likely, HUGS would have made supporting
the large number of students in that course a bit easier.

Conrad

H. Conrad Cunningham
Professor Emeritus & Chair Emeritus
The University of Mississippi (Ole Miss)

Hm, what does "unmaintained" mean? Sure, long time (more than 10 years)
> no updates. Nevertheless, there doesn't seem to be a large number of
> requests for changes or corrections that are left without response. You
> may say, there are no users, hence no problems. You may also say that
> the users are simply quietly satisfied.
>
> And there are a few users, as witnessed by Doug's
>
>   https://mail.haskell.org/pipermail/hugs-users/2018-July/000902.html
>
> and Anthony's
>
>   https://mail.haskell.org/pipermail/hugs-users/2018-July/000900.html
>
> a bit further along in the same thread.
>
> When I started using Haskell in 2003, inspired by my use of Miranda in a
> course some 10 years before that, haskell.org had a "Implementation"
> button with Hugs, nhc, and GHC (of course) and perhaps more, Helium,
> jhc, uhc, lhc come to mind, I am not sure. Even on top of just wishing
> the Hugs links repaired, that list would also be high on my wish list.
>
> To be sure, I would never recommend any unmaintained program, such that
> Hugs very clearly labels itself on https://www.haskell.org/hugs (the
> wording is "no longer in development"), for any "serious" use.
> Nevertheless, it seems a waste not to maintain these references to
> valuable material, whether for educational, historical or just
> entertainment reasons. One valuable development, not particularly recent
> but worth mentioning, is Andy Gill's hpc, Haskell Program Coverage, that
> took place initially, as I understand, using nhc with Malcolm Wallace
> guidance.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200430/7b18628e/attachment.html>

From manny at fpcomplete.com  Thu Apr 30 17:14:18 2020
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Thu, 30 Apr 2020 10:14:18 -0700
Subject: [Haskell-cafe] ANN: stack-2.3.1
In-Reply-To: <CAGtp2Si8LN9nDeO1kn35Mf8V39YpSR+y=AYc8TTi99jNYNJLEg@mail.gmail.com>
References: <CACGj5vJeTpvkQFdf+Y0ptw=TKJEN_Jdu1AzmBFa5GJSZYduwgg@mail.gmail.com>
 <CAGtp2Si8LN9nDeO1kn35Mf8V39YpSR+y=AYc8TTi99jNYNJLEg@mail.gmail.com>
Message-ID: <CACGj5vKEsQr=p75Qd1gZnGuzL4P7jFCG0Wyp1S1pVwd-zyzpHQ@mail.gmail.com>

Yes, sorry about that.  It's fixed now and `stack upgrade` once again works
on Linux x86_64.


On Wed, Apr 29, 2020 at 12:33 PM Simon Jakobi <simon.jakobi at googlemail.com>
wrote:

> Hi Manny,
>
> I just gave "stack upgrade" a try:
>
> $ stack upgrade
>> Current Stack version: 2.1.3, available download version: 2.3.1
>> Newer version detected, downloading
>> Querying for archive location for platform: linux-x86_64-static
>> Downloading from:
>> https://github.com/commercialhaskell/stack/releases/download/v2.3.1/stack-2.3.1-linux-x86_64-static.tar.gz
>> Warning: Exception occured when trying to perform binary upgrade:
>>          Stack executable "stack-2.3.1-linux-x86_64-static/stack" not
>> found in archive from
>> https://github.com/commercialhaskell/stack/releases/download/v2.3.1/stack-2.3.1-linux-x86_64-static.tar.gz
>> CallStack (from HasCallStack):
>>   error, called at src/Stack/Setup.hs:2012:33 in
>> stack-2.1.3-HEoMsL9gvgt2vNexTWWwGx:Stack.Setup
>>
>>          Falling back to source upgrade
>
>
> I'd rather not recompile stack myself. Is the problem with the archive
> something that could be fixed?
>
> Thanks,
> Simon
>
>
>
>
> Am Mi., 29. Apr. 2020 um 21:05 Uhr schrieb Emanuel Borsboom <
> manny at fpcomplete.com>:
>
>> See https://haskellstack.org/ for installation and upgrade instructions.
>>
>> Release notes:
>>
>>    -
>>
>>    We have reduced the number of platforms that we support with binary
>>    releases.
>>    The reason behind this is that we've been slowed down in our release
>>    process
>>    until now with issues trying to build binaries for less common
>>    platforms. In
>>    order to make sure we can address issues more quickly (like
>>    supporting new
>>    GHC versions), we're limiting support from the Stack team to:
>>    - Linux 64-bit (static)
>>       - macOS
>>       - Windows 64-bit
>>
>>    If others want to provide additional binaries, we will definitely be
>>    happy
>>    for the support. But since our CI system is currently able to produce
>>    these
>>    three bindists only, that's what we will be providing with the next
>>    release.
>>    -
>>
>>    Since we no longer have dynamically linked Linux binaries, we are
>>    removing
>>    removing the -static suffix from the static Linux binaries. If you
>>    have
>>    scripts to download the latest stable Linux binary, update them to use
>>    linux-x86_64 instead of linux-x86_64-static (if you are already using
>>    the
>>    former, nothing needs to change). For this release, both are
>>    supported, but
>>    the next release will no longer have the -static variant.
>>    -
>>
>>    We are also deprecating the download links at
>>    https://stackage.org/stack.
>>    See this page for the current installation instructions:
>>    https://docs.haskellstack.org/en/stable/install_and_upgrade/.
>>    -
>>
>>    These are the canonical locations to download the latest stable
>>    binaries
>>    from, and will continue to be supported going forward:
>>    - Linux 64-bit (static):
>>       https://get.haskellstack.org/stable/linux-x86_64.tar.gz
>>       - macOS: https://get.haskellstack.org/stable/osx-x86_64.tar.gz
>>       - Windows 64-bit:
>>       https://get.haskellstack.org/stable/windows-x86_64.zip
>>
>>    As always, binaries for specific versions are available from the
>>    Github
>>    releases: https://github.com/commercialhaskell/stack/releases.
>>
>> *Changes since v2.1.3.1*
>>
>> Major changes:
>>
>>    -
>>
>>    setup-info-locations yaml configuration now allows overwriting the
>>    default locations of stack-setup-2.yaml.
>>    #5031 <https://github.com/commercialhaskell/stack/pull/5031>
>>    #2983 <https://github.com/commercialhaskell/stack/issues/2983>
>>    #2913 <https://github.com/commercialhaskell/stack/issues/2913>
>>    -
>>
>>    The setup-info configuration key now allows overwriting parts of the
>>    default setup-info
>>    -
>>
>>    The --setup-info-yaml command line flag now may be used in all stack
>>    commands such as stack build, and not only in stack setup
>>    -
>>
>>    The --setup-info-yaml may specify multiple locations for
>>    stack-setup.yaml files.
>>    -
>>
>>    The stack upload can read first reads environment Variable
>>    $HACKAGE_USERNAME and $HACKAGE_PASSWORD if they are missing only then
>>    asks for username or password
>>    -
>>
>>    Fully remove GHCJS support.
>>    -
>>
>>    Remove the freeze command. It has been replaced by lock files.
>>
>> Behavior changes:
>>
>>    -
>>
>>    Remove the deprecated --stack-setup-yaml command line argument in
>>    favor of --setup-info-yaml
>>    #2647 <https://github.com/commercialhaskell/stack/issues/2647>
>>    -
>>
>>    We now recommend checking in generated cabal files for repos. When
>>    generating lock files for
>>    extra-deps that only include package.yaml files, a deprecation
>>    warning will be generated.
>>    Also, those packages will no longer be included in the generated lock
>>    files.
>>    See #5210 <https://github.com/commercialhaskell/stack/issues/5210>.
>>
>> Other enhancements:
>>
>>    -
>>
>>    Add build-output-timestamps flag in yaml. Setting it to true
>>    prefixes each build log output line with a timestamp.
>>    -
>>
>>    Show warning about local-programs-path with spaces on windows
>>    when running scripts. See
>>    #5013 <https://github.com/commercialhaskell/stack/pull/5013>
>>    -
>>
>>    Add ls dependencies json which will print dependencies as JSON.
>>    ls dependencies --tree is now ls dependencies tree. See
>>    #4424 <https://github.com/commercialhaskell/stack/pull/4424>
>>    -
>>
>>    Remove warning for using Stack with GHC 8.8-8.10, and Cabal 3.0-3.2.
>>    -
>>
>>    Allow relative paths in --setup-info-yaml and tool paths
>>    #3394 <https://github.com/commercialhaskell/stack/issues/3394>
>>    -
>>
>>    Added the --only-locals flag. See
>>    #5272 <https://github.com/commercialhaskell/stack/issues/5272>
>>
>> Bug fixes:
>>
>>    -
>>
>>    Upgrade pantry: module mapping insertions into the database are now
>>    atomic.
>>    Previously, if you SIGTERMed at the wrong time while running a
>>    script, you
>>    could end up with an inconsistent database state.
>>    -
>>
>>    --resolver global doesn't retrieve snapshots list from the internet
>>    beause doesn't need it. See #5103
>>    <https://github.com/commercialhaskell/stack/issues/5103>
>>    -
>>
>>    Fix using relative links in haddocks output. See
>>    #4971 <https://github.com/commercialhaskell/stack/issues/4971>.
>>    -
>>
>>    Do not include generated cabal file information in lock files. See
>>    #5045 <https://github.com/commercialhaskell/stack/issues/5045>.
>>    -
>>
>>    Use proper Hoogle executable path when installed automatically. See
>>    #4905 <https://github.com/commercialhaskell/stack/issues/4905>
>>    -
>>
>>    Fix GHC version for batched package unregistration. See
>>    #4951 <https://github.com/commercialhaskell/stack/issues/4951>
>>    -
>>
>>    Use Hoogle from the snapshot used and not the latest version. See
>>    #4905 <https://github.com/commercialhaskell/stack/issues/4905>
>>    -
>>
>>    Resolve "'stty' is not recognized". See
>>    #4901 <https://github.com/commercialhaskell/stack/issues/4901>
>>    -
>>
>>    Fix missing reconfigure check causing errors when a package gets
>>    used in multiple projects. See
>>    #5147 <https://github.com/commercialhaskell/stack/issues/5147>
>>
>> *Thanks to all our contributors for this release:*
>>
>>    - Adam McCullough
>>    - Akshay Mankar
>>    - Brian Wignall
>>    - Cheah Jer Fei
>>    - Chris Done
>>    - David Baynard
>>    - davit nalchevanidze
>>    - Dino Morelli
>>    - Emanuel Borsboom
>>    - Felix Yan
>>    - flip111
>>    - Flowers Safety
>>    - Fred Miller
>>    - Fyrbll
>>    - gdziadkiewicz
>>    - Good boy
>>    - Hypnoes.Liu
>>    - Iisus
>>    - Iustin Pop
>>    - ivanbakel
>>    - Javier Neira
>>    - Jeff Happily
>>    - jeffhappily
>>    - jneira
>>    - Justin Le
>>    - Kirill Zaborsky
>>    - Leif Metcalf
>>    - Leonhard Markert
>>    - Lokesh Mohanty
>>    - Matt Audesse
>>    - Michael Snoyman
>>    - Mihai Maruseac
>>    - NightRa
>>    - Phil Ruffwind
>>    - qinzhenlong
>>    - Robert Hensing
>>    - Sasha Bogicevic
>>    - Sibi
>>    - Sibi Prabakaran
>>    - Simon Michael
>>    - Steve Mao
>>    - Vlad Ki
>>    - Xia Li-yao
>>
>> _______________________________________________
>> 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/20200430/caf3c07e/attachment.html>

From ietf-dane at dukhovni.org  Thu Apr 30 18:11:51 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 30 Apr 2020 14:11:51 -0400
Subject: [Haskell-cafe] A quick poll about GHC's -with-rtsopts flag
In-Reply-To: <27EDFCD9-049A-4D34-97BD-2776FE7C1893@inconsistent.nl>
References: <27EDFCD9-049A-4D34-97BD-2776FE7C1893@inconsistent.nl>
Message-ID: <20200430181151.GI41308@straasha.imrryr.org>

On Thu, Apr 30, 2020 at 04:21:47PM +0200, Merijn Verstraaten wrote:

> 1) Aware that multiple invocations of -with-rtsopts clobber each other, and
> 2) Actually relies on this behaviour?

Haven't thought about it, but this may makes sense, when configuring
options in more than one file, e.g. foo.cabal, and stack.yaml, and
whichever precedence, should probably be definitive.  Likely cumulative
behaviour would be more surprising.

[ Based on the assumption that GHC options in stack.yaml are in addition
  to the component-specific options in the cabal file. ]

The name is plural, so takes all the options at once.  There could be
new options to incrementally modify the list of rtsopts:

    -set-rtsopt?
    -add-rtsopt?
    -del-rtsopt?

assuming there's a sensible way to accumulate these.

-- 
    Viktor.

From travis at anduril.com  Thu Apr 30 22:26:26 2020
From: travis at anduril.com (Travis Whitaker)
Date: Thu, 30 Apr 2020 15:26:26 -0700
Subject: [Haskell-cafe] A quick poll about GHC's -with-rtsopts flag
In-Reply-To: <20200430181151.GI41308@straasha.imrryr.org>
References: <27EDFCD9-049A-4D34-97BD-2776FE7C1893@inconsistent.nl>
 <20200430181151.GI41308@straasha.imrryr.org>
Message-ID: <CAJ0zmqdb8dURdxXMPFFL8-CiWkR+avYDkyKWRvKCZ6dut+SGYA@mail.gmail.com>

The current (i.e. clobbering) behavior seems like the right choice to me,
for what it's worth.

On Thu, Apr 30, 2020 at 11:12 AM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Thu, Apr 30, 2020 at 04:21:47PM +0200, Merijn Verstraaten wrote:
>
> > 1) Aware that multiple invocations of -with-rtsopts clobber each other,
> and
> > 2) Actually relies on this behaviour?
>
> Haven't thought about it, but this may makes sense, when configuring
> options in more than one file, e.g. foo.cabal, and stack.yaml, and
> whichever precedence, should probably be definitive.  Likely cumulative
> behaviour would be more surprising.
>
> [ Based on the assumption that GHC options in stack.yaml are in addition
>   to the component-specific options in the cabal file. ]
>
> The name is plural, so takes all the options at once.  There could be
> new options to incrementally modify the list of rtsopts:
>
>     -set-rtsopt?
>     -add-rtsopt?
>     -del-rtsopt?
>
> assuming there's a sensible way to accumulate these.
>
> --
>     Viktor.
> _______________________________________________
> 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/20200430/de8c8843/attachment.html>

From dyaitskov at gmail.com  Thu Apr 30 23:30:54 2020
From: dyaitskov at gmail.com (Daneel Yaitskov)
Date: Thu, 30 Apr 2020 16:30:54 -0700
Subject: [Haskell-cafe] [Haskell-Cafe] How to deal with looped references
	inside instances?
Message-ID: <CACNT4y4TN=LABDwG-O0svROgw-M++tvEgcBKBchttiOqZEU4EA@mail.gmail.com>

{-
Hi,

I am trying to translate a Java sample
with looped references below to Haskell.
I've found 2 solutions, but both of them look ugly,
because they require a helper class.
So I am looking for an advice for best practices on working
with looped references in polymorphic types.

interface Engine {
   String showEng();
}

class Car<E extends Engine> {
   int id;
   E eng;

   String show() {
     return "Car with " + eng.showEng();
   }

   int getId() { return id; }
}

class Steam implements Engine {
   Car<Steam> car;
   Stream(Car<Steam> car) { this.car = car; }
   String showEng() {
     return "id " + car.getId();
   }
}

Car<Steam> car = new Car<>();
car.id = 42;
car.eng = new Stream(car);
car.show();

-}

{-# LANGUAGE UndecidableInstances #-} -- Fix2 shortcoming

class Car c where
    getId :: c -> Int

class Engine e where
    showEng :: e -> String

data SteamEng c = SteamEng c

instance (Car c) => Engine (SteamEng c) where
    showEng (SteamEng c) = "id " ++ show (getId c)

{-

First solution is via ShowEng class.
I don't know how to tell type checker
that the type which is got after application of type function
is instantiating Engine class??

  instance (Engine eng) => Show (Car1 eng) where
      show (Car1 _ eng) = "Car1 with " ++ showEng eng

-}


data Car1 eng = Car1 Int (eng (Car1 eng))

class ShowEng f where
    showEng2 :: (Car a) => f a -> String

instance ShowEng SteamEng where
    showEng2 = showEng

{-
A side note. Intuitive alternative for ShowEng which is not working!
showEng2 = showEng means showEng2 gets Engine, but

class HaveEngine f where
    cast :: (Car a) => f a -> f a

instance HaveEngine SteamEng where
    cast = id

...

instance (HaveEngine eng) => Show (Car1 eng) where
    show (Car1 _ eng) = "Car1 with " ++ (showEng (cast eng))

nor

instance (HaveEngine eng) => Show (Car1 eng) where
    show (Car1 _ eng) = "Car1 with " ++ (showEng eng)

-}

instance Car (Car1 e) where
    getId (Car1 id _) = id

instance (ShowEng eng) => Show (Car1 eng) where
    show (Car1 _ eng) = "Car1 with " ++ (showEng2 eng)

c1 = Car1 42 (SteamEng c1)

{-
Second solution is removing argument from engine type parameter.
-}

data Car0 eng = Car0 Int eng

instance Car (Car0 e) where
    getId (Car0 id _) = id

instance (Engine eng) => Show (Car0 eng) where
    show (Car0 _ eng) = "Car0 with " ++ showEng eng


{-
in this case I have to avoid infinite type and introducing
an extra wrapper and instantiating business logic classes for him.

  λ c0 = Car0 42 (SteamEng c0)

  <interactive>:30:6: error:
     • Occurs check: cannot construct the infinite type:
         car ~ Car0 (SteamEng car)
     • In the expression: Car0 (SteamEng c0)
       In an equation for ‘c0’: c0 = Car0 42 (SteamEng c0)
     • Relevant bindings include c0 :: car (bound at <interactive>:30:1)

-}


newtype Fix2 f g = Fix2 (f (g (Fix2 f g)))

instance (Show (f (g (Fix2 f g)))) => Show (Fix2 f g) where
    show (Fix2 a) = show a

{-
  λ c0 = Car0 42 (SteamEng (Fix2 c0))

  <interactive>:62:1: error:
     • No instance for (Car (Fix2 Car0 SteamEng))
         arising from a use of ‘print’
     • In a stmt of an interactive GHCi command: print it
-}

instance (Car (f (g (Fix2 f g)))) => Car (Fix2 f g) where
    getId (Fix2 a) = getId a

c0 = Car0 42 (SteamEng (Fix2 c0))

{-
Thanks,
Daniil
-}