From rae at cs.brynmawr.edu  Sun Jul  1 01:39:33 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sat, 30 Jun 2018 21:39:33 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.6.1-alpha1 available
In-Reply-To: <A77D91D8-2D04-46B9-BBB9-10F25A93041C@cs.brynmawr.edu>
References: <87fu14ufsp.fsf@smart-cactus.org>
 <2c30ad4c-7dfd-9b08-6972-022a7f3933af@iohk.io>
 <A77D91D8-2D04-46B9-BBB9-10F25A93041C@cs.brynmawr.edu>
Message-ID: <3AA93441-CC3A-41F8-964B-FD94D27E3444@cs.brynmawr.edu>

I (really) should have known better: this change is intentional. GHC 8.6 changes the way that * is parsed in types. Specifically, * is always parsed as if it is a synonym for Type (that is, the kind of things like Int and Bool), not a binary operator. If you want it to be a binary operator, you must specify -XNoStarIsType.

Richard

> On Jun 30, 2018, at 7:33 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> 
> I've created a ticket for this: https://ghc.haskell.org/trac/ghc/ticket/15329 <https://ghc.haskell.org/trac/ghc/ticket/15329>
> 
> Thanks for letting us know!
> 
>> On Jun 30, 2018, at 7:26 PM, Vanessa McHale <vanessa.mchale at iohk.io <mailto:vanessa.mchale at iohk.io>> wrote:
>> 
>> The parser seems to be broken. Attempting to build basement <http://hackage.haskell.org/package/basement> yields:
>> 
>> Basement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+), type (*), type (^), type (-) | ^
>> 
>> I'm not 100% sure where to report bugs for the alpha. 
>> 
>> On 06/30/2018 04:26 PM, Ben Gamari wrote:
>>> The GHC development team is pleased to announce the first 
>>> alpha release leading up to GHC 8.6.1. The usual release artifacts
>>> are available from
>>> 
>>>     https://downloads.haskell.org/~ghc/8.6.1-alpha1 <https://downloads.haskell.org/~ghc/8.6.1-alpha1>
>>> 
>>> This is the first release (partially) generated using our new CI
>>> infrastructure. One known issue is that the haddock documentation is
>>> currently unavailable. This will be fixed in the next alpha release. Do
>>> let us know if you spot anything else amiss.
>>> 
>>> As always, do let us know if you encounter any trouble in the course of
>>> testing. Thanks for your help!
>>> 
>>> 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 <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 <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/20180630/2eb4807b/attachment.html>

From ben at well-typed.com  Mon Jul  2 16:55:10 2018
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 02 Jul 2018 12:55:10 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.6.1-alpha1 available
In-Reply-To: <CAB-d4A76gToQ1pg6MrxZq5CihvTUPrGqOSPkvXDOWM1X7Ses7w@mail.gmail.com>
References: <87fu14ufsp.fsf@smart-cactus.org>
 <CAB-d4A76gToQ1pg6MrxZq5CihvTUPrGqOSPkvXDOWM1X7Ses7w@mail.gmail.com>
Message-ID: <874lhhvaqd.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> I don't see an apple/darwin binary. Not sure if that is an oversight or was
> planned.
>
Yikes! Thank you for mentioning this. This is indeed a mistake. I'm
uploading the Darwin distribution right now; it will be done within 20
minutes.

Cheers,

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

From mail at joachim-breitner.de  Mon Jul  2 17:40:33 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 02 Jul 2018 13:40:33 -0400
Subject: [Haskell-cafe] 2nd Call for Talks -- Haskell Implementors' Workshop
Message-ID: <d3f67563b280edb4de6e6988821db0f840c38161.camel@joachim-breitner.de>

                        Call for Contributions
               ACM SIGPLAN Haskell Implementors’ Workshop

            https://icfp18.sigplan.org/track/hiw-2018-papers

                     Co-located with ICFP 2018
                      St. Louis, Missouri, US
              https://conf.researchr.org/home/icfp-2018

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

Proposal Deadline:  Friday, 20 July, 2018
Notification:       Friday, 3 August, 2018
Workshop:           Sunday, 23 September, 2018

Keynote speaker
---------------

This year, the Haskell Implementors’ Workshop is proud to present
Rahul Muttineni as the keynote speaker. Rahul brough the joys of
Haskell to the realm of Java by creating the Eta programming language.

   Title: Let's Go Mainstream with Eta!


   Eta is a fork of GHC that focuses on three core principles: user
   experience, performance, and safety. We'll discuss how we used these
   principles to guide the re-implementation of the GHC runtime and
   code generator on the JVM. Moreover, will also cover the inner
   workings of the FFI and the typechecker support we added for
   subtyping to make it smooth to interact with Java libraries.
   Finally, we'll round out with a look at where Eta is headed and how
   Eta and GHC can collaborate in the future.


About the Haskell Implementors’ Workshop
----------------------------------------

The 10th Haskell Implementors’ Workshop is to be held alongside ICFP
2018 this year in St. Louis. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings. The workshop will be informal and interactive, with open
spaces in the timetable and room for ad-hoc discussion, demos and
lightning talks.

Scope and Target Audience
-------------------------

It is important to distinguish the Haskell Implementors’ Workshop from
the Haskell Symposium which is also co-located with ICFP 2018. The
Haskell Symposium is for the publication of Haskell-related research.
In contrast, the Haskell Implementors’ Workshop will have no
proceedings – although we will aim to make talk videos, slides and
presented data available with the consent of the speakers.

The Implementors’ Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related
tool, or even propose future lines of Haskell development. Members of
the wider Haskell community encouraged to attend the workshop – we
need your feedback to keep the Haskell ecosystem thriving. Students
working with Haskell are specially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we’ve missed, so by all means submit a proposal even
if it doesn’t fit exactly into one of these buckets:

 *  Compilation techniques
 *  Language features and extensions
 *  Type system implementation
 *  Concurrency and parallelism: language design and implementation
 *  Performance, optimisation and benchmarking
 *  Virtual machines and run-time systems
 *  Libraries and tools for development or deployment

Talks
-----

We invite proposals from potential speakers for talks and
demonstrations. We are aiming for 20-minute talks with 5 minutes for
questions and changeovers. We want to hear from people writing
compilers, tools, or libraries, people with cool ideas for directions
in which we should take the platform, proposals for new features to be
implemented, and half-baked crazy ideas. Please submit a talk title
and abstract of no more than 300 words.

Submissions can be made via HotCRP at
                    https://icfp-hiw18.hotcrp.com/
until July 20th (anywhere on earth).

We will also have lightning talks session. These have been very well
received in recent years, and we aim to increase the time available to
them. Lightning talks be ~7mins and are scheduled on the day of the
workshop. Suggested topics for lightning talks are to present a single
idea, a work-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.

Program Committee
-----------------

 * Edwin Brady (University of St. Andrews, UK)
 * Joachim Breitner – chair (University of Pennsylvania)
 * Ben Gamari (Well-Typed LLP)
 * Michael Hanus (Kiel University)
 * Roman Leshchinsky (Facebook)
 * Niki Vazou (University of Maryland)

Contact
-------

 * Joachim Breitner <joachim at cis.upenn.edu>


-- 
Joachim Breitner
Post-Doctoral researcher
http://cis.upenn.edu/~joachim

From simon at joyful.com  Mon Jul  2 19:55:40 2018
From: simon at joyful.com (Simon Michael)
Date: Mon, 2 Jul 2018 20:55:40 +0100
Subject: [Haskell-cafe] ANN: hledger-1.10
In-Reply-To: <9A1F2792-8703-4C09-B6C9-3F0FF96D4A6F@joyful.com>
References: <9A1F2792-8703-4C09-B6C9-3F0FF96D4A6F@joyful.com>
Message-ID: <C5B6AE00-5AAB-4A75-B669-2AD9D29DD187@joyful.com>

FYI,  there were errors in both the hledger-install.sh script and in the stack install instructions on the download page. I believe all are now fixed.


> On Jun 30, 2018, at 10:33 PM, Simon Michael <simon at joyful.com> wrote:
> 
> hledger (http://hledger.org) is a friendly, robust, cross-platform
> program for tracking money, time or other commodities, using
> double-entry accounting, simple plain text file formats, and
> command-line, curses or web UIs.
> 
> I'm very pleased to announce hledger 1.10, including work by release
> contributors:
> 
> Alex Chen,
> Everett Hildenbrandt,
> Jakub Zárybnický,
> Nolan Darilek,
> Dmitry Astapov,
> Jacob Weisz,
> Peter Simons,
> Stephen Morgan,
> Pavlo Kerestey,
> Trevor Riles,
> Léo Gaspard,
> Mykola Orliuk,
> Wad,
> Nana Amfo.
> 
> You'll note this is not 2.0 as previously planned - we will spend a
> bit more time on that.  The next major release is expected to be on
> 2018/09/30.
> 
> Please see http://hledger.org/release-notes#hledger-1.10 for the changes 
> (as soon as I can get to those; until then, the package changelogs):
> 
> http://hackage.haskell.org/package/hledger-1.10/changelog
> http://hackage.haskell.org/package/hledger-ui-1.10/changelog
> http://hackage.haskell.org/package/hledger-web-1.10/changelog
> http://hackage.haskell.org/package/hledger-api-1.10/changelog
> http://hackage.haskell.org/package/hledger-lib-1.10/changelog
> 
> 
> 
> How to get started:
> -------------------
> 
> See http://hledger.org/download for all install methods.
> 
> One of the easiest is the hledger-install script, which requires only
> bash and will build and install the hledger tools in $HOME/.local/bin/:
> 
> $ curl -O https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh
> $ less hledger-install.sh # (do security review)
> $ bash hledger-install.sh # (add -v for more detail; use bash -x to show commands being run)
> 
> or (insecure):
> 
> $ curl https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh | bash
> 
> After installation, ensure $HOME/.local/bin is in your $PATH, and try some commands:
> 
> $ hledger -h            # quick help
> $ hledger help          # list built-in manuals
> $ hledger add           # record some transactions
> $ hledger               # list available commands
> 
> Next, I encourage you to at least skim the tutorials and docs at
> http://hledger.org.
> 
> Say hello and ask questions in the #hledger IRC channel on Freenode:
> http://irc.hledger.org.
> 
> New users and contributors are always welcome! Give feedback, report
> bugs, send pull requests, write, evangelise, donate.
> 
> 
> Best!
> -Simon
> 


From jeffbrown.the at gmail.com  Mon Jul  2 23:26:12 2018
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Mon, 2 Jul 2018 18:26:12 -0500
Subject: [Haskell-cafe] GHC's timing: Now solid enough for music?
Message-ID: <CAEc4Ma0iP0nnf=AYf-n3D4b0hAaYg=XwgDeG5aRG4WLT48T59w@mail.gmail.com>

I just discovered Tom Murphy's Vivid-Synth[1], a Haskell library that lets
you control SuperCollider. (A few very slight changes allowed me to get it
to work in Stack instead of Cabal, as described here[2,3].)

TidalCycles[4] also controls SuperCollider from Haskell. It does tortuous
backflips to hand the timing job over to SuperCollider. If I recall
correctly, that was because SC's timing was more solid than Haskell's.

I modified the Vivid demo to go faster and have a few more voices[5], and
tried running it at the same time as Spotify and Youtube and apt upgrade
and loading LibreOffice and playing some music in VLC, and I detected (by
ear) no timing errors.

Can I expect GHC's maybe-new rhythmic stability to hold up?

[1] http://www.vivid-synth.com/
[2] https://github.com/vivid-synth/vivid/issues/5
[3]
https://github.com/JeffreyBenjaminBrown/vivid/commit/3d25266d4495d9dd8e573f30e819e8ebeffc3f88
[4] https://tidalcycles.org/
[5] https://github.com/JeffreyBenjaminBrown/vivid/blob/jbb/jbb/sine.hs


-- 
Jeff Brown | Jeffrey Benjamin Brown
Website <https://msu.edu/~brown202/>   |   Facebook
<https://www.facebook.com/mejeff.younotjeff>   |   LinkedIn
<https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss
messages here)   |   Github <https://github.com/jeffreybenjaminbrown>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180702/6cf282df/attachment.html>

From amindfv at gmail.com  Tue Jul  3 00:45:28 2018
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 2 Jul 2018 20:45:28 -0400
Subject: [Haskell-cafe] GHC's timing: Now solid enough for music?
In-Reply-To: <CAEc4Ma0iP0nnf=AYf-n3D4b0hAaYg=XwgDeG5aRG4WLT48T59w@mail.gmail.com>
References: <CAEc4Ma0iP0nnf=AYf-n3D4b0hAaYg=XwgDeG5aRG4WLT48T59w@mail.gmail.com>
Message-ID: <7B02D4DA-DDA2-4F09-A856-0B11710FF347@gmail.com>

Vivid has combinators to schedule music with sample-accurate timing (it's as simple as prepending e.g. "doScheduledIn 0.2" to any VividAction, where 0.2 is 0.2 seconds from now - everything will be precise relative to that start time). "doScheduledAt" is another useful one. You can also write to a file with precise timing by prepending e.g. 'writeNRT "foo.wav"'.

Still, I'd be curious to know  the more-general answer to the question of how accurate we can expect forkIO and threadDelay to be, under normal load. E.g. how often/by how much does threadDelay take longer than needed to wake? To my ears and a few quick tests it's usually surprisingly good.

Tom

> El 2 jul 2018, a las 19:26, Jeffrey Brown <jeffbrown.the at gmail.com> escribió:
> 
> I just discovered Tom Murphy's Vivid-Synth[1], a Haskell library that lets you control SuperCollider. (A few very slight changes allowed me to get it to work in Stack instead of Cabal, as described here[2,3].)
> 
> TidalCycles[4] also controls SuperCollider from Haskell. It does tortuous backflips to hand the timing job over to SuperCollider. If I recall correctly, that was because SC's timing was more solid than Haskell's.
> 
> I modified the Vivid demo to go faster and have a few more voices[5], and tried running it at the same time as Spotify and Youtube and apt upgrade and loading LibreOffice and playing some music in VLC, and I detected (by ear) no timing errors.
> 
> Can I expect GHC's maybe-new rhythmic stability to hold up?
> 
> [1] http://www.vivid-synth.com/
> [2] https://github.com/vivid-synth/vivid/issues/5
> [3] https://github.com/JeffreyBenjaminBrown/vivid/commit/3d25266d4495d9dd8e573f30e819e8ebeffc3f88
> [4] https://tidalcycles.org/
> [5] https://github.com/JeffreyBenjaminBrown/vivid/blob/jbb/jbb/sine.hs
> 
> 
> -- 
> Jeff Brown | Jeffrey Benjamin Brown
> Website   |   Facebook   |   LinkedIn(spammy, so I often miss messages here)   |   Github   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180702/2dd5bc2f/attachment.html>

From benl at ouroborus.net  Tue Jul  3 05:14:58 2018
From: benl at ouroborus.net (Ben Lippmeier)
Date: Tue, 3 Jul 2018 15:14:58 +1000
Subject: [Haskell-cafe] GHC's timing: Now solid enough for music?
In-Reply-To: <7B02D4DA-DDA2-4F09-A856-0B11710FF347@gmail.com>
References: <CAEc4Ma0iP0nnf=AYf-n3D4b0hAaYg=XwgDeG5aRG4WLT48T59w@mail.gmail.com>
 <7B02D4DA-DDA2-4F09-A856-0B11710FF347@gmail.com>
Message-ID: <BCD9921A-1582-41F1-B248-E7689881A82B@ouroborus.net>



> On 3 Jul 2018, at 10:45 am, amindfv at gmail.com wrote:
> 
> Vivid has combinators to schedule music with sample-accurate timing (it's as simple as prepending e.g. "doScheduledIn 0.2" to any VividAction, where 0.2 is 0.2 seconds from now - everything will be precise relative to that start time). "doScheduledAt" is another useful one. You can also write to a file with precise timing by prepending e.g. 'writeNRT "foo.wav”'.

> Still, I'd be curious to know  the more-general answer to the question of how accurate we can expect forkIO and threadDelay to be, under normal load. E.g. how often/by how much does threadDelay take longer than needed to wake? To my ears and a few quick tests it's usually surprisingly good.

The question here is somewhat unrelated to the statement above. Audio streams are buffered and are consumed (and thus played back) by the audio hardware which has its own clock. Ensuring that samples are played at the correct time with respect to each other is trivial as you just need to write them into the audio buffer at the correct time. Even if there is a 10ms delay between a user pressing a key and the sample playing, most humans will perceive those actions as simultaneous.

For the second question about forkIO and threadDelay, the I was working on the Repa data parallel library a few years ago (~2013) I did some testing and the time to wake up a GHC green thread on a separate OS process was in the order of 200 microseconds. Note that this is to wake up a OS process on a separate core. The time to communicate to another process via a MVar should be much shorter. The time to wake up a process is also affected by whether you’ve set the core affinity — so that a particular GHC execution capability is bound to a particular OS process / hardware core.

See S5.1.1 of the following paper (on page 8)
http://benl.ouroborus.net/papers/2012-guiding/guiding-Haskell2012.pdf <http://benl.ouroborus.net/papers/2012-guiding/guiding-Haskell2012.pdf>

This includes thread scope diagrams showing the delay between forking a computation and it actually starting.

Ben.

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

From paston.cooper at gmail.com  Tue Jul  3 10:10:12 2018
From: paston.cooper at gmail.com (Justin Paston-Cooper)
Date: Tue, 3 Jul 2018 11:10:12 +0100
Subject: [Haskell-cafe] ForeignPtrs, Finalizers and thread-local storage
Message-ID: <CAEndGgSB-ky0_DNTiCJWNSR9AvZGeXk-ytwE8FYZpv-xDuOHHA@mail.gmail.com>

glpk-hs defines a binding to glpk, a linear programme library. A linear
programme is created by calling `glp_create_prob` and deleted by calling
`glp_delete_prob`. These two C functions manage memory themselves using
thread-local storage.

They are called by glpk-hs using the foreign function interface in the
following code. Note that glpDelProb and glpCreateProb are imported foreign
functions.

runGLPK :: GLPK a -> IO a
runGLPK m = do  lp <- newForeignPtr glpDelProb =<< glpCreateProb
                withForeignPtr lp (execGLPK m)

(
https://github.com/jyp/glpk-hs/blob/master/src/Data/LinearProgram/GLPK/Types.hs
)

It seems that sometimes the finaliser is called in a thread different to
the one where glp_create_prob is called. This leads to glpk aborting with a
dynamic memory allocation error when tries to de-allocate the linear
programme in the wrong thread-local storage, which has never seen that
programme.

Given that the ForeignPtr is used only in runGLPK, runGLPK could of course
be fixed by using Control.Concurrent.bracket instead. However, I'm
interested to know whether there is a solution to this problem.

I'm only assuming that the finaliser sometimes runs in a different thread.
If this is indeed the case, then is there any way to ensure that a
finaliser runs in the thread where the pointer is created?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180703/ca007c20/attachment.html>

From paston.cooper at gmail.com  Tue Jul  3 10:58:54 2018
From: paston.cooper at gmail.com (Justin Paston-Cooper)
Date: Tue, 3 Jul 2018 11:58:54 +0100
Subject: [Haskell-cafe] ForeignPtrs, Finalizers and thread-local storage
In-Reply-To: <CAEndGgSB-ky0_DNTiCJWNSR9AvZGeXk-ytwE8FYZpv-xDuOHHA@mail.gmail.com>
References: <CAEndGgSB-ky0_DNTiCJWNSR9AvZGeXk-ytwE8FYZpv-xDuOHHA@mail.gmail.com>
Message-ID: <CAEndGgS9=smNKu2F8ZJj0mt=YPR=aQDXKjMbrO1tX_E+xBc54A@mail.gmail.com>

The Control.Concurrent.bracket solution should involve
Control.Concurrent.runInBoundThread as well.

On 3 July 2018 at 11:10, Justin Paston-Cooper <paston.cooper at gmail.com>
wrote:

> glpk-hs defines a binding to glpk, a linear programme library. A linear
> programme is created by calling `glp_create_prob` and deleted by calling
> `glp_delete_prob`. These two C functions manage memory themselves using
> thread-local storage.
>
> They are called by glpk-hs using the foreign function interface in the
> following code. Note that glpDelProb and glpCreateProb are imported foreign
> functions.
>
> runGLPK :: GLPK a -> IO a
> runGLPK m = do  lp <- newForeignPtr glpDelProb =<< glpCreateProb
>                 withForeignPtr lp (execGLPK m)
>
> (https://github.com/jyp/glpk-hs/blob/master/src/Data/
> LinearProgram/GLPK/Types.hs)
>
> It seems that sometimes the finaliser is called in a thread different to
> the one where glp_create_prob is called. This leads to glpk aborting with a
> dynamic memory allocation error when tries to de-allocate the linear
> programme in the wrong thread-local storage, which has never seen that
> programme.
>
> Given that the ForeignPtr is used only in runGLPK, runGLPK could of course
> be fixed by using Control.Concurrent.bracket instead. However, I'm
> interested to know whether there is a solution to this problem.
>
> I'm only assuming that the finaliser sometimes runs in a different thread.
> If this is indeed the case, then is there any way to ensure that a
> finaliser runs in the thread where the pointer is created?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180703/1e1ff98e/attachment.html>

From ietf-dane at dukhovni.org  Wed Jul  4 05:27:44 2018
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 4 Jul 2018 01:27:44 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.3 released
In-Reply-To: <87lgc2kyyx.fsf@smart-cactus.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
Message-ID: <20180704052744.GJ85096@straasha.imrryr.org>

On Tue, May 29, 2018 at 04:07:23PM -0400, Ben Gamari wrote:

> The GHC team is pleased to announce the availability of GHC 8.4.3. The
> source distribution, binary distributions, and documentation for this
> release are available at
> 
>     https://downloads.haskell.org/~ghc/8.4.3

While there's no binary distribution for FreeBSD at haskell.org,
as of June 30 there's a FreeBSD ghc-8.4.3 port.  

    https://svnweb.freebsd.org/ports/head/lang/ghc/Makefile?view=log

FWIW, while building it I saw a compiler warning:

    libraries/Cabal/Cabal/Distribution/Simple/Program/Builtin.hs:62:1: warning: [-Wunused-imports]
	The import of ‘System.FilePath’ is redundant
	  except perhaps to import instances from ‘System.FilePath’
	To import instances alone, use: import System.FilePath()
       |
    62 | import System.FilePath (takeDirectory)
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

one thing that puzzles me is that on MacOS/X and Linux running
Haskell code has a fixed virtual size of 1TB, while on FreeBSD the
"vsz" reported by "ps", "top", ... is rought what you'd expect given
the actual memory usage of the program plus overhead from generational
GC.

I am curious as to why the process memory model is platform-dependent
in this manner.  It seems as though on many platforms the RTS gives
the process a large virtul address space, and then allocates memory
by fauliting-in previously unused pages, whereas on FreeBSD brk(2)
(via sbrk() or malloc(), ...) is used to extend the process virtual
size on demand.

--
	Viktor.

From vlatko.basic at gmail.com  Wed Jul  4 11:12:37 2018
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Wed, 4 Jul 2018 13:12:37 +0200
Subject: [Haskell-cafe] Measuring memory usage
In-Reply-To: <5e82210c-6aa4-a7d0-fce6-2668df343214@gmail.com>
References: <5e82210c-6aa4-a7d0-fce6-2668df343214@gmail.com>
Message-ID: <c43a2141-c5d3-36f4-35cc-ddaef362fa80@gmail.com>

Hello again,

I'm still trying to find some method to predict memory usage and came upon this 
page: https://wiki.haskell.org/GHC/Memory_Footprint

I tried to manually calculate how much memory will the record below consume 
(64-bit, 1W = 8B):

newtype Id   = Id    Text deriving (Generic, Data, NFData) -- = 6W
newtype Uid  = Uid   Int  deriving (Generic, Data, NFData) -- = 2W
newtype XUid = XUid  Uid  deriving (Generic, Data, NFData) -- = 2W
newtype YUid = YUid  Uid  deriving (Generic, Data, NFData) -- = 2W
data    Dir  = Yes | No   deriving (Generic, Data)         -- = 2W

data X = X
   { a :: XUid                -- =  2W       -- Int
   , b :: YUid                -- =  2W       -- Int
   , c :: Id                  -- =  6W + 8B  -- Text len 4
   , d :: Either Dir Dir      -- =  1W + 2W  -- Either + Dir + No/Yes
   , e :: Text                -- =  6W + 8B  -- Text len 4
   } deriving (Generic, Data) -- = 19W + 16B = 152 + 16 = 168B

and calculated the assumed sizes of few lists with different number of elements:

Expected list sizes    ([v] = (1 + 3N) words + N * sizeof(v))
   30: 1 + 3W *   30 + (19W *   30 + 16 *   30) =   5,761 B
  600: 1 + 3W *  600 + (19W *  600 + 16 *  600) = 115,201 B
5000: 1 + 3W * 5000 + (19W * 5000 + 16 * 5000) = 960,001 B

I also compared these sizes with three libs (Data.Generics.Schemes.gsize, 
GHC.DataSize.recursiveSizeNF, Weigh) and the results were:

#items recursiveSizeNF gSize      Weigh    Expected  Diff/recursiveSizeNF
    1:            1,416       18        696 168          -
   30:            8,008      931     20,880 5,761        28%
  600:          135,688   18,601    417,600 115,201        15%
5000:        1,121,288  155,001  3,480,000 960,001        14%

As you can see, the results are more than surprising (to me), with 
recursiveSizeNF coming closest. They all measure the same variable.


What am I missing?


For completeness, here are relevant parts of code for creating elements (with 
excessive forcing):

   let mkX i = force X{ a = XUid $ Uid i
                      , b = YUid $ Uid i
                      , c = Id $ tshow i
                      , d = if even i then (Left Yes) else (Right No)
                      , e = T.reverse (tshow i)
                      }
       xs30  = force . map mkX $ take   30 $ randomRs (1000,1030) (mkStdGen 0)
       xs600 = force . map mkX $ take  600 $ randomRs (1000,1600) (mkStdGen 0)
       xs5K  = force . map mkX $ take 5000 $ randomRs (1000,5000) (mkStdGen 0)

   dataSize <- recursiveSizeNF $!! {a}
   let gSize = gsize $!! mkX 0



> -------- Original Message --------
> Subject: Measuring memory usage
> From: Vlatko Basic <vlatko.basic at gmail.com>
> To: haskell-cafe <Haskell-cafe at Haskell.org>
> Date: 29/06/18 14:31
>
>
> Hello,
>
> I've come to some strange results using Weigh package.
>
> It shows that HashMap inside 'data' is using much, much more memory.
>
> The strange thing is that I'm seeing too large mem usage in my app as well 
> (several "MapData" like in records), and trying to figure out with 'weigh' 
> what's keeping the mem.
>
> Noticed that when I change the code to use HashMap directly (not inside 
> 'data', that's the only change), the mem usage observed with top drops down 
> for ~60M, from 850M to 790M.
>
>
> These are the test results for 10K, 5K and 3.3K items for "data MapData k v = 
> MapData (HashMap k v)" (at the end is the full runnable example.)
>
> Case           Allocated  GCs
> HashMap          262,824    0
> HashMap half      58,536    0
> HashMap third     17,064    0
> MapData        4,242,208    4
>
> I tested by changing the order, disabling all but one etc., and the results 
> were the same. Same 'weigh' behaviour with IntMap and Map.
>
>
> So, if anyone knows and has some experience with such issues, my questions are:
>
> 1. Is 'weigh' package reliable/usable, at least to some extent? (the results 
> do show diff between full, half and third)
>
> 2. How do you measure mem consumptions of your large data/records?
>
> 3. If the results are even approximately valid, what could cause such large 
> discrepancies with 'data'?
>
> 4. Is there a way to see if some record has been freed from memory, GCed?
>
>
>
> module Main where
>
> import Prelude
>
> import Control.DeepSeq     (NFData)
> import Data.HashMap.Strict (HashMap, fromList)
> import GHC.Generics        (Generic)
> import Weigh               (mainWith, value)
>
>
> data MapData k v = MapData (HashMap k v) deriving Generic
> instance (NFData k, NFData v) => NFData (MapData k v)
>
> full, half, third :: Int
> full  = 10000
> half  =  5000
> third =  3333
>
> main :: IO ()
> main = mainWith $ do
>   value "HashMap"       (          mkHMList full)
>   value "HashMap half"  (          mkHMList half)
>   value "HashMap third" (          mkHMList third)
>   value "MapData"       (MapData $ mkHMList full)
>
> mkHMList :: Int -> HashMap Int String
> mkHMList n = fromList . zip [1..n] $ replicate n "some text"
>
>
>

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

From lysxia at gmail.com  Wed Jul  4 13:12:13 2018
From: lysxia at gmail.com (Li-yao Xia)
Date: Wed, 4 Jul 2018 09:12:13 -0400
Subject: [Haskell-cafe] Measuring memory usage
In-Reply-To: <c43a2141-c5d3-36f4-35cc-ddaef362fa80@gmail.com>
References: <5e82210c-6aa4-a7d0-fce6-2668df343214@gmail.com>
 <c43a2141-c5d3-36f4-35cc-ddaef362fa80@gmail.com>
Message-ID: <e05a9a71-29f5-3609-f1fe-a8e754197cf4@gmail.com>

Hi Vlatko,

I don't get the same numbers with ghc-datasize

recursiveSize $! xs1   -- 240 (list of length 1)
recursiveSize $! xs30  -- 6296

compiled on GHC 8.0.2 with optimizations (-O)

whereas recursiveSizeNF gives me the size of the thunk (force xs1), 
which depends on whether xs1 is evaluated or not.

The size of X is missing:

- 1 word for the X constructor
- 5 words for the fields (they are not unpacked, this must be explicitly 
required with the {-# UNPACK #-} pragma)
- 8B for one of the text fields (which for some reason takes 64B instead 
of 56B)

That's 56B extra, for a total of 224B. Add in 4W for a singleton list 
and that's 256B. Why are 16B missing in the above 240B figure? Note that 
in mkX, there are two fields equal to (Uid i), so they get shared 
(recursiveSize doesn't recount shared structures). (It's hardly an 
optimization: if we take out the newtypes, the code looks like X {a = i, 
b = i, ...}, so the compiler simply puts the same pointer in the two 
fields.)

Notice also that nullary constructors (in particular Yes/No) will always 
be shared. The compiler may also float out the whole "Left Yes" and 
"Right No" to the toplevel, further reducing the size of longer lists.

gsize counts constructors. In particular, each newtype constructor 
counts as one, and primitives like Int and Char also count as one (the 
value they box is not visible to Data), and Text has a dummy Data 
instance to make it seem like a newtype around [Char].

You can use this snippet to see a trace of the generic traversal:

     everywhereM (\x -> print (dataTypeOf x) >> return x) xs1

Finally, "weigh" counts allocations, which are generally a superset of 
the actual space taken by a data structure once it is fully computed.

Li-yao


On 07/04/2018 07:12 AM, Vlatko Basic wrote:
> Hello again,
> 
> I'm still trying to find some method to predict memory usage and came 
> upon this page: https://wiki.haskell.org/GHC/Memory_Footprint
> 
> I tried to manually calculate how much memory will the record below 
> consume (64-bit, 1W = 8B):
> 
> newtype Id   = Id    Text deriving (Generic, Data, NFData) -- = 6W
> newtype Uid  = Uid   Int  deriving (Generic, Data, NFData) -- = 2W
> newtype XUid = XUid  Uid  deriving (Generic, Data, NFData) -- = 2W
> newtype YUid = YUid  Uid  deriving (Generic, Data, NFData) -- = 2W
> data    Dir  = Yes | No   deriving (Generic, Data)         -- = 2W
> 
> data X = X
>    { a :: XUid                -- =  2W       -- Int
>    , b :: YUid                -- =  2W       -- Int
>    , c :: Id                  -- =  6W + 8B  -- Text len 4
>    , d :: Either Dir Dir      -- =  1W + 2W  -- Either + Dir + No/Yes
>    , e :: Text                -- =  6W + 8B  -- Text len 4
>    } deriving (Generic, Data) -- = 19W + 16B = 152 + 16 = 168B
> 
> and calculated the assumed sizes of few lists with different number of 
> elements:
> 
> Expected list sizes    ([v] = (1 + 3N) words + N * sizeof(v))
>    30: 1 + 3W *   30 + (19W *   30 + 16 *   30) =   5,761 B
>   600: 1 + 3W *  600 + (19W *  600 + 16 *  600) = 115,201 B
> 5000: 1 + 3W * 5000 + (19W * 5000 + 16 * 5000) = 960,001 B
> 
> I also compared these sizes with three libs 
> (Data.Generics.Schemes.gsize, GHC.DataSize.recursiveSizeNF, Weigh) and 
> the results were:
> 
> #items recursiveSizeNF gSize      Weigh    Expected  Diff/recursiveSizeNF
>     1:            1,416       18        696 168          -
>    30:            8,008      931     20,880 5,761        28%
>   600:          135,688   18,601    417,600 115,201        15%
> 5000:        1,121,288  155,001  3,480,000 960,001        14%
> 
> As you can see, the results are more than surprising (to me), with 
> recursiveSizeNF coming closest. They all measure the same variable.
> 
> 
> What am I missing?
> 
> 
> For completeness, here are relevant parts of code for creating elements 
> (with excessive forcing):
> 
>    let mkX i = force X{ a = XUid $ Uid i
>                       , b = YUid $ Uid i
>                       , c = Id $ tshow i
>                       , d = if even i then (Left Yes) else (Right No)
>                       , e = T.reverse (tshow i)
>                       }
>        xs30  = force . map mkX $ take   30 $ randomRs (1000,1030) 
> (mkStdGen 0)
>        xs600 = force . map mkX $ take  600 $ randomRs (1000,1600) 
> (mkStdGen 0)
>        xs5K  = force . map mkX $ take 5000 $ randomRs (1000,5000) 
> (mkStdGen 0)
> 
>    dataSize <- recursiveSizeNF $!! {a}
>    let gSize = gsize $!! mkX 0
> 
> 
> 
>> -------- Original Message --------
>> Subject: Measuring memory usage
>> From: Vlatko Basic <vlatko.basic at gmail.com>
>> To: haskell-cafe <Haskell-cafe at Haskell.org>
>> Date: 29/06/18 14:31
>>
>>
>> Hello,
>>
>> I've come to some strange results using Weigh package.
>>
>> It shows that HashMap inside 'data' is using much, much more memory.
>>
>> The strange thing is that I'm seeing too large mem usage in my app as 
>> well (several "MapData" like in records), and trying to figure out 
>> with 'weigh' what's keeping the mem.
>>
>> Noticed that when I change the code to use HashMap directly (not 
>> inside 'data', that's the only change), the mem usage observed with 
>> top drops down for ~60M, from 850M to 790M.
>>
>>
>> These are the test results for 10K, 5K and 3.3K items for "data 
>> MapData k v = MapData (HashMap k v)" (at the end is the full runnable 
>> example.)
>>
>> Case           Allocated  GCs
>> HashMap          262,824    0
>> HashMap half      58,536    0
>> HashMap third     17,064    0
>> MapData        4,242,208    4
>>
>> I tested by changing the order, disabling all but one etc., and the 
>> results were the same. Same 'weigh' behaviour with IntMap and Map.
>>
>>
>> So, if anyone knows and has some experience with such issues, my 
>> questions are:
>>
>> 1. Is 'weigh' package reliable/usable, at least to some extent? (the 
>> results do show diff between full, half and third)
>>
>> 2. How do you measure mem consumptions of your large data/records?
>>
>> 3. If the results are even approximately valid, what could cause such 
>> large discrepancies with 'data'?
>>
>> 4. Is there a way to see if some record has been freed from memory, GCed?
>>
>>
>>
>> module Main where
>>
>> import Prelude
>>
>> import Control.DeepSeq     (NFData)
>> import Data.HashMap.Strict (HashMap, fromList)
>> import GHC.Generics        (Generic)
>> import Weigh               (mainWith, value)
>>
>>
>> data MapData k v = MapData (HashMap k v) deriving Generic
>> instance (NFData k, NFData v) => NFData (MapData k v)
>>
>> full, half, third :: Int
>> full  = 10000
>> half  =  5000
>> third =  3333
>>
>> main :: IO ()
>> main = mainWith $ do
>>   value "HashMap"       (          mkHMList full)
>>   value "HashMap half"  (          mkHMList half)
>>   value "HashMap third" (          mkHMList third)
>>   value "MapData"       (MapData $ mkHMList full)
>>
>> mkHMList :: Int -> HashMap Int String
>> mkHMList n = fromList . zip [1..n] $ replicate n "some text"
>>
>>
>>
> 
> 
> 
> _______________________________________________
> 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 e1528532 at student.tuwien.ac.at  Wed Jul  4 15:23:10 2018
From: e1528532 at student.tuwien.ac.at (Armin Wurzinger)
Date: Wed, 4 Jul 2018 17:23:10 +0200
Subject: [Haskell-cafe] Typechecker Plugin Constraint Solving
Message-ID: <6e0b2fe1-bc8e-ccf7-f192-00cc91106840@student.tuwien.ac.at>

Good day,

I am currently developing a typechecker plugin for GHC for realizing an 
idea
regarding types based on regular expressions to describe the contents of 
a string.
This is done using type-level literals to denote a particular regex. 
Additionally
there are additional constraints for working with such types. One of those
constraints is called Intersectable and denotes whether an intersection 
between
two regexes would be possible in the sense that there is some common 
alphabet
between them. Furthermore there is a type-level function that calculates 
the
actual intersection between two regex types and returns the resulting 
regex type:

type family Intersectable (a :: Symbol) (b :: Symbol) :: Constraint
type family Intersection (a :: Symbol) (b :: Symbol) :: Symbol

Now i've created a typechecker plugin that resolves such constraints by 
using a
finite-automata representation of the regexes to do the actual work. 
While my
plugin is already able to proof progams where regexes are fully applied, 
i.e. they
can reduce terms to a single regex and then verify the constraints 
accordingly
or reject them, it fails to type "intermediate" functions. As a small 
example
assume the following program:

checkFour :: Intersectable a "[0-4]" => RgxString a -> RgxString 
(Intersection a "[0-4]")
checkFour a = undefined

checkEight :: Intersectable a "[0-8]" => RgxString a -> RgxString 
(Intersection a "[0-8]")
checkEight a = undefined

test = checkFour . checkEight  -- this fails to type correctly
test2 = checkFour $ checkEight $ (RgxString :: RegexString ".*") -- this 
works fine

The constraint solver wants me to proof the following constraints for test:

tcPluginSolve
given   = []
derived = []
wanted  = [
[WD] irred_a2GV {0}:: Intersectable
     (Intersection a0 "[0-8]")
     "[0-4]" (CNonCanonical),
[WD] irred_a2GY {0}:: Intersectable a0 "[0-8]" (CNonCanonical)]

My plugin reduces the first constraint to Intersectable a0 [0-4] as regex
intersection is commutative so i can intersect [0-8] with [0-4] first. 
But i
haven't found out yet how i would tell the compiler to put this reduced
constraint to the type signature instead of the current one where the 
constraint
got dropped at all instead of at least remain unnormalized, and the 
return type
remains unnormalized as well:

RgxString a -> RgxString (Intersection (Intersection a "[0-8]") "[0-4]")

I'd need to tell the typechecker somehow that (Intersection
(Intersection a "[0-8]") "[0-4]") is equal to Intersection a "[0-4]" so 
it substitutes
it accordingly. My idea is that i have to generate given type and 
function equality
constraints during the  typechecking telling it that those 
representations are equal,
but i am really not sure what kind of constraints i need. CTyEqCan for 
instance
seems to require a TyVar on one side while i though i could generate 
something like

Intersection (Intersection a "[0-8]") "[0-4]" ~ Intersection a "[0-4]"

I have already tried a lot but there is little documentation on the whole
constraint solving process and i am slowly getting stuck. Thanks for 
helping!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180704/e882f654/attachment.html>

From vlatko.basic at gmail.com  Wed Jul  4 18:06:32 2018
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Wed, 4 Jul 2018 20:06:32 +0200
Subject: [Haskell-cafe] Measuring memory usage
In-Reply-To: <e05a9a71-29f5-3609-f1fe-a8e754197cf4@gmail.com>
References: <5e82210c-6aa4-a7d0-fce6-2668df343214@gmail.com>
 <c43a2141-c5d3-36f4-35cc-ddaef362fa80@gmail.com>
 <e05a9a71-29f5-3609-f1fe-a8e754197cf4@gmail.com>
Message-ID: <47ea5cee-f0ee-ede0-b59e-b5eb6fafcc5e@gmail.com>

Hi Li-yao,

Thanks for taking the time to test and explain in so much details. It is much 
clearer to me now. :-)

I changed 'b' to "b = YUid $ Uid (i * 2)" so they are different now.

Thanks to your correction, I added 6W to sizeOf X and calculated that its mem 
usage is now 216, but I do not understand which text field are you talking 
about. I added 8 (i.e. 2N) to both Text fields (c and e). I checked xs30 and 
both text fields are 4 chars long.

data X = X                     -- = 1W + 5W
   { a :: XUid                  -- = 2W       -- Int
   , b :: YUid                  -- = 2W       -- Int
   , c :: Id                    -- = 6W + 8B  -- Text len 4
   , d :: Either Dir Dir        -- = W  + 2W
   , e :: Text                  -- = 6W + 8B  -- Text len 4
   } deriving (Generic, D.Data) -- = 25W + 16B = 200 + 16 = 216

so xs1 would be 216 + 4W = 248

The diff is now minimal, except for xs1.

What        ds    Expected   Diff
xs1:       272         248   0.88%    -- overhead 24B - 3W
xs30:    7,232       7,208   0.04%    -- overhead 24B - 3W
xs600: 144,032     144,008   0.00%    -- overhead 24B - 3W


Seems like a constant induced by measurement. For recursiveSizeNF it is also 
constant, 64B - 8W.

I'm very satisfied with the proof that recursiveSize(NF) shows the correct size, 
less 24 (or 64).

I'm on GHC 8.2.2 and saw no diff with different levels of optimization, or 
without any.


Have a nice day,
vlatko



-------- Original Message  --------
Subject: Re: [Haskell-cafe] Measuring memory usage
From: Li-yao Xia <lysxia at gmail.com>
To: vlatko.basic at gmail.com
Cc: haskell-cafe <Haskell-cafe at Haskell.org>
Date: 04/07/18 15:12

> Hi Vlatko,
> 
> I don't get the same numbers with ghc-datasize
> 
> recursiveSize $! xs1   -- 240 (list of length 1)
> recursiveSize $! xs30  -- 6296
> 
> compiled on GHC 8.0.2 with optimizations (-O)
> 
> whereas recursiveSizeNF gives me the size of the thunk (force xs1), which 
> depends on whether xs1 is evaluated or not.
> 
> The size of X is missing:
> 
> - 1 word for the X constructor
> - 5 words for the fields (they are not unpacked, this must be explicitly 
> required with the {-# UNPACK #-} pragma)
> - 8B for one of the text fields (which for some reason takes 64B instead of 56B)
> 
> That's 56B extra, for a total of 224B. Add in 4W for a singleton list and that's 
> 256B. Why are 16B missing in the above 240B figure? Note that in mkX, there are 
> two fields equal to (Uid i), so they get shared (recursiveSize doesn't recount 
> shared structures). (It's hardly an optimization: if we take out the newtypes, 
> the code looks like X {a = i, b = i, ...}, so the compiler simply puts the same 
> pointer in the two fields.)
> 
> Notice also that nullary constructors (in particular Yes/No) will always be 
> shared. The compiler may also float out the whole "Left Yes" and "Right No" to 
> the toplevel, further reducing the size of longer lists.
> 
> gsize counts constructors. In particular, each newtype constructor counts as 
> one, and primitives like Int and Char also count as one (the value they box is 
> not visible to Data), and Text has a dummy Data instance to make it seem like a 
> newtype around [Char].
> 
> You can use this snippet to see a trace of the generic traversal:
> 
>      everywhereM (\x -> print (dataTypeOf x) >> return x) xs1
> 
> Finally, "weigh" counts allocations, which are generally a superset of the 
> actual space taken by a data structure once it is fully computed.
> 
> Li-yao
> 
> 
> On 07/04/2018 07:12 AM, Vlatko Basic wrote:
>> Hello again,
>>
>> I'm still trying to find some method to predict memory usage and came upon 
>> this page: https://wiki.haskell.org/GHC/Memory_Footprint
>>
>> I tried to manually calculate how much memory will the record below consume 
>> (64-bit, 1W = 8B):
>>
>> newtype Id   = Id    Text deriving (Generic, Data, NFData) -- = 6W
>> newtype Uid  = Uid   Int  deriving (Generic, Data, NFData) -- = 2W
>> newtype XUid = XUid  Uid  deriving (Generic, Data, NFData) -- = 2W
>> newtype YUid = YUid  Uid  deriving (Generic, Data, NFData) -- = 2W
>> data    Dir  = Yes | No   deriving (Generic, Data)         -- = 2W
>>
>> data X = X
>>    { a :: XUid                -- =  2W       -- Int
>>    , b :: YUid                -- =  2W       -- Int
>>    , c :: Id                  -- =  6W + 8B  -- Text len 4
>>    , d :: Either Dir Dir      -- =  1W + 2W  -- Either + Dir + No/Yes
>>    , e :: Text                -- =  6W + 8B  -- Text len 4
>>    } deriving (Generic, Data) -- = 19W + 16B = 152 + 16 = 168B
>>
>> and calculated the assumed sizes of few lists with different number of elements:
>>
>> Expected list sizes    ([v] = (1 + 3N) words + N * sizeof(v))
>>    30: 1 + 3W *   30 + (19W *   30 + 16 *   30) =   5,761 B
>>   600: 1 + 3W *  600 + (19W *  600 + 16 *  600) = 115,201 B
>> 5000: 1 + 3W * 5000 + (19W * 5000 + 16 * 5000) = 960,001 B
>>
>> I also compared these sizes with three libs (Data.Generics.Schemes.gsize, 
>> GHC.DataSize.recursiveSizeNF, Weigh) and the results were:
>>
>> #items recursiveSizeNF gSize      Weigh    Expected  Diff/recursiveSizeNF
>>     1:            1,416       18        696 168          -
>>    30:            8,008      931     20,880 5,761        28%
>>   600:          135,688   18,601    417,600 115,201        15%
>> 5000:        1,121,288  155,001  3,480,000 960,001        14%
>>
>> As you can see, the results are more than surprising (to me), with 
>> recursiveSizeNF coming closest. They all measure the same variable.
>>
>>
>> What am I missing?
>>
>>
>> For completeness, here are relevant parts of code for creating elements (with 
>> excessive forcing):
>>
>>    let mkX i = force X{ a = XUid $ Uid i
>>                       , b = YUid $ Uid i
>>                       , c = Id $ tshow i
>>                       , d = if even i then (Left Yes) else (Right No)
>>                       , e = T.reverse (tshow i)
>>                       }
>>        xs30  = force . map mkX $ take   30 $ randomRs (1000,1030) (mkStdGen 0)
>>        xs600 = force . map mkX $ take  600 $ randomRs (1000,1600) (mkStdGen 0)
>>        xs5K  = force . map mkX $ take 5000 $ randomRs (1000,5000) (mkStdGen 0)
>>
>>    dataSize <- recursiveSizeNF $!! {a}
>>    let gSize = gsize $!! mkX 0
>>
>>
>>
>>> -------- Original Message --------
>>> Subject: Measuring memory usage
>>> From: Vlatko Basic <vlatko.basic at gmail.com>
>>> To: haskell-cafe <Haskell-cafe at Haskell.org>
>>> Date: 29/06/18 14:31
>>>
>>>
>>> Hello,
>>>
>>> I've come to some strange results using Weigh package.
>>>
>>> It shows that HashMap inside 'data' is using much, much more memory.
>>>
>>> The strange thing is that I'm seeing too large mem usage in my app as well 
>>> (several "MapData" like in records), and trying to figure out with 'weigh' 
>>> what's keeping the mem.
>>>
>>> Noticed that when I change the code to use HashMap directly (not inside 
>>> 'data', that's the only change), the mem usage observed with top drops down 
>>> for ~60M, from 850M to 790M.
>>>
>>>
>>> These are the test results for 10K, 5K and 3.3K items for "data MapData k v = 
>>> MapData (HashMap k v)" (at the end is the full runnable example.)
>>>
>>> Case           Allocated  GCs
>>> HashMap          262,824    0
>>> HashMap half      58,536    0
>>> HashMap third     17,064    0
>>> MapData        4,242,208    4
>>>
>>> I tested by changing the order, disabling all but one etc., and the results 
>>> were the same. Same 'weigh' behaviour with IntMap and Map.
>>>
>>>
>>> So, if anyone knows and has some experience with such issues, my questions are:
>>>
>>> 1. Is 'weigh' package reliable/usable, at least to some extent? (the results 
>>> do show diff between full, half and third)
>>>
>>> 2. How do you measure mem consumptions of your large data/records?
>>>
>>> 3. If the results are even approximately valid, what could cause such large 
>>> discrepancies with 'data'?
>>>
>>> 4. Is there a way to see if some record has been freed from memory, GCed?
>>>
>>>
>>>
>>> module Main where
>>>
>>> import Prelude
>>>
>>> import Control.DeepSeq     (NFData)
>>> import Data.HashMap.Strict (HashMap, fromList)
>>> import GHC.Generics        (Generic)
>>> import Weigh               (mainWith, value)
>>>
>>>
>>> data MapData k v = MapData (HashMap k v) deriving Generic
>>> instance (NFData k, NFData v) => NFData (MapData k v)
>>>
>>> full, half, third :: Int
>>> full  = 10000
>>> half  =  5000
>>> third =  3333
>>>
>>> main :: IO ()
>>> main = mainWith $ do
>>>   value "HashMap"       (          mkHMList full)
>>>   value "HashMap half"  (          mkHMList half)
>>>   value "HashMap third" (          mkHMList third)
>>>   value "MapData"       (MapData $ mkHMList full)
>>>
>>> mkHMList :: Int -> HashMap Int String
>>> mkHMList n = fromList . zip [1..n] $ replicate n "some text"
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> 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 aquagnu at gmail.com  Thu Jul  5 06:28:42 2018
From: aquagnu at gmail.com (PY)
Date: Thu, 5 Jul 2018 09:28:42 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
Message-ID: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>

Hello, Cafe!

There is an opinion that Bool type has problems. It's "dangerous", 
because it's not good to be used as flag for success/fail result. I read 
this post: 
https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and 
was shocked. How popular is such opinion? Is it true, that bool is "bad" 
type?

As I understand arguments of the post, Bool is bad because: 1) you don't 
know what does True/False mean  2) after comparison you get bit (!) only 
but then you may need to  "recover" the comparing value which was 
"shrink" to bit already.

Let's begin from 2. As I understand the author talks about one register 
computers ;) if he have to "recover" a value. But shown examples are in 
ML, where function arguments are bound to all function body, so you 
don't need to "recover" anything, what was bound as function argument or 
with "let". Sounds totally weird and more close to psychology than to CS :)

Argument #1 is more interesting.

    A Boolean,/b/, is either*true*, or *false*; that’s it.  There is
    no/information/carried by a Boolean beyond its value, and that’s the
    rub.  As Conor McBride puts it, to make use of a Boolean you have to
    know its/provenance/so that you can know what it/means./

Really, what does True/False mean? How to find semantic of True? It's 
very simple, because there is A) contract/interface which interprets 
True/False and also B) there is a help from science.

A) There are a lot of languages (Unix shell, ML, Basic, Haskell, 
C/C++...) with short-circuit expressions. Ex.,

    e1 || e2
    e1 && e2
    e1 orelse e2

where interface is described by its operations: ||, &&, orelse, etc and 
it has absolutely accurate and clear meaning: "||" executes e2 iff e1 
*fails, was not success*. "&&" executes e2 iff e1 was succeeded. I don't 
use words "True" and "False". Because, in different languages marker of 
success/fail is different. For example, in Bash, the fail is any integer 
except 0. In Haskell fail is False. In C is 0... What does mean False 
(and True) is defined by contract/interface of short-circuit operations, 
related to boolean algebra. A rare case when type is bound with 
semantic! We read them literally (native English): e1 or-else e2!

*This means that using of False to indicate success - is error! And no 
way to miss provenance/knowledge what True or False means.*

(the same: what does Right/False mean?)

B) The help from science. Math (and CS) has own history. And one of its 
mail-stones was birth of formal logic and then of Boolean algebra. CS 
implemented those in declarative languages (Prolog, for example). If we 
have some predicate in Prolog, "true" for that predicate means "it was 
achieved", as goal. If that predicate has side-effects, "true" means it 
was achieved, i.e. all its steps (side-effects) were successfully 
executed. Predicate write_text_to_file/2 is "true" when it wrote text to 
file. And no way to return False on success or to think about sacral 
sense of True/False :) And that sense traditionally is the same in all 
programming language. If you invert it, you deny contract, semantic and 
begin to use "inverted" logic :)

We can repeat the same logic with 3.1415926.. What does it mean? 
Meaning, semantic is described, but contract/interface: this magic 
irrational was born from part of algebra, called trigonometry. And this 
algebra defines semantic of Pi, not programmer's usage of Pi, 
programming context, etc. True/False semantic is defining by its 
algebra: boolean. So, programmer should not change their semantic, am I 
right?

So, my question is: is this post a april 1st trolling or author was 
serious? :)

---

Best regards, Paul


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

From vanessa.mchale at iohk.io  Thu Jul  5 07:05:06 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Thu, 5 Jul 2018 02:05:06 -0500
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
Message-ID: <63e086a1-67a4-1422-e944-9b5bcccae5b9@iohk.io>

I think the point is well worth thinking over and thinking about in the
context of programming language design though it may not change the fact
that I use if expressions in my programs.

In the particular example they cite with plus, what happens is:

    A) We have a number
    B) We use that number to get a boolean representing whether or not a
proposition about that number holds
    C) We use that boolean (remembering that it represents something
about the number) to pick another number

However, the second approach works as follows:

    A) We pattern match on the number, using something about its
structure to pick another number.

The value "true" or "false" tells you absolutely nothing about *what* it
is testing. The author is not saying "well you might have forgotten
which boolean is which and used it in the wrong place," rather "we could
do so much better by connecting the *process of proof* to the truth of a
particular proposition." Because those are completely different things!

The status quo is "only model theory matters, I'm going to ignore proof
theory completely," and you shouldn't be satisfied with that! You may
not change how you compose your programs overnight, but there *should*
be a nagging feeling that all programming is on some level immoral.

On 07/05/2018 01:28 AM, PY wrote:
>
> Hello, Cafe!
>
> There is an opinion that Bool type has problems. It's "dangerous",
> because it's not good to be used as flag for success/fail result. I
> read this post:
> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/
> and was shocked. How popular is such opinion? Is it true, that bool is
> "bad" type?
>
> As I understand arguments of the post, Bool is bad because: 1) you
> don't know what does True/False mean  2) after comparison you get bit
> (!) only but then you may need to  "recover" the comparing value which
> was "shrink" to bit already.
>
> Let's begin from 2. As I understand the author talks about one
> register computers ;) if he have to "recover" a value. But shown
> examples are in ML, where function arguments are bound to all function
> body, so you don't need to "recover" anything, what was bound as
> function argument or with "let". Sounds totally weird and more close
> to psychology than to CS :)
>
> Argument #1 is more interesting.
>
>     A Boolean, /b/, is either *true*, or *false*; that’s it.  There is
>     no /information/ carried by a Boolean beyond its value, and that’s
>     the rub.  As Conor McBride puts it, to make use of a Boolean you
>     have to know its /provenance /so that you can know what it /means./
>
> Really, what does True/False mean? How to find semantic of True? It's
> very simple, because there is A) contract/interface which interprets
> True/False and also B) there is a help from science.
>
> A) There are a lot of languages (Unix shell, ML, Basic, Haskell,
> C/C++...) with short-circuit expressions. Ex.,
>
>     e1 || e2
>     e1 && e2
>     e1 orelse e2
>
> where interface is described by its operations: ||, &&, orelse, etc
> and it has absolutely accurate and clear meaning: "||" executes e2 iff
> e1 *fails, was not success*. "&&" executes e2 iff e1 was succeeded. I
> don't use words "True" and "False". Because, in different languages
> marker of success/fail is different. For example, in Bash, the fail is
> any integer except 0. In Haskell fail is False. In C is 0... What does
> mean False (and True) is defined by contract/interface of
> short-circuit operations, related to boolean algebra. A rare case when
> type is bound with semantic! We read them literally (native English):
> e1 or-else e2!
>
> *This means that using of False to indicate success - is error! And no
> way to miss provenance/knowledge what True or False means.*
>
> (the same: what does Right/False mean?)
>
> B) The help from science. Math (and CS) has own history. And one of
> its mail-stones was birth of formal logic and then of Boolean algebra.
> CS implemented those in declarative languages (Prolog, for example).
> If we have some predicate in Prolog, "true" for that predicate means
> "it was achieved", as goal. If that predicate has side-effects, "true"
> means it was achieved, i.e. all its steps (side-effects) were
> successfully executed. Predicate write_text_to_file/2 is "true" when
> it wrote text to file. And no way to return False on success or to
> think about sacral sense of True/False :) And that sense traditionally
> is the same in all programming language. If you invert it, you deny
> contract, semantic and begin to use "inverted" logic :)
>
> We can repeat the same logic with 3.1415926.. What does it mean?
> Meaning, semantic is described, but contract/interface: this magic
> irrational was born from part of algebra, called trigonometry. And
> this algebra defines semantic of Pi, not programmer's usage of Pi,
> programming context, etc. True/False semantic is defining by its
> algebra: boolean. So, programmer should not change their semantic, am
> I right?
>
> So, my question is: is this post a april 1st trolling or author was
> serious? :)
>
> ---
>
> Best regards, Paul
>
>
>
>
> _______________________________________________
> 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/20180705/fd72635d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180705/fd72635d/attachment.sig>

From leandro at ostera.io  Thu Jul  5 07:48:53 2018
From: leandro at ostera.io (Leandro Ostera)
Date: Thu, 5 Jul 2018 09:48:53 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <63e086a1-67a4-1422-e944-9b5bcccae5b9@iohk.io>
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
 <63e086a1-67a4-1422-e944-9b5bcccae5b9@iohk.io>
Message-ID: <CAH2TZMiUeb6dUWEEjrzQc2r8tF2xyKRsu=zKu-qA3iOf1KVEeQ@mail.gmail.com>

> You may not change how you compose your programs
> overnight, but there *should* be a nagging feeling that all
> programming is on some level immoral.

Perhaps elaborating on this is tangential to the issue at hand, but I’d
love to hear/read more behind this thought process. Could you elaborate?
On Thu, 5 Jul 2018 at 09:05, Vanessa McHale <vanessa.mchale at iohk.io> wrote:

> I think the point is well worth thinking over and thinking about in the
> context of programming language design though it may not change the fact
> that I use if expressions in my programs.
>
> In the particular example they cite with plus, what happens is:
>
>     A) We have a number
>     B) We use that number to get a boolean representing whether or not a
> proposition about that number holds
>     C) We use that boolean (remembering that it represents something about
> the number) to pick another number
>
> However, the second approach works as follows:
>
>     A) We pattern match on the number, using something about its structure
> to pick another number.
>
> The value "true" or "false" tells you absolutely nothing about *what* it
> is testing. The author is not saying "well you might have forgotten which
> boolean is which and used it in the wrong place," rather "we could do so
> much better by connecting the *process of proof* to the truth of a
> particular proposition." Because those are completely different things!
>
> The status quo is "only model theory matters, I'm going to ignore proof
> theory completely," and you shouldn't be satisfied with that! You may not
> change how you compose your programs overnight, but there *should* be a
> nagging feeling that all programming is on some level immoral.
>
> On 07/05/2018 01:28 AM, PY wrote:
>
> Hello, Cafe!
>
> There is an opinion that Bool type has problems. It's "dangerous", because
> it's not good to be used as flag for success/fail result. I read this post:
> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and
> was shocked. How popular is such opinion? Is it true, that bool is "bad"
> type?
>
> As I understand arguments of the post, Bool is bad because: 1) you don't
> know what does True/False mean  2) after comparison you get bit (!) only
> but then you may need to  "recover" the comparing value which was "shrink"
> to bit already.
>
> Let's begin from 2. As I understand the author talks about one register
> computers ;) if he have to "recover" a value. But shown examples are in ML,
> where function arguments are bound to all function body, so you don't need
> to "recover" anything, what was bound as function argument or with "let".
> Sounds totally weird and more close to psychology than to CS :)
>
> Argument #1 is more interesting.
>
> A Boolean, *b*, is either *true*, or *false*; that’s it.  There is no
> *information* carried by a Boolean beyond its value, and that’s the rub.
> As Conor McBride puts it, to make use of a Boolean you have to know its
> *provenance *so that you can know what it *means.*
>
> Really, what does True/False mean? How to find semantic of True? It's very
> simple, because there is A) contract/interface which interprets True/False
> and also B) there is a help from science.
>
> A) There are a lot of languages (Unix shell, ML, Basic, Haskell, C/C++...)
> with short-circuit expressions. Ex.,
>
> e1 || e2
> e1 && e2
> e1 orelse e2
>
> where interface is described by its operations: ||, &&, orelse, etc and it
> has absolutely accurate and clear meaning: "||" executes e2 iff e1 *fails,
> was not success*. "&&" executes e2 iff e1 was succeeded. I don't use
> words "True" and "False". Because, in different languages marker of
> success/fail is different. For example, in Bash, the fail is any integer
> except 0. In Haskell fail is False. In C is 0... What does mean False (and
> True) is defined by contract/interface of short-circuit operations, related
> to boolean algebra. A rare case when type is bound with semantic! We read
> them literally (native English): e1 or-else e2!
>
> *This means that using of False to indicate success - is error! And no way
> to miss provenance/knowledge what True or False means.*
>
> (the same: what does Right/False mean?)
>
> B) The help from science. Math (and CS) has own history. And one of its
> mail-stones was birth of formal logic and then of Boolean algebra. CS
> implemented those in declarative languages (Prolog, for example). If we
> have some predicate in Prolog, "true" for that predicate means "it was
> achieved", as goal. If that predicate has side-effects, "true" means it was
> achieved, i.e. all its steps (side-effects) were successfully executed.
> Predicate write_text_to_file/2 is "true" when it wrote text to file. And no
> way to return False on success or to think about sacral sense of True/False
> :) And that sense traditionally is the same in all programming language. If
> you invert it, you deny contract, semantic and begin to use "inverted"
> logic :)
>
> We can repeat the same logic with 3.1415926.. What does it mean? Meaning,
> semantic is described, but contract/interface: this magic irrational was
> born from part of algebra, called trigonometry. And this algebra defines
> semantic of Pi, not programmer's usage of Pi, programming context, etc.
> True/False semantic is defining by its algebra: boolean. So, programmer
> should not change their semantic, am I right?
>
> So, my question is: is this post a april 1st trolling or author was
> serious? :)
>
> ---
>
> Best regards, Paul
>
>
>
>
> _______________________________________________
> 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/20180705/6ade09b9/attachment.html>

From asandroq at gmail.com  Thu Jul  5 13:30:22 2018
From: asandroq at gmail.com (Alex Silva)
Date: Thu, 5 Jul 2018 15:30:22 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
Message-ID: <7e144477-0a77-d401-915a-a47539656107@gmail.com>

On 05/07/18 08:28, PY wrote:
> Hello, Cafe!
> 
> There is an opinion that Bool type has problems. It's "dangerous",
> because it's not good to be used as flag for success/fail result. I read
> this post:
> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and
> was shocked. How popular is such opinion? Is it true, that bool is "bad"
> type?
> 

The text never uses the word "dangerous" or "bad", it says that the Bool
type is boring, carries no information and leads to blindness. For
instance, let's say that you want to call `head` on a list. But `head`
is a partial function, so you need to check first if the list is not
empty. Then you branch on the result of the test and call `head` or do
something else in the other branch. At first the code is clear and easy
to follow. But after several refactorings and new features, the call to
`head` was pushed far away from the emptiness test. As you can see, this
code is now very fragile. If someone changes the test to something else
it will still compile but `head` may now fail at run time.

On the other hand, if you use a type expressive enough to encode a proof
that the list is not empty (trivial in Agda or Idris), that proof will
be in scope and a total version of `head` will only compile if it finds
the proof.

Cheers,
-- 
-alex
https://unendli.ch/

From ben at smart-cactus.org  Thu Jul  5 13:32:31 2018
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 05 Jul 2018 09:32:31 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.3 released
In-Reply-To: <20180704052744.GJ85096@straasha.imrryr.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
 <20180704052744.GJ85096@straasha.imrryr.org>
Message-ID: <878t6pst91.fsf@smart-cactus.org>

Viktor Dukhovni <ietf-dane at dukhovni.org> writes:

> On Tue, May 29, 2018 at 04:07:23PM -0400, Ben Gamari wrote:
>
>> The GHC team is pleased to announce the availability of GHC 8.4.3. The
>> source distribution, binary distributions, and documentation for this
>> release are available at
>> 
>>     https://downloads.haskell.org/~ghc/8.4.3
>
Indeed. I have had quite some difficulty finding a toolchain on FreeBSD
that works. I found that depending upon which FreeBSD version I use
(10.3 or 11) I either encounter linker crashes or very high numbers of
crashing tests. I didn't spend much time on the issue as no one raised
the issue.

> While there's no binary distribution for FreeBSD at haskell.org,
> as of June 30 there's a FreeBSD ghc-8.4.3 port.  
>
>     https://svnweb.freebsd.org/ports/head/lang/ghc/Makefile?view=log
>
Ahh, great! Thanks for doing this. I'll try to replicate this while
doing the builds for 8.6.

> FWIW, while building it I saw a compiler warning:
>
>     libraries/Cabal/Cabal/Distribution/Simple/Program/Builtin.hs:62:1: warning: [-Wunused-imports]
> 	The import of ‘System.FilePath’ is redundant
> 	  except perhaps to import instances from ‘System.FilePath’
> 	To import instances alone, use: import System.FilePath()
>        |
>     62 | import System.FilePath (takeDirectory)
>        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
Indeed this is expected.

> one thing that puzzles me is that on MacOS/X and Linux running
> Haskell code has a fixed virtual size of 1TB, while on FreeBSD the
> "vsz" reported by "ps", "top", ... is rought what you'd expect given
> the actual memory usage of the program plus overhead from generational
> GC.
>
> I am curious as to why the process memory model is platform-dependent
> in this manner.  It seems as though on many platforms the RTS gives
> the process a large virtul address space, and then allocates memory
> by fauliting-in previously unused pages, whereas on FreeBSD brk(2)
> (via sbrk() or malloc(), ...) is used to extend the process virtual
> size on demand.
>
We use a much different memory allocation strategy on FreeBSD which
(AFAIK) does not allow one to reserve address space without also
committing. On Linux we ask up-front for a single 1TB address space
mapping and lazily commit it as we need it. This allows out heap check
to be extremely efficient as we know the heap is contiguous. On
platforms that don't support this we need to use a slower check. This
behavior can be switched off on Linux using the
--disable-large-address-space configure flag.

Cheers,

- Ben

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

From jannis at limperg.de  Thu Jul  5 14:02:46 2018
From: jannis at limperg.de (Jannis Limperg)
Date: Thu, 5 Jul 2018 16:02:46 +0200
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.3 released
In-Reply-To: <87lgc2kyyx.fsf@smart-cactus.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
Message-ID: <37c19c47-5984-4a59-fb04-b4bd962d53d8@limperg.de>

Hej Ben,

the release page for GHC 8.4.3 is currently missing a Fedora binary. Is
this intentional?

(It would be nice to have this binary since afaict `stack setup` relies
on it for systems with ncurses6/tinfo8.)

Cheers,
Jannis

From monnier at iro.umontreal.ca  Thu Jul  5 14:27:15 2018
From: monnier at iro.umontreal.ca (Stefan Monnier)
Date: Thu, 05 Jul 2018 10:27:15 -0400
Subject: [Haskell-cafe] Bool is not...safe?!
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
Message-ID: <jwv7em9hij0.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>

> There is an opinion that Bool type has problems. It's "dangerous", because
> it's not good to be used as flag for success/fail result. I read this post:
> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and was
> shocked. How popular is such opinion? Is it true, that bool is "bad" type?

To me the argument boils down to the `head` case mentioned by Alex.

Most programming languages force you to write code like

    if List.empty l then
        ...
    else
        ... x = List.head l ...

where the problem is that the fact that the List.head call will find the
list non-empty is not obvious (in the sense that it requires reasoning).

In contrast

    case l
    | nil => ...
    | cons x xs => ...

makes it trivially obvious that `x` is extracted from a non-empty list
without any reasoning needed at all.


        Stefan


From aquagnu at gmail.com  Thu Jul  5 15:04:50 2018
From: aquagnu at gmail.com (PY)
Date: Thu, 5 Jul 2018 18:04:50 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <jwv7em9hij0.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
 <jwv7em9hij0.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
Message-ID: <c22ceac6-c145-cc93-5aff-d49dec5852ed@gmail.com>

So, the problem is that test of emptiness does not force you to 
something right. And possible errors are:

    if empty:
       # do if NOT empty - BUG!
    else:
       # do if EMPTY - BUG TOO!

    or

    # do if NOT empty - BUG!
    if NOT empty:
       # now nothing or old "do if NOT EMPTY"


OK, I understand it. But how is it related to Booleans? :) Sure, if you 
use Maybe or Either you are forced with nature of ">>=": it cuts off 
incorrect branches. With if-then - it does not. But it's not related to 
Bool: Bool is result for predicates. Maybe/Either forces you with magic 
operation ">>=" (which is hidden by do-sugar). Bool does not force you - 
right. But it's problem of Haskell implementation. For example, Prolog 
"forces" you:

Haskell forces you in monad "do":
   do
     someInt <- someMaybe
     -- will not be executed if someMaybe is Nothing

Prolog forces you too but on success/fail (Boolean?):
   someGoal, anotherGoal   % anotherGoal will not be executed if 
someGoal is False

Haskell adds only "bool" function which is close to ">>=" in terms of it 
hides semantic of right bool's processing, avoid those possible errors. 
If you will use "bool" anywhere when you use Bool as result - all will 
be fine, or? Sure, you can move "head" usage out of "bool" but you will 
get empty "bool"s argument. So, IMHO examples of problem with booleans 
is not related to Bool type at whole, but related to problem that Bool 
has kind * but not * -> * to be processed in monadic style (and to has 
needed  ">>=" semantic to force you).

OK, but original article was not about Haskell's monads, but about Bool 
in general :)    Also what I can't understand: if we will think in such 
manner does it mean that "if..test" construct is "boring"/"blindness" 
(excuse my English:) at whole? And all predicates must be removed from 
the language? What will happen to `filter` function without predicates? 
And no way to avoid "if..else" construct and predicates functions.

As for me, this question is related to static-types fanaticism and "How 
many angels could dance on the head of a pin". Example with "head" is 
totally incorrect - it can deconstruct list and no need to predicate 
function. But what I should do with isSpace, isLower, etc? How to use 
predicates at whole? :)   To map   a -> Bool   to   a -> Maybe a  ?
What about function which returns IO Bool? Action which can ends with 
non-critical failure (and need optionally logging, for example) ?


05.07.2018 17:27, Stefan Monnier wrote:
>> There is an opinion that Bool type has problems. It's "dangerous", because
>> it's not good to be used as flag for success/fail result. I read this post:
>> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and was
>> shocked. How popular is such opinion? Is it true, that bool is "bad" type?
> To me the argument boils down to the `head` case mentioned by Alex.
>
> Most programming languages force you to write code like
>
>      if List.empty l then
>          ...
>      else
>          ... x = List.head l ...
>
> where the problem is that the fact that the List.head call will find the
> list non-empty is not obvious (in the sense that it requires reasoning).
>
> In contrast
>
>      case l
>      | nil => ...
>      | cons x xs => ...
>
> makes it trivially obvious that `x` is extracted from a non-empty list
> without any reasoning needed at all.
>
>
>          Stefan
>
> _______________________________________________
> 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/20180705/52d5049d/attachment.html>

From b at chreekat.net  Thu Jul  5 17:51:54 2018
From: b at chreekat.net (Bryan Richter)
Date: Thu, 5 Jul 2018 13:51:54 -0400
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <c22ceac6-c145-cc93-5aff-d49dec5852ed@gmail.com>
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
 <jwv7em9hij0.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 <c22ceac6-c145-cc93-5aff-d49dec5852ed@gmail.com>
Message-ID: <55e21eb7-0e6c-699d-05fa-51b7a5eef773@chreekat.net>

Happily, all of this has nothing to do with monads or Haskell's
special syntax for monads. :)

I would not call it static-types fanaticism, but rather,
pattern-matching fanaticism. To me, "boolean blindness" is a cute way
to describe how this:

    -- | Sum the first two ints of a list, if possible
    foo1 :: [Int] -> Maybe Int
    foo1 (x:y:_) = Just (x + y)
    foo1 [x] = Just x
    foo1 [] = Nothing

is better than this:

    -- | Same thing, but with "blind bools"
    foo2 :: [Int] -> Maybe Int
    foo2 xs =
        if length x >= 2
            then Just ((x!!1) + (x!!2))
            else if length x == 1
                then Just (x!!1)
                else Nothing

NB: I already had to correct one mistake in that second code while
writing it, and there may be others (I forget if it's (!!) or (!), and
I also forget if it's 0-based or 1-based).

The first is a description of what I want. It is correct by
construction.

The second requires converting the description of what I want (sum of
the first two ints) into a description of how it is computed, with
steps like "find the length and compare it to 2".

By using pattern matching, I get both a guarantee of the structure I
need, as well as information from within the structure at the same
time. With an operational description, I have to do it in separate
steps.

To me, that's the crux of boolean blindness: Use pattern matching
whenever possible!


On 07/05/2018 11:04 AM, PY wrote:
> So, the problem is that test of emptiness does not force you to something right. And possible errors are:
> 
>     if empty:
>       # do if NOT empty - BUG!
>     else:
>       # do if EMPTY - BUG TOO!
> 
>     or
> 
>     # do if NOT empty - BUG!
>     if NOT empty:
>       # now nothing or old "do if NOT EMPTY"
> 
> 
> OK, I understand it. But how is it related to Booleans? :) Sure, if you use Maybe or Either you are forced with nature of ">>=": it cuts off incorrect branches. With if-then - it does not. But it's not
> related to Bool: Bool is result for predicates. Maybe/Either forces you with magic operation ">>=" (which is hidden by do-sugar). Bool does not force you - right. But it's problem of Haskell
> implementation. For example, Prolog "forces" you:
> 
> Haskell forces you in monad "do":
>   do
>     someInt <- someMaybe
>     -- will not be executed if someMaybe is Nothing
> 
> Prolog forces you too but on success/fail (Boolean?):
>   someGoal, anotherGoal   % anotherGoal will not be executed if someGoal is False
> 
> Haskell adds only "bool" function which is close to ">>=" in terms of it hides semantic of right bool's processing, avoid those possible errors. If you will use "bool" anywhere when you use Bool as
> result - all will be fine, or? Sure, you can move "head" usage out of "bool" but you will get empty "bool"s argument. So, IMHO examples of problem with booleans is not related to Bool type at whole,
> but related to problem that Bool has kind * but not * -> * to be processed in monadic style (and to has needed  ">>=" semantic to force you).
> 
> OK, but original article was not about Haskell's monads, but about Bool in general :)    Also what I can't understand: if we will think in such manner does it mean that "if..test" construct is
> "boring"/"blindness" (excuse my English:) at whole? And all predicates must be removed from the language? What will happen to `filter` function without predicates? And no way to avoid "if..else"
> construct and predicates functions.
> 
> As for me, this question is related to static-types fanaticism and "How many angels could dance on the head of a pin". Example with "head" is totally incorrect - it can deconstruct list and no need to
> predicate function. But what I should do with isSpace, isLower, etc? How to use predicates at whole? :)   To map   a -> Bool   to   a -> Maybe a  ?
> What about function which returns IO Bool? Action which can ends with non-critical failure (and need optionally logging, for example) ?
> 
> 
> 05.07.2018 17:27, Stefan Monnier wrote:
>>> There is an opinion that Bool type has problems. It's "dangerous", because
>>> it's not good to be used as flag for success/fail result. I read this post:
>>> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and was
>>> shocked. How popular is such opinion? Is it true, that bool is "bad" type?
>> To me the argument boils down to the `head` case mentioned by Alex.
>>
>> Most programming languages force you to write code like
>>
>>     if List.empty l then
>>         ...
>>     else
>>         ... x = List.head l ...
>>
>> where the problem is that the fact that the List.head call will find the
>> list non-empty is not obvious (in the sense that it requires reasoning).
>>
>> In contrast
>>
>>     case l
>>     | nil => ...
>>     | cons x xs => ...
>>
>> makes it trivially obvious that `x` is extracted from a non-empty list
>> without any reasoning needed at all.
>>
>>
>>         Stefan
>>
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180705/e0e6b2ec/attachment.sig>

From jo at durchholz.org  Thu Jul  5 18:48:10 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Thu, 5 Jul 2018 20:48:10 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
Message-ID: <2a0a052c-2e68-ec3e-168b-9ecbbd4f307c@durchholz.org>

Hi,

the criticism is valid but mostly irrelevant.
> There is an opinion that Bool type has problems. It's "dangerous", 
> because it's not good to be used as flag for success/fail result.

Actually that's the one good use case.
Also, Boolean-as-a-type means that you do not need a separate language 
concept of Condition, Conditions are just those Expressions that happen 
to be of type Boolean. And suddenly you can write functions that operate 
on Conditions, or define operators for them (if the language allows 
operator definitions), etc.

> I read this post: 
> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/

Well, the first two paragraphs are just overgeneralizations of personal 
observations.

> and was shocked. How popular is such opinion?

It's a fringe opinion. Most people don't even think about whether 
Boolean is an appropriate type.

 > Is it true, that bool is "bad" type?
> 
> As I understand arguments of the post, Bool is bad because: 1) you
> don't know what does True/False mean  2) after comparison you get bit
> (!) only but then you may need to  "recover" the comparing value
> which was "shrink" to bit already.

Sure. That's a valid point the post is making.
So you shouldn't move the creation of a Boolean too far away from its 
consumption.

The same argument holds for any numeric data type; if you pass around 
Floats, you quickly lose knowledge whether it's yards or meters (that 
kind of problem actually made an interplanetary probe miss its 
destination planet).

So you simply use whatever the language offers for making binary 
distinctions. In C you use the preprocessor to say PRESENT or ABSENT 
instead of true or false (actually 0 or 1); in Java you use an enum, in 
Haskell you use a data type.

> Really, what does True/False mean? How to find semantic of True? It's
>  very simple, because there is A) contract/interface which interprets
>  True/False and also B) there is a help from science.

This works as long as the contract is easily deducible from the context 
in the program.
I.e. if you have a file-is-open function, then the contract of that 
function says that the result is True or False, and as long as the value 
from the function is kept in contexts where it's clear that we are 
talking about a file-open status, that's good enough.
Things can get nasty when you start moving a file-is-open Boolean into a 
"valid" attribute. You (as a human reader) lose the information that the 
value is related to a file-open status.
Note that such a loss of context may actually be intentional, if the 
goal is to have more abstract code and we don't care anymore whether 
that valid=False status relates to files or whether it's a weekday. 
Though that's exactly the situation where the blog post's arguments are 
irrelevant, too :-)

> *This means that using of False to indicate success - is error!

Not really.
It can mislead a human reader, so it should be avoided. But I have had 
some rare occasions where isFailure: Boolean was the correct declaration 
to use (e.g. if isFailure is False by default - actually that's not a 
too rare situation now that I think about it).

 > And
> no way to miss provenance/knowledge what True or False means.*

Except that if you pass the value to a variable named "isSuccess", you 
have a bug.

> (the same: what does Right/False mean?)

Personally, I avoid the True/False terminology; it (mis)applies the 
concept of "desirable" or "truth", and boolean values aren't about 
desirability or truth.

Just assume the values are "Yes" and "No"; actually this is exactly the 
issue the blog post is really talking about: "Yes" and "No" are answers, 
but answers are useful only as long as you know the question.
(Reminds me of "42" in the Douglas Adams fiction: the supercomputer gave 
that as the ultimate answer, now they are building a larger 
supercomputer to find out what the question to that answer is.)

> B) The help from science.

Science is not too relevant here.
The blog post is talking about maintainability, i.e. programmer psychology.

For Booleans, science tells you a lot about what you can do with them, 
but it does not tell you what the results of your operations *mean*.


> So, my question is: is this post a april 1st trolling or author was 
> serious? :)

The latter, but you missed the point ;-)
(SCNR)

BTW the post is pretty rambling, it touches a lot of points but is never 
quite precise.
I hope I did better but I'll leave that to better judgement than mine :-)

From olf at aatal-apotheke.de  Thu Jul  5 20:26:59 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 5 Jul 2018 22:26:59 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
Message-ID: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>

Indeed, why use Bool when you can have your own algebraic datatype? Why not 

data Equality = Equal | NotEqual
(==) :: Eq a => a -> a -> Equality

when we have essentially the same for 'compare' already? Why not use

data Result = Success | Failure

as the return type of effectful code? Equality and Result are Booleans with some provenance. 
But wait! Equality does not come with all the nice functions like (||) and (&&), and Failure still does not tell us what exactly went wrong. Maybe a derivable type class IsomorphicToBool could remedy the former problem. For the latter, Haskell has exception monads. One of the things I love about Haskell is that I do not have to use Int as a return type and remember that negative numbers mean failure of some sort, or worse, the return type is Void but some global variable may now contain the error code of the last function call. In some post in haskell-cafe which I am unable to find right now it was mentioned that the GHC source contains many types that are isomorphic but not equal to Bool. 
Does anyone know whether the C and C++ folks are now using more informative structs as return types? 

Cheers,
Olaf

From branimir.maksimovic at gmail.com  Thu Jul  5 20:32:13 2018
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Thu, 5 Jul 2018 22:32:13 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
Message-ID: <86694166-1fcf-4337-9783-ccc29f112cc1@gmail.com>



On 07/05/2018 10:26 PM, Olaf Klinke wrote:
> Indeed, why use Bool when you can have your own algebraic datatype? Why not
>
> data Equality = Equal | NotEqual
> (==) :: Eq a => a -> a -> Equality
>
> when we have essentially the same for 'compare' already? Why not use
>
> data Result = Success | Failure
>
> as the return type of effectful code? Equality and Result are Booleans with some provenance.
> But wait! Equality does not come with all the nice functions like (||) and (&&), and Failure still does not tell us what exactly went wrong. Maybe a derivable type class IsomorphicToBool could remedy the former problem. For the latter, Haskell has exception monads. One of the things I love about Haskell is that I do not have to use Int as a return type and remember that negative numbers mean failure of some sort, or worse, the return type is Void but some global variable may now contain the error code of the last function call. In some post in haskell-cafe which I am unable to find right now it was mentioned that the GHC source contains many types that are isomorphic but not equal to Bool.
> Does anyone know whether the C and C++ folks are now using more informative structs as return types?

Herb Sutter made proposal recently to turn exceptions into ADT's 
(internally).
C++ has std::optional and preferred way to return errors is via 
discriminated unions. I think that main reason
for this is that exceptions are non-deterministic.

Greets, Branimir.

From blaze at ruddy.ru  Thu Jul  5 20:39:01 2018
From: blaze at ruddy.ru (Olga Ershova)
Date: Thu, 5 Jul 2018 16:39:01 -0400
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
Message-ID: <CALujEfh6OPhMujcmesEqhD0eL7cw67pCpsYOFwrb+XMBq1C65g@mail.gmail.com>

On Thu, Jul 5, 2018 at 4:27 PM Olaf Klinke <olf at aatal-apotheke.de> wrote:

> Does anyone know whether the C and C++ folks are now using more
> informative structs as return types?
>

When returning errors, they call them "exceptions".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180705/c72b21dc/attachment.html>

From ietf-dane at dukhovni.org  Thu Jul  5 23:21:22 2018
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 5 Jul 2018 19:21:22 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.3 released
In-Reply-To: <878t6pst91.fsf@smart-cactus.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
 <20180704052744.GJ85096@straasha.imrryr.org>
 <878t6pst91.fsf@smart-cactus.org>
Message-ID: <20180705232122.GR85096@straasha.imrryr.org>

On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:

> > While there's no binary distribution for FreeBSD at haskell.org,
> > as of June 30 there's a FreeBSD ghc-8.4.3 port.  
> >
> >     https://svnweb.freebsd.org/ports/head/lang/ghc/Makefile?view=log
>
> Ahh, great! Thanks for doing this. I'll try to replicate this while
> doing the builds for 8.6.

For the record, in case anyone gets the wrong impression, I am not
one of the port maintainers (who deserve the credit for creating
the port).  I'm just a happy user of the port, which was upgraded
from 8.4.2 to 8.4.3 on Jun 30th.  No issues with either version on
FreeBSD 11.1-RELEASE-p10.

My meagre contribution amounts to reporting success with:

	# cd /usr/ports/lang/ghc
	# make config
	# make package
	# pkg install work/pkg/ghc-8.4.3.txz

The "make config" options include:

    BOOT     Use installed GHC for bootstrapping

which speeds up upgrade builds.

-- 
	Viktor.

From ietf-dane at dukhovni.org  Fri Jul  6 00:13:33 2018
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 5 Jul 2018 20:13:33 -0400
Subject: [Haskell-cafe] GHC FreeBSD memory model (was: 8.4.3 release)
In-Reply-To: <878t6pst91.fsf@smart-cactus.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
 <20180704052744.GJ85096@straasha.imrryr.org>
 <878t6pst91.fsf@smart-cactus.org>
Message-ID: <20180706001333.GT85096@straasha.imrryr.org>

On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:

> We use a much different memory allocation strategy on FreeBSD which
> (AFAIK) does not allow one to reserve address space without also
> committing.

Here's a demo of mapping in a 1TB heap on FreeBSD 11.1, on a machine
with "just" 64GB of RAM and 160GB swap.  I would expect anon memory
mappings to behave similarly on older systems.

    $ cat foo.c
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <sys/mman.h>

    int main(int argc, char **argv)
    {
	size_t heaplen = 1ULL << 40; /* 1TB */
	unsigned char *heap;

	heap = mmap(NULL, heaplen, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
	heap[0] = 'A';
	heap[heaplen-1] = 'z';
	printf ("%p(%zd) %c %c\n", heap, heaplen, heap[0], heap[heaplen-1]);
	sleep(2);
	return 0;
    }

    $ ./foo & sleep 1; ps -o vsz= -o rss= $! ; wait
    [1] 75193
    0x800e00000(1099511627776) A z
    1073750140 2076
    [1]+  Done                    ./foo

    $ printf "0x%8x\n" $(( 1073750140 * 1024 ))
    0x1000081f000

The process gets a contiguous 1TB of anonymous demand-paged zero-filled
memory, and a virtual size of 1TB + 0x81f000 bytes.   The resident
set size is a modest 2MB.

-- 
	Viktor.

From ietf-dane at dukhovni.org  Fri Jul  6 00:50:57 2018
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 5 Jul 2018 20:50:57 -0400
Subject: [Haskell-cafe] GHC FreeBSD memory model (was: 8.4.3 release)
In-Reply-To: <20180706001333.GT85096@straasha.imrryr.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
 <20180704052744.GJ85096@straasha.imrryr.org>
 <878t6pst91.fsf@smart-cactus.org>
 <20180706001333.GT85096@straasha.imrryr.org>
Message-ID: <20180706005057.GU85096@straasha.imrryr.org>

On Thu, Jul 05, 2018 at 08:13:33PM -0400, Viktor Dukhovni wrote:
> On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:
> 
> > We use a much different memory allocation strategy on FreeBSD which
> > (AFAIK) does not allow one to reserve address space without also
> > committing.
> 
> Here's a demo of mapping in a 1TB heap on FreeBSD 11.1, on a machine
> with "just" 64GB of RAM and 160GB swap.  I would expect anon memory
> mappings to behave similarly on older systems.
> 
>     $ cat foo.c
>     #include <stdio.h>
>     #include <stdlib.h>
>     #include <unistd.h>
>     #include <sys/mman.h>
> 
>     int main(int argc, char **argv)
>     {
> 	size_t heaplen = 1ULL << 40; /* 1TB */
> 	unsigned char *heap;
> 
> 	heap = mmap(NULL, heaplen, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
> 	heap[0] = 'A';
> 	heap[heaplen-1] = 'z';
> 	printf ("%p(%zd) %c %c\n", heap, heaplen, heap[0], heap[heaplen-1]);
> 	sleep(2);
> 	return 0;
>     }

I also get essentially the same results with posix_memalign(3):

    #include <stdlib.h>
    #include <stdio.h>
    #include <err.h>
    #include <unistd.h>
    #include <sys/mman.h>

    int main(int argc, char **argv)
    {
	size_t heaplen = 1ULL << 40;
	void *p;
	unsigned char *heap;

	if (posix_memalign(&p, getpagesize(), heaplen) != 0)
	    err(1, "posix_memalign");
	heap = p;
	heap[0] = 'A';
	heap[heaplen-1] = 'z';
	printf ("%p(%zd) %c %c\n", heap, heaplen, heap[0], heap[heaplen-1]);
	sleep(2);
	return 0;
    }

    $ ./foo & sleep 1; ps -o vsz= -o rss= $! ; wait
    [1] 76003
    0x801000000(1099511627776) A z
    1073750140 2080
    [1]+  Done                    ./foo

-- 
	Viktor.

From ben at well-typed.com  Fri Jul  6 02:20:30 2018
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 05 Jul 2018 22:20:30 -0400
Subject: [Haskell-cafe] GHC FreeBSD memory model (was: 8.4.3 release)
In-Reply-To: <20180706001333.GT85096@straasha.imrryr.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
 <20180704052744.GJ85096@straasha.imrryr.org>
 <878t6pst91.fsf@smart-cactus.org>
 <20180706001333.GT85096@straasha.imrryr.org>
Message-ID: <87y3epqf4o.fsf@smart-cactus.org>

Viktor Dukhovni <ietf-dane at dukhovni.org> writes:

> On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:
>
>> We use a much different memory allocation strategy on FreeBSD which
>> (AFAIK) does not allow one to reserve address space without also
>> committing.
>
> Here's a demo of mapping in a 1TB heap on FreeBSD 11.1, on a machine
> with "just" 64GB of RAM and 160GB swap.  I would expect anon memory
> mappings to behave similarly on older systems.
>
Hmm, it's possible this could be fixed fairly easily in that case. The
original reason for disabling the two-step allocator is #12695, where
GHC failed to build due to MAP_NORESERVE being undefined. I had assumed
that this meant that reservation-only mappings weren't defined however
now that I look again at the mmap(2) manpage it looks like I
am probably wrong. MAP_NORESERVE merely flags to the system that swap
space should not be reserved for the mapping.

It looks like this functionality was simply never implemented in FreeBSD
and the flag eventually removed in [1]. However, your example suggests
that the kernel may be doing the right thing by default. It sounds to me
like we could likely remove the assertion enforcing the availability of
MAP_NORESERVE and enable two-step allocation on FreeBSD.

My only question is how one performs reservation-and-commit mappings on
FreeBSD. This is important since without committing any access to the
mapping may crash the program in the case of OOM. Does FreeBSD simply
not provide a way to safely map known-good memory?

Regardless, thanks for bringing this up!

Cheers,

 -Ben


[1] https://reviews.freebsd.org/D848
-------------- 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/20180705/578dd86c/attachment.sig>

From ben at smart-cactus.org  Fri Jul  6 02:31:52 2018
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 05 Jul 2018 22:31:52 -0400
Subject: [Haskell-cafe] GHC FreeBSD memory model (was: 8.4.3 release)
In-Reply-To: <20180706001333.GT85096@straasha.imrryr.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
 <20180704052744.GJ85096@straasha.imrryr.org>
 <878t6pst91.fsf@smart-cactus.org>
 <20180706001333.GT85096@straasha.imrryr.org>
Message-ID: <87tvpdqelq.fsf@smart-cactus.org>

Viktor Dukhovni <ietf-dane at dukhovni.org> writes:

> On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:
>
>> We use a much different memory allocation strategy on FreeBSD which
>> (AFAIK) does not allow one to reserve address space without also
>> committing.
>
> Here's a demo of mapping in a 1TB heap on FreeBSD 11.1, on a machine
> with "just" 64GB of RAM and 160GB swap.  I would expect anon memory
> mappings to behave similarly on older systems.
>
I have opened #15348 [1] to track the issue.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/ticket/15348
-------------- 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/20180705/335b19c4/attachment.sig>

From ietf-dane at dukhovni.org  Fri Jul  6 05:15:12 2018
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 6 Jul 2018 01:15:12 -0400
Subject: [Haskell-cafe] GHC FreeBSD memory model (was: 8.4.3 release)
In-Reply-To: <87y3epqf4o.fsf@smart-cactus.org>
References: <87lgc2kyyx.fsf@smart-cactus.org>
 <20180704052744.GJ85096@straasha.imrryr.org>
 <878t6pst91.fsf@smart-cactus.org>
 <20180706001333.GT85096@straasha.imrryr.org>
 <87y3epqf4o.fsf@smart-cactus.org>
Message-ID: <20180706051512.GW85096@straasha.imrryr.org>

On Thu, Jul 05, 2018 at 10:20:30PM -0400, Ben Gamari wrote:

> Hmm, it's possible this could be fixed fairly easily in that case. The
> original reason for disabling the two-step allocator is #12695, where
> GHC failed to build due to MAP_NORESERVE being undefined. I had assumed
> that this meant that reservation-only mappings weren't defined however
> now that I look again at the mmap(2) manpage it looks like I
> am probably wrong. MAP_NORESERVE merely flags to the system that swap
> space should not be reserved for the mapping.

Right, absence of MAP_NORESERVE does not mean that all the pages
will be reserved in advance.  However, the VM behaviour may be
configuration-dependent:

    https://wiki.freebsd.org/SystemTuning#SYSCTL_TUNING

    The vm.overcommit sysctl defines the overcommit behaviour of
    the vm subsystem. The virtual memory system always does accounting
    of the swap space reservation, both total for system and per-user.
    Corresponding values are available through sysctl vm.swap_total,
    that gives the total bytes available for swapping, and
    vm.swap_reserved, that gives number of bytes that may be needed
    to back all currently allocated anonymous memory. Setting bit
    0 of the vm.overcommit sysctl causes the virtual memory system
    to return failure to the process when allocation of memory
    causes vm.swap_reserved to exceed vm.swap_total. Bit 1 of the
    sysctl enforces RLIMIT_SWAP limit (see getrlimit(2)). Root is
    exempt from this limit. Bit 2 allows to count most of the
    physical memory as allocatable, except wired and free reserved
    pages (accounted by vm.stats.vm.v_free_target and
    vm.stats.vm.v_wire_count sysctls, respectively).

I have the default vm.overcommmit setting:

    $ sysctl vm.overcommit
    vm.overcommit: 0

in which "bit 0" is off, so processes can allocate more anonymous
memory than available swap.  With vm.overcommit=1 the 1TB mmap()
fails (surprisingly EINVAL rather than ENOMEM), while a 1MB mmap()
succeeds.

> My only question is how one performs reservation-and-commit mappings on
> FreeBSD. This is important since without committing any access to the
> mapping may crash the program in the case of OOM. Does FreeBSD simply
> not provide a way to safely map known-good memory?

With vm.overcommit=0, I don't off-hand know of a way to map anonymous
memory that's guaranteed to not later segfault on first access.

One way to avoid issues when vm.overcommit=1 is to use the MAP_GUARD
flag to reserve a mapping without allocating any pages.  And then
(as needed) explicitly map pages within the reserved range.

    $ cat foo.c
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <err.h>
    #include <sys/mman.h>

    int main(int argc, char **argv)
    {
	size_t heapmax = 1ULL << 40; /* 1TB */
	size_t heaplen = 1ULL << 20; /* 1MB */
	unsigned char *heap;
	unsigned char *heap2;

	/* Reserve 1 TB of address-space */
	heap = mmap(NULL, heapmax, PROT_NONE, MAP_GUARD, -1, 0);
	if (heap == MAP_FAILED)
	    err(1, "mmap");
	printf ("%p(%zd)\n", heap, heapmax);

	/* Allocate last 1MB of the 1TB address-space */
	heap2 = &heap[heapmax - heaplen];
	heap2 = mmap(heap2, heaplen, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE|MAP_FIXED, -1, 0);
	if (heap2 == MAP_FAILED)
	    err(1, "mmap");

	/* Use the allocated space */
	heap2[0] = 'A';
	heap2[heaplen-1] = 'z';
	printf ("%p(%zd) %c %c\n", heap, heaplen, heap2[0], heap2[heaplen-1]);
	sleep(20);
	return 0;
    }

    $ ./foo & sleep 1; pid=$! ; cat /proc/$pid/map; ps -o vsz= -o rss= $pid ; wait
    [1] 84867
    0x800e00000(1099511627776)
    0x800e00000(1048576) A z
    0x400000 0x401000 1 0 0xfffff80f04f75780 r-x 2 0 0x9210 COW NC vnode /tmp/foo NCH -1
    0x600000 0x601000 1 0 0xfffff80b872ed1e0 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x800600000 0x800621000 33 0 0xfffff80011df3780 r-x 173 76 0x1000 COW NC vnode /libexec/ld-elf.so.1 NCH -1
    0x800621000 0x800642000 22 0 0xfffff80b872ed690 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x800820000 0x800821000 1 0 0xfffff80d348e3c30 rw- 1 0 0x3000 COW NNC vnode /libexec/ld-elf.so.1 CH 1001
    0x800821000 0x800822000 1 0 0xfffff80f432df690 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x800822000 0x8009b4000 402 0 0xfffff8000d720e10 r-x 173 76 0x1000 COW NC vnode /lib/libc.so.7 NCH -1
    0x8009b4000 0x800bb4000 0 0 0xfffff8035779ea50 --- 1 0 0x2000 NCOW NNC default - NCH -1
    0x800bb4000 0x800bc0000 12 0 0xfffff8084feace10 rw- 1 0 0x3000 COW NNC vnode /lib/libc.so.7 CH 1001
    0x800bc0000 0x800bda000 5 0 0xfffff80682dcfc30 rw- 2 0 0x3000 NCOW NNC default - CH 1001
    0x800c00000 0x800e00000 9 0 0xfffff80682dcfc30 rw- 2 0 0x3000 NCOW NNC default - CH 1001
    0x800e00000 0x10800d00000 0 0 0 --- 0 0 0x0 COW NC none - NCH -1
    0x10800d00000 0x10800e00000 2 0 0xfffff8018644c1e0 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x10800e00000 0x10801000000 6 0 0xfffff80b76b20d20 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x7fffdffff000 0x7ffffffdf000 0 0 0 --- 0 0 0x0 NCOW NNC none - NCH -1
    0x7ffffffdf000 0x7ffffffff000 3 0 0xfffff80c6b72c1e0 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x7ffffffff000 0x800000000000 0 0 0xfffff800117b6000 r-x 100 0 0x6 NCOW NNC default - NCH -1
    9340 2072
    [1]+  Done                    ./foo

Note the 1TB-1MB hole in the process memory map:

    0x800e00000 0x10800d00000 0 0 0 --- 0 0 0x0 COW NC none - NCH -1

followed by a 1MB mapping:

    0x10800d00000 0x10800e00000 2 0 0xfffff8018644c1e0 rw- 1 0 0x3000 NCOW NNC default - CH 1001

Note also that the "vsz" does not include the hole.  So we are
guaranteed exclusive use of a virtual address range, but it is not
initially allocated, and later allocations can proceed incrementally.
Those later allocation may or may not be subject to overcommit
with OOM segfaults depending on vm.overcommit.

-- 
	Viktor.

From aquagnu at gmail.com  Fri Jul  6 05:27:52 2018
From: aquagnu at gmail.com (PY)
Date: Fri, 6 Jul 2018 08:27:52 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <2a0a052c-2e68-ec3e-168b-9ecbbd4f307c@durchholz.org>
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
 <2a0a052c-2e68-ec3e-168b-9ecbbd4f307c@durchholz.org>
Message-ID: <073310ea-7182-c653-55ad-722b41f4618e@gmail.com>

Hello Joachim!

Very nice answer and explanations! So:

05.07.2018 21:48, Joachim Durchholz wrote:
> > Is it true, that bool is "bad" type?
>>
>> As I understand arguments of the post, Bool is bad because: 1) you
>> don't know what does True/False mean  2) after comparison you get bit
>> (!) only but then you may need to  "recover" the comparing value
>> which was "shrink" to bit already.
>
> Sure. That's a valid point the post is making.
> So you shouldn't move the creation of a Boolean too far away from its 
> consumption.
>
> The same argument holds for any numeric data type; if you pass around 
> Floats, you quickly lose knowledge whether it's yards or meters (that 
> kind of problem actually made an interplanetary probe miss its 
> destination planet).

Yes! And I can not imagine Bool which is not bound to some meaningful 
named variable (flag) like "enabled", "isClosed", etc. Bool is always 
flag or a result of predicate.

>> Really, what does True/False mean? How to find semantic of True? It's
>>  very simple, because there is A) contract/interface which interprets
>>  True/False and also B) there is a help from science.
>
> This works as long as the contract is easily deducible from the 
> context in the program.
> I.e. if you have a file-is-open function, then the contract of that 
> function says that the result is True or False, and as long as the 
> value from the function is kept in contexts where it's clear that we 
> are talking about a file-open status, that's good enough.
> Things can get nasty when you start moving a file-is-open Boolean into 
> a "valid" attribute. You (as a human reader) lose the information that 
> the value is related to a file-open status.

Yes, makes sense. What is difficult to me, to imagine true/false itself, 
without predicate or flag. So, it's difficult to me to imagine bool 
which looses its original sense. It's the same as to forget the sense of 
Right or Left. Actually, what does Left mean? Success result? Or 
something else? Totally depends on context, on semantic. You can encode 
good result as "Left Smth" and failure as "Right smth". And only 
implementation of ">>=" will be problem in such inversion. But ML (in 
the original article) has not ">>=", so no way to force you to keep in 
mind success-result == "Right Smth". This was the reason why I made 
accent to monadic operations.

> Personally, I avoid the True/False terminology; it (mis)applies the 
> concept of "desirable" or "truth", and boolean values aren't about 
> desirability or truth.
>
> Just assume the values are "Yes" and "No"; actually this is exactly 
> the issue the blog post is really talking about: "Yes" and "No" are 
> answers, but answers are useful only as long as you know the question.
> (Reminds me of "42" in the Douglas Adams fiction: the supercomputer 
> gave that as the ultimate answer, now they are building a larger 
> supercomputer to find out what the question to that answer is.)
Yes, you are absolutely right here too. So I was talking about 
contract/interface: in Bash the value of "truth" is 0, the value of 
"false" is multiple values. In Haskell: only True and False. But with 
BoolValue and Boolean instances we can map Bash case to Haskell case.

>> B) The help from science.
>
> Science is not too relevant here.
> The blog post is talking about maintainability, i.e. programmer 
> psychology.
Yes, I see now that it's more relevant to psychology :)  When I talked 
about science, I mean that I think not "file-open -> {True|False}"  but 
"openedFile -> {achieved|not achieved}". For me, action is already 
predicate. So when we map functional style to declarative style we must 
treat Bool in this way. In Prolog is don't need to separate predicate 
and its result (Boolean - is some variable) but I'm using predicate 
instead of Bool. May be problem here is that FP is imperative and not 
declarative.


From aquagnu at gmail.com  Fri Jul  6 05:33:55 2018
From: aquagnu at gmail.com (PY)
Date: Fri, 6 Jul 2018 08:33:55 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <55e21eb7-0e6c-699d-05fa-51b7a5eef773@chreekat.net>
References: <00cce4b7-099a-f381-7128-735ff9ea457f@gmail.com>
 <jwv7em9hij0.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 <c22ceac6-c145-cc93-5aff-d49dec5852ed@gmail.com>
 <55e21eb7-0e6c-699d-05fa-51b7a5eef773@chreekat.net>
Message-ID: <a223f064-4a3e-5761-3e5c-ed0a70cb55f2@gmail.com>

Hello Bryan!

IMHO a discrepancy arises from the to different flows:

  * With pattern matching we create 2 branches with *data flow* (typical
    for ML):

     1. Result exists - to be processed (head of list)
     2. Result does not exist, nothing to process (no head at whole)

  * With boolean testing we create 2 branches in *logical flow* (typical
    for Prolog):

     1. Predicate is true and further sequential processing is possible
     2. Predicate is false and other part of the sentence is false too
        (no more further processing)

So, my misunderstanding is that I try to think about ML/Haskell as about 
declarative languages, but they are imperative.

05.07.2018 20:51, Bryan Richter wrote:
> Happily, all of this has nothing to do with monads or Haskell's
> special syntax for monads. :)
>
> I would not call it static-types fanaticism, but rather,
> pattern-matching fanaticism. To me, "boolean blindness" is a cute way
> to describe how this:
>
>      -- | Sum the first two ints of a list, if possible
>      foo1 :: [Int] -> Maybe Int
>      foo1 (x:y:_) = Just (x + y)
>      foo1 [x] = Just x
>      foo1 [] = Nothing
>
> is better than this:
>
>      -- | Same thing, but with "blind bools"
>      foo2 :: [Int] -> Maybe Int
>      foo2 xs =
>          if length x >= 2
>              then Just ((x!!1) + (x!!2))
>              else if length x == 1
>                  then Just (x!!1)
>                  else Nothing
>
> NB: I already had to correct one mistake in that second code while
> writing it, and there may be others (I forget if it's (!!) or (!), and
> I also forget if it's 0-based or 1-based).
>
> The first is a description of what I want. It is correct by
> construction.
>
> The second requires converting the description of what I want (sum of
> the first two ints) into a description of how it is computed, with
> steps like "find the length and compare it to 2".
>
> By using pattern matching, I get both a guarantee of the structure I
> need, as well as information from within the structure at the same
> time. With an operational description, I have to do it in separate
> steps.
>
> To me, that's the crux of boolean blindness: Use pattern matching
> whenever possible!
>
>
> On 07/05/2018 11:04 AM, PY wrote:
>> So, the problem is that test of emptiness does not force you to something right. And possible errors are:
>>
>>      if empty:
>>        # do if NOT empty - BUG!
>>      else:
>>        # do if EMPTY - BUG TOO!
>>
>>      or
>>
>>      # do if NOT empty - BUG!
>>      if NOT empty:
>>        # now nothing or old "do if NOT EMPTY"
>>
>>
>> OK, I understand it. But how is it related to Booleans? :) Sure, if you use Maybe or Either you are forced with nature of ">>=": it cuts off incorrect branches. With if-then - it does not. But it's not
>> related to Bool: Bool is result for predicates. Maybe/Either forces you with magic operation ">>=" (which is hidden by do-sugar). Bool does not force you - right. But it's problem of Haskell
>> implementation. For example, Prolog "forces" you:
>>
>> Haskell forces you in monad "do":
>>    do
>>      someInt <- someMaybe
>>      -- will not be executed if someMaybe is Nothing
>>
>> Prolog forces you too but on success/fail (Boolean?):
>>    someGoal, anotherGoal   % anotherGoal will not be executed if someGoal is False
>>
>> Haskell adds only "bool" function which is close to ">>=" in terms of it hides semantic of right bool's processing, avoid those possible errors. If you will use "bool" anywhere when you use Bool as
>> result - all will be fine, or? Sure, you can move "head" usage out of "bool" but you will get empty "bool"s argument. So, IMHO examples of problem with booleans is not related to Bool type at whole,
>> but related to problem that Bool has kind * but not * -> * to be processed in monadic style (and to has needed  ">>=" semantic to force you).
>>
>> OK, but original article was not about Haskell's monads, but about Bool in general :)    Also what I can't understand: if we will think in such manner does it mean that "if..test" construct is
>> "boring"/"blindness" (excuse my English:) at whole? And all predicates must be removed from the language? What will happen to `filter` function without predicates? And no way to avoid "if..else"
>> construct and predicates functions.
>>
>> As for me, this question is related to static-types fanaticism and "How many angels could dance on the head of a pin". Example with "head" is totally incorrect - it can deconstruct list and no need to
>> predicate function. But what I should do with isSpace, isLower, etc? How to use predicates at whole? :)   To map   a -> Bool   to   a -> Maybe a  ?
>> What about function which returns IO Bool? Action which can ends with non-critical failure (and need optionally logging, for example) ?
>>
>>
>> 05.07.2018 17:27, Stefan Monnier wrote:
>>>> There is an opinion that Bool type has problems. It's "dangerous", because
>>>> it's not good to be used as flag for success/fail result. I read this post:
>>>> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and was
>>>> shocked. How popular is such opinion? Is it true, that bool is "bad" type?
>>> To me the argument boils down to the `head` case mentioned by Alex.
>>>
>>> Most programming languages force you to write code like
>>>
>>>      if List.empty l then
>>>          ...
>>>      else
>>>          ... x = List.head l ...
>>>
>>> where the problem is that the fact that the List.head call will find the
>>> list non-empty is not obvious (in the sense that it requires reasoning).
>>>
>>> In contrast
>>>
>>>      case l
>>>      | nil => ...
>>>      | cons x xs => ...
>>>
>>> makes it trivially obvious that `x` is extracted from a non-empty list
>>> without any reasoning needed at all.
>>>
>>>
>>>          Stefan
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180706/439c25a1/attachment-0001.html>

From aquagnu at gmail.com  Fri Jul  6 05:39:48 2018
From: aquagnu at gmail.com (PY)
Date: Fri, 6 Jul 2018 08:39:48 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
Message-ID: <71e7165f-b707-113b-504b-679c3aa247c2@gmail.com>

Hello, Olaf! It makes sense absolutely and totally! Even more, I'm using 
BoolValue and Boolean (from AC-Boolean package) instances already. And 
IMHO it's right way to proceed with this. Such way allows to treat Unix 
shell exit codes as "success", "failure" even (but in the case with them 
it will be homomorphism, which is interesting case, because in logic we 
have "base" values {0, 1} for classical logic, [0...1] for fuzzy logic, 
this is some kind of logical base too - how is it called?)


05.07.2018 23:26, Olaf Klinke wrote:
> Indeed, why use Bool when you can have your own algebraic datatype? Why not
>
> data Equality = Equal | NotEqual
> (==) :: Eq a => a -> a -> Equality
>
> when we have essentially the same for 'compare' already? Why not use
>
> data Result = Success | Failure
>
> as the return type of effectful code? Equality and Result are Booleans with some provenance.
> But wait! Equality does not come with all the nice functions like (||) and (&&), and Failure still does not tell us what exactly went wrong. Maybe a derivable type class IsomorphicToBool could remedy the former problem. For the latter, Haskell has exception monads. One of the things I love about Haskell is that I do not have to use Int as a return type and remember that negative numbers mean failure of some sort, or worse, the return type is Void but some global variable may now contain the error code of the last function call. In some post in haskell-cafe which I am unable to find right now it was mentioned that the GHC source contains many types that are isomorphic but not equal to Bool.
> Does anyone know whether the C and C++ folks are now using more informative structs as return types?
>
> Cheers,
> Olaf


From alexandre at moine.me  Fri Jul  6 11:16:45 2018
From: alexandre at moine.me (Alexandre Moine)
Date: Fri, 06 Jul 2018 13:16:45 +0200
Subject: [Haskell-cafe] [GSoC 2018] Benchmarking Haskell graph libraries
Message-ID: <845e476b6723731ae06823869b462dad@moine.me>

[ Results are here: 
https://github.com/haskell-perf/graphs/tree/master/results/ ]

Hi,

I am french 2nd year student in maths and computer sciences and I am 
running a {Google,Haskell} Summer of Code now.

One of my goals is to write a benchmarking suite for graphs libraries in 
Haskell (Fgl, Alga, Containers and Hash-Graph) and I reached a state 
where I can produce reasonable numbers.

If you are interested, I have wrote a little blog article explaining the 
results I obtained: 
https://blog.nyarlathotep.one/2018/07/benchmarking-haskell-graph-libraries/

Feel free to comment or to send feedback on the Github :)

-- 
Alexandre Moine

From olf at aatal-apotheke.de  Fri Jul  6 20:04:43 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Fri, 6 Jul 2018 22:04:43 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <CALujEfh6OPhMujcmesEqhD0eL7cw67pCpsYOFwrb+XMBq1C65g@mail.gmail.com>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <CALujEfh6OPhMujcmesEqhD0eL7cw67pCpsYOFwrb+XMBq1C65g@mail.gmail.com>
Message-ID: <2BD6E857-38C6-429C-8C50-49B435E400F0@aatal-apotheke.de>


> Am 05.07.2018 um 22:39 schrieb Olga Ershova <blaze at ruddy.ru>:
> 
> 
> 
> On Thu, Jul 5, 2018 at 4:27 PM Olaf Klinke <olf at aatal-apotheke.de> wrote:
> Does anyone know whether the C and C++ folks are now using more informative structs as return types? 
>  
> When returning errors, they call them "exceptions". 
Quite so. One might say that the equivalent of try...catch blocks in Haskell is the pattern match

case (action :: Either err a) of
  Right result -> ...
  Left err -> deal_with err

But what keeps bugging me about exceptions is this: When working with libraries having nested dependencies, is there a way of knowing the complete set of exceptions that might be thrown by a block of code? It is generally considered bad style to write a catch-all. Instead, only catch the exceptions you know how to deal with. But if I don't know what can be thrown, then I can not make my code bullet-proof. The explicit return type seems the clearer approach to this problem. 

Olaf

From jo at durchholz.org  Fri Jul  6 20:35:57 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 6 Jul 2018 22:35:57 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <2BD6E857-38C6-429C-8C50-49B435E400F0@aatal-apotheke.de>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <CALujEfh6OPhMujcmesEqhD0eL7cw67pCpsYOFwrb+XMBq1C65g@mail.gmail.com>
 <2BD6E857-38C6-429C-8C50-49B435E400F0@aatal-apotheke.de>
Message-ID: <662dfc9a-e489-39b6-e6c8-b87eb711947e@durchholz.org>

Am 06.07.2018 um 22:04 schrieb Olaf Klinke:
> 
>> Am 05.07.2018 um 22:39 schrieb Olga Ershova <blaze at ruddy.ru>:
>>
>>
>>
>> On Thu, Jul 5, 2018 at 4:27 PM Olaf Klinke <olf at aatal-apotheke.de> wrote:
>> Does anyone know whether the C and C++ folks are now using more informative structs as return types?
>>   
>> When returning errors, they call them "exceptions".

True but not really.
C does not have exceptions, so C APIs have always been returning 
discriminated unions.
C++ exceptions tend to be used in different ways, sometimes like Olga 
says, sometimes differently.

> Quite so. One might say that the equivalent of try...catch blocks in Haskell is the pattern match
> 
> case (action :: Either err a) of
>    Right result -> ...
>    Left err -> deal_with err

That's kind of how "checked exceptions" in Java work: You declare them 
in the function signature.

> But what keeps bugging me about exceptions is this: When working with libraries having nested dependencies, is there a way of knowing the complete set of exceptions that might be thrown by a block of code?

So for checked exceptions you know what may go up.
I.e. it's really equivalent to pattern matching.

"Unchecked" exceptions are not declared.
I.e. you can use them as untyped pattern match.

> It is generally considered bad style to write a catch-all. Instead, only catch the exceptions you know how to deal with. But if I don't know
what can be thrown, then I can not make my code bullet-proof. The
explicit return type seems the clearer approach to this problem.

Not generally actually.
At the top level, you do indeed catch all exceptions, as a signal that 
the called computation failed.
Typical reactions to that are:
- Abort the program.
- Log the error and wait for the next request (background programs).
- Report an error message to the user (interactive programs).
- Retry (a useful strategy if nondeterminism is involved).
- Fall back to a simpler strategy (for really large software systems).
Some design philosophies do this not just at the top level, but at each 
intermediate level. Some systems are built using "monitor layers", 
modules that do this kind of subtask monitoring and report an exception 
only if retrying or falling back didn't work.

Regards,
Jo

From aquagnu at gmail.com  Sat Jul  7 05:15:12 2018
From: aquagnu at gmail.com (Paul)
Date: Sat, 7 Jul 2018 08:15:12 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <662dfc9a-e489-39b6-e6c8-b87eb711947e@durchholz.org>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <CALujEfh6OPhMujcmesEqhD0eL7cw67pCpsYOFwrb+XMBq1C65g@mail.gmail.com>
 <2BD6E857-38C6-429C-8C50-49B435E400F0@aatal-apotheke.de>
 <662dfc9a-e489-39b6-e6c8-b87eb711947e@durchholz.org>
Message-ID: <5b404c5c.1c69fb81.d9341.d99c@mx.google.com>

By the way, there are a lot of articles why checked exceptions are bad design (more problems than benefit).

More interesting for me is this snippet:

case (action :: Either err a) of
   Right result -> ...
   Left err -> deal_with err

Somebody says me that to use Bool in such way is “not safe” because no way to know what does “True” returning from “action” mean. Success or failure? But with some ADT (Success|Failure) code is more Haskellish and safe.

But is it true? We are talking about semantics, not type-safety because type-checker passes both cases (positive branch under False/Failure, negative branch under True/Success). But the same with Right/Left: nothing says you to use Right for positive and Left for error case. Is it true?

Bool is algebra <1, 0, +, *> or more familiar <T, F, |, &> (let’s ignore other operations). We are talking about semantics and not TYPE safety. Semantic is not here <T, F>, semantic is here: <|, &>. You can use Right for negative branch processing if you have only types. Type system can not save you from such “bug”. But operational model – can. Semantic of Either is here: < (>>=), return, fail >. Operation “>>=” forces you to treat Right for positive case (otherwise, your code mixing with other Eithers will have strange behaviour). The same with Bool, short-circuit operations describe semantic and force you to use True for happy-ways:

e1 || e2

e2 will be evaluated only if e1 leads to false. In Bash: command e2 will be executed only if e1 fails (no False, any number =/= 0). The semantic is defining by operations, not types (operations “interpret” values and are linked with semantics), and they are similar in case of Either and Bool. So, Bool type is not less safe then Either. Changing of convenient leads to the same problems in both cases: strange behaviour.

Problem with Haskell is that it’s imperative and not declarative language. Haskell can not work with “behaviour”, behaviour can not be “lifted” to type system which lives at compile-time only. If type-checker passes – all is good. So, “pure $ print 1” is right in Haskell but mostly it’s error. IMHO root of the problem is more deep than talking about types.

The root of the problem is that imperative nature of Haskell leads to missing term “evaluation to something”. Haskell program is not evaluated expression and in the same as in Java or C: it is IO action. But in Prolog every piece of code is evaluated to TRUTH or to FALSE. Each sentence is a goal which can be achieved and becomes a fact or can not be – and becomes lie. So, if you inverse semantic in Haskell – program is compiled although with strange behaviour but in Prolog program become lie. Prolog evaluation model has clean definition in run-time too, not only at compile-time. Execution of Prolog program is a CHECK: is it truth or lie? Strange behaviour of Haskell == lie in Prolog (at run-time). You will get answer “No.” (for example). It’s dialog with MU-TH-UR 6000 or HAL-9000 😊 not execution of some action.


From: Joachim Durchholz
Sent: 6 июля 2018 г. 23:36
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Bool is not...safe?!

Am 06.07.2018 um 22:04 schrieb Olaf Klinke:
> 
>> Am 05.07.2018 um 22:39 schrieb Olga Ershova <blaze at ruddy.ru>:
>>
>>
>>
>> On Thu, Jul 5, 2018 at 4:27 PM Olaf Klinke <olf at aatal-apotheke.de> wrote:
>> Does anyone know whether the C and C++ folks are now using more informative structs as return types?
>>   
>> When returning errors, they call them "exceptions".

True but not really.
C does not have exceptions, so C APIs have always been returning 
discriminated unions.
C++ exceptions tend to be used in different ways, sometimes like Olga 
says, sometimes differently.

> Quite so. One might say that the equivalent of try...catch blocks in Haskell is the pattern match
> 
> case (action :: Either err a) of
>    Right result -> ...
>    Left err -> deal_with err

That's kind of how "checked exceptions" in Java work: You declare them 
in the function signature.

> But what keeps bugging me about exceptions is this: When working with libraries having nested dependencies, is there a way of knowing the complete set of exceptions that might be thrown by a block of code?

So for checked exceptions you know what may go up.
I.e. it's really equivalent to pattern matching.

"Unchecked" exceptions are not declared.
I.e. you can use them as untyped pattern match.

> It is generally considered bad style to write a catch-all. Instead, only catch the exceptions you know how to deal with. But if I don't know
what can be thrown, then I can not make my code bullet-proof. The
explicit return type seems the clearer approach to this problem.

Not generally actually.
At the top level, you do indeed catch all exceptions, as a signal that 
the called computation failed.
Typical reactions to that are:
- Abort the program.
- Log the error and wait for the next request (background programs).
- Report an error message to the user (interactive programs).
- Retry (a useful strategy if nondeterminism is involved).
- Fall back to a simpler strategy (for really large software systems).
Some design philosophies do this not just at the top level, but at each 
intermediate level. Some systems are built using "monitor layers", 
modules that do this kind of subtask monitoring and report an exception 
only if retrying or falling back didn't work.

Regards,
Jo
_______________________________________________
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/20180707/c5161eb6/attachment.html>

From olf at aatal-apotheke.de  Sat Jul  7 05:34:40 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 7 Jul 2018 07:34:40 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <71e7165f-b707-113b-504b-679c3aa247c2@gmail.com>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <71e7165f-b707-113b-504b-679c3aa247c2@gmail.com>
Message-ID: <E59326C5-4F0B-49A0-94D4-A4C1B2BBDECE@aatal-apotheke.de>


> Am 06.07.2018 um 07:39 schrieb PY <aquagnu at gmail.com>:
> 
> Hello, Olaf! It makes sense absolutely and totally! Even more, I'm using BoolValue and Boolean (from AC-Boolean package) instances already. And IMHO it's right way to proceed with this.
AC-Boolean ist precisely my intention when I thought about IsomorphicToBool. Of course by defining an instance you force upon everyone else which value you consider to be 'True'. 

> Such way allows to treat Unix shell exit codes as "success", "failure" even (but in the case with them it will be homomorphism, which is interesting case, because in logic we have "base" values {0, 1} for classical logic, [0...1] for fuzzy logic, this is some kind of logical base too - how is it called?)
You might be interested in another kind of Boolean-like types: Commutative monads. A monad is called commutative if the order of actions does not matter, i.e. if the following always holds. 
do { x <- mx; y <- my; return f x y} == do {y <- my; x <- mx; return f x y}
For example, Maybe is commutative, and [] is up to permutation. For such a monad m consider the type m (). Observe that Maybe () is isomorphic to Bool. Can we derive some operations generically? Indeed, 

true = return ()
(&&) = liftM2 const
(||) = mplus
false = mzero

Notice that this is different from AC-Boolean, where false = return false. The monad being commutative makes the binary operations commutative, as required for proper logic. 

For 'not', we need to work a little harder. A monadic implementation of 'not' means that you can pattern match on mzero, which is not baked into any monad type class. But having a monadic 'not' makes the monad really interesting. If you have a probability monad, for instance, then 'not' (or rather implication, of which 'not' is a special case) provides conditional probabilities. 

Olaf
> 
> 
> 05.07.2018 23:26, Olaf Klinke wrote:
>> Indeed, why use Bool when you can have your own algebraic datatype? Why not
>> 
>> data Equality = Equal | NotEqual
>> (==) :: Eq a => a -> a -> Equality
>> 
>> when we have essentially the same for 'compare' already? Why not use
>> 
>> data Result = Success | Failure
>> 
>> as the return type of effectful code? Equality and Result are Booleans with some provenance.
>> But wait! Equality does not come with all the nice functions like (||) and (&&), and Failure still does not tell us what exactly went wrong. Maybe a derivable type class IsomorphicToBool could remedy the former problem. For the latter, Haskell has exception monads. One of the things I love about Haskell is that I do not have to use Int as a return type and remember that negative numbers mean failure of some sort, or worse, the return type is Void but some global variable may now contain the error code of the last function call. In some post in haskell-cafe which I am unable to find right now it was mentioned that the GHC source contains many types that are isomorphic but not equal to Bool.
>> Does anyone know whether the C and C++ folks are now using more informative structs as return types?
>> 
>> Cheers,
>> Olaf
> 


From jo at durchholz.org  Sat Jul  7 08:17:07 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Sat, 7 Jul 2018 10:17:07 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <5b404c5c.1c69fb81.d9341.d99c@mx.google.com>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <CALujEfh6OPhMujcmesEqhD0eL7cw67pCpsYOFwrb+XMBq1C65g@mail.gmail.com>
 <2BD6E857-38C6-429C-8C50-49B435E400F0@aatal-apotheke.de>
 <662dfc9a-e489-39b6-e6c8-b87eb711947e@durchholz.org>
 <5b404c5c.1c69fb81.d9341.d99c@mx.google.com>
Message-ID: <cc861580-8b00-bad8-a1d1-787a2ce9a2c5@durchholz.org>

Am 07.07.2018 um 07:15 schrieb Paul:
> By the way, there are a lot of articles why checked exceptions are bad 
> design (more problems than benefit).

That's because exceptions disrupt control flow.
If they're used as an alternative to pattern matching, i.e. thrown only 
in tail position and always either fully handled or rethrown unchanged, 
then they're fine.

I.e. checked exceptions are bad because they make it easy to construct 
bad design. Unchecked exceptions can be abused in the same way but there 
seem to be psychological reasons why this isn't done so often.

> More interesting for me is this snippet:
> 
> case (action :: Either err a) of
>     Right result -> ...
>     Left err -> deal_with err
> 
> Somebody says me that to use Bool in such way is “not safe” because no 
> way to know what does “True” returning from “action” mean. Success or 
> failure? But with some ADT (Success|Failure) code is more Haskellish and 
> safe.

Terminology N.B.: (Success|Failure) is not an abstract data type (ADT). 
It's pretty much the opposite of abstract.

> But is it true? We are talking about semantics, not type-safety because 
> type-checker passes both cases (positive branch under False/Failure, 
> negative branch under True/Success). But the same with Right/Left: 
> nothing says you to use Right for positive and Left for error case. Is 
> it true?

There's no good way to use Bool as the type of action, so the point is moot.
Of course you can reconstruct action's type to be a struct consisting of 
a Bool, a SuccessResult, and a FailureResult, but that's just awkward so 
nobody is doing this.

> Bool is algebra <1, 0, +, *>

Let me repeat: the algebraic and mathematical properties of Bool are 
irrelevant.

> Problem with Haskell is that it’s imperative and not declarative 
> language.

Haskell isn't imperative.
I.e. it matches almost none of the definitions for "imperative" that I 
have ever seen.
It matches a substantial percentage of the definitions for "declarative" 
actually, but not enough of them that I'd instinctively say it is really 
declarative - others with a different set of definitions encountered may 
feel differently.

> The root of the problem is that imperative nature of Haskell leads to 
> missing term “evaluation to something”.

The most compact definition of "imperative" that I have seen is 
"computation progresses by applying side effects".
By that definition, the ability to distinguish evaluated and unevaluated 
expressions is irrelevant.

 > Haskell program is not evaluated
> expression and in the same as in Java or C: it is IO action. But in 
> Prolog every piece of code is evaluated to TRUTH or to FALSE. Each 
> sentence is a goal which can be achieved and becomes a fact or can not 
> be – and becomes lie.

Wrong terminology. Nothing in a computer is a lie.

Prolog works by turning stuff into either tautologies or contradictions.
A lie is something entirely different: a statement that intentionally 
contradicts reality. Programming language semantics does not have 
intention; programs may have state that matches or contradicts reality, 
but take this message which isn't a lie but still does not match any 
reality because no sheet of paper with these glyphs ever existed (there 
may be in the future if somebody prints this message, but that doesn't 
turn this message from a lie into a truth).

Please, get your terminology right. If you keep working with "almost 
right" terminology in your head, you will continuously "almost 
misunderstand" whatever you read, leading you to conclusions which are 
almost right but take a huge amount of effort to clean up. People who 
know the concepts and the terminology will find it too tiresome to talk 
with you because it is all about educating you (which is not the right 
level to talk with a person anyway), and will eventually drop out of 
discussions with you; the only persons who talk to you will be those who 
happen to have similarly vague ideas, placing you in an echo chamber of 
ideas that lead nowhere because everything is subtly wrong.
Just saying. I'm not going to force anything on you - but I find that 
this message is entirely about terminology correction and almost nothing 
about the topics that really interest you, which means it's been mostly 
a waste of time of both of us.

Regards,
Jo

From monkleyon at gmail.com  Sat Jul  7 12:10:16 2018
From: monkleyon at gmail.com (MarLinn)
Date: Sat, 7 Jul 2018 14:10:16 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <E59326C5-4F0B-49A0-94D4-A4C1B2BBDECE@aatal-apotheke.de>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <71e7165f-b707-113b-504b-679c3aa247c2@gmail.com>
 <E59326C5-4F0B-49A0-94D4-A4C1B2BBDECE@aatal-apotheke.de>
Message-ID: <05d0abfb-74ed-967e-ae1f-c00cb6858018@gmail.com>


> You might be interested in another kind of Boolean-like types: Commutative monads. A monad is called commutative if the order of actions does not matter, i.e. if the following always holds.
> do { x <- mx; y <- my; return f x y} == do {y <- my; x <- mx; return f x y}
> For example, Maybe is commutative, and [] is up to permutation. For such a monad m consider the type m (). Observe that Maybe () is isomorphic to Bool. Can we derive some operations generically? Indeed,
>
> true = return ()
> (&&) = liftM2 const
> (||) = mplus
> false = mzero

I don't think it's by definition yet, but surely by convention, that 
this is a restricted form of

true  = pure ()
(&&)  = (<*)
(||)  = (<|>)
false = empty

All of these functions require only an Applicative or an Alternative, 
and except for "true", they're all in the library.

Which shows another reason to think twice before using a bool: 
Applicatives can be a better fit. They can often carry the question 
behind the bool and the value this question is about in one convenient 
structure.

Cheers,
MarLinn


From evan at evanrutledgeborden.dreamhosters.com  Sat Jul  7 14:38:34 2018
From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com)
Date: Sat, 7 Jul 2018 10:38:34 -0400
Subject: [Haskell-cafe] ANN: network-2.6.3.6
Message-ID: <CABmRwSAh6p+9fUjD_kJrovNU5Ouozbn4_1d55VLu6z9Ejwez-w@mail.gmail.com>

Announcing network-2.6.3.6

This is a bug fix release for the 2.6 branch of network.

 * Removed unnecessary withMVar, which caused locking on close.
   [#330](https://github.com/haskell/network/pull/330)

Thank you to network contributors for finding and diagnosing the bug.

--
Evan Borden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180707/a54785e0/attachment.html>

From evan at evanrutledgeborden.dreamhosters.com  Sat Jul  7 14:55:37 2018
From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com)
Date: Sat, 7 Jul 2018 10:55:37 -0400
Subject: [Haskell-cafe] ANN: network-2.7.0.2
Message-ID: <CABmRwSCGopYWrw_H2HOkF1QHv9QSiHr7nfrKo+sOKoMvf32aWg@mail.gmail.com>

Announcing network-2.7.0.2

* Removing withMVar to avoid the deadlock between "accept" and "close"
   [#330](https://github.com/haskell/network/pull/330)
* "close" does not throw exceptions. A new API: "close'" throws
   exceptions when necessary.
   [#337](https://github.com/haskell/network/pull/337)
* Fixing the hang of lazy sendAll.
   [#340](https://github.com/haskell/network/pull/340)
* Installing NetDef.h (#334)
   [#334](https://github.com/haskell/network/pull/334)

Thank you to network contributors for this bug fix release.

--
Evan Borden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180707/21546a85/attachment.html>

From olf at aatal-apotheke.de  Sat Jul  7 19:58:55 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 7 Jul 2018 21:58:55 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
Message-ID: <374B8D5D-6D88-4497-80C3-4235229E009A@aatal-apotheke.de>

> 
>> true = return ()
>> (&&) = liftM2 const
>> (||) = mplus
>> false = mzero
> 
> I don't think it's by definition yet, but surely by convention, that 
> this is a restricted form of
> 
> true  = pure ()
> (&&)  = (<*)
> (||)  = (<|>)
> false = empty
> 
> All of these functions require only an Applicative or an Alternative, 
> and except for "true", they're all in the library.

True, and after sending I realized I should have used exaclty the definitions you gave. It's just that I don't know whether there exists the concept of "commutative applicative". It is equired for (&&) to be commutative. How could one even state it without the monad bind? The following definitions are from a category theory paper [1] by Anders Kock.

import Control.Monad
-- tensorial strengths
t'' :: (Functor m) => a -> m b -> m (a,b)
t'' a mb = fmap (\b -> (a,b)) mb

t' :: (Functor m) => m a -> b -> m (a,b)
t' ma b = fmap (\a -> (a,b)) ma

-- so-called linear extensions in the first and second argument
linearext1 :: Functor m => (m c -> c) -> (a -> b -> c) -> m a -> b -> c
linearext1 struct f ma b = struct $ (fmap $ uncurry f) $ t' ma b

linearext2 :: Functor m => (m c -> c) -> (a -> b -> c) -> a -> m b -> c
linearext2 struct f a mb = struct $ (fmap $ uncurry f) $ t'' a mb

The first argument to linearext1 and linearext2 is called a "structure map" in the context of [1]. Such structure maps exist when m is a monad. Indeed, we have 

linearext1 join t'' :: (Monad m) => m a -> m b -> m (a, b)
linearext2 join t'  :: (Monad m) => m a -> m b -> m (a, b)

Now m is called commutative if the above two maps are the same [*]. But join does not exist for applicative functors, it is interdefinable with (>>=). 

Olaf

[1] Anders Kock: "Commutative Monads as a Theory of Distributions".
Theory and Applications of Categories, Vol. 26 No. 4 (2012). 
[*] They are called Fubini maps because a special case is Fubini's theorem about integration by parts. 

From olf at aatal-apotheke.de  Sat Jul  7 20:01:25 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 7 Jul 2018 22:01:25 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
Message-ID: <5D769131-DBE2-49F6-8639-BF4E49E0A59E@aatal-apotheke.de>

>But in Prolog every piece of code is evaluated to TRUTH or to FALSE. Each sentence is a goal which can be achieved and becomes a fact >or can not be – and becomes lie. So, if you inverse semantic in Haskell – program is compiled although with strange behaviour but in >Prolog program become lie. Prolog evaluation model has clean definition in run-time too, not only at compile-time. Execution of >Prolog program is a CHECK: is it truth or lie? 

I have only very limited Prolog pratice. But what you state about Prolog's semantics is only true for very simple cases, isn't it? As soon as I/O is involved, things get messier. Also, there are actually three outcomes as far as I know: provably true, provably false and "could not be proved" which is different from "false". 

When I anticipate an exception in an application where the condition prohibits the program from fulfilling its purpose, I simply call error. A common pattern I use is a library function that has return type (Either SomeErr Value), and the application takes it and wraps the result in either (error.show) return, transforming (Either SomeErr Value) into (IO Value). For libraries, one should be more careful, as we don't know what kind of environment the function might be called in - see Joachim Durchholz's post. 

Olaf

From dennis.raddle at gmail.com  Sun Jul  8 06:42:14 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Sat, 7 Jul 2018 23:42:14 -0700
Subject: [Haskell-cafe] functions making their own memos
Message-ID: <CAKxLvorFVrSmdMGDnKdJ7N63f4zaY1CkHizNu3QaC6fXnAdM+g@mail.gmail.com>

I've been wondering for some time how to handle a common use case in
imperative programming, "static" variables that are accessed only inside
one function, but not needed elsewhere.

I think this probably has something to do with existential quantification,
but in any case this is an area I'm ready to learn a lot more about. Any
ideas are welcome along with suggested reading.

Let's say that I have a function for generating random numbers every time
it is called, but I sometimes want it to to re-use the last number
depending on the time the last number was geneated:

sometimesNew :: Time -> Int -> IO (Time,Int)
sometimesNew lastTime lastValue = do
  currentTime <- <get time for system>
  if currentTime > lastTime + 10
    then do
      newValue <- <get pseudorandom value>
      return (currentTime,newValue)
    else return (lastTime,lastValue)

This function depends on the caller to remember its output (last time and
last value) and feed that back to it.

It would be nice if this function could make some kind of memo inside it
itself and no one else needs to know.

The case I'm working on right now is doing animation in Purescript on a
canvas, in which I can control the motion of an object appearing in the
animation by composing functions that control the motion. I might like to
write a function that generates an overall circular trajectory, then
compose it with a function that generates a slight wobbly motion. The
wobbly function needs, basically, to change the motion randomly by
interpolating between random positions and changing the random position
only occassionally instead of during every animation frame.

type MovementFunc = ...

So this would generate a large circular movement:

circularMovement :: MovementFunc

This generates a small wobble.

wobble :: MovementFunc

Then I can compute the final position once per animation frame by
superimposing or composing individual movements:

computePosition :: [MovementFunc] -> Time -> IO Position

The wobble function might like to have access to a memo of the last
randomly chosen position, and how long ago in milliseconds it chose that
position.

Let's say that every movement function might like to have access to a memo,
but the actual data type involved could be different from function to
function. I also need to deal with initializing the memo. So the trick is
to maintain and initialize these memo types without needing to know the
internals of every function.

Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180707/0b63f09d/attachment.html>

From aquagnu at gmail.com  Sun Jul  8 07:43:30 2018
From: aquagnu at gmail.com (Paul)
Date: Sun, 8 Jul 2018 10:43:30 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <cc861580-8b00-bad8-a1d1-787a2ce9a2c5@durchholz.org>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <CALujEfh6OPhMujcmesEqhD0eL7cw67pCpsYOFwrb+XMBq1C65g@mail.gmail.com>
 <2BD6E857-38C6-429C-8C50-49B435E400F0@aatal-apotheke.de>
 <662dfc9a-e489-39b6-e6c8-b87eb711947e@durchholz.org>
 <5b404c5c.1c69fb81.d9341.d99c@mx.google.com>
 <cc861580-8b00-bad8-a1d1-787a2ce9a2c5@durchholz.org>
Message-ID: <5b41c09c.1c69fb81.26ce5.6302@mx.google.com>

@Olaf Hello, you are right. Prolog allows side-effects, which means that you has predicates which is not “pure”. Today, after “pure” functional programming fashion, there is fashion of pure declarative programming too 😊 You define nature of predicates with determinism categories but “variables” nature with +/- notation (if variable is “output” only then it’s not pure predicate, for example, “X is Y + 5” is not pure because it’s functional but not declarative, ie, it’s evaluation but not relation). Mercury has “!” annotation, which is close to linear types I suppose (am I right?). Idea was side-effects is coded as input-output variable which is changing (state of external world). Unfortunately, I learned Prolog when I was student...  

When we are talking about truth, probably truth, etc, I think we mean https://www.mercurylang.org/information/doc-latest/mercury_ref/Determinism-categories.html. In Prolog we apply restrictions/relations to answer to get more strict answer. It’s linked with declarative nature: no evaluation but some kind of DSL to barrier answers. Sure, it’s not strict definition or something like this 😊 My intuition is like Prolog evaluation can be imagine in Haskell terms like some logic monad on top level instead of IO monad (main :: SomeLogic (), for example). Btw, how works Curry? And another my intuition is that it’s possible in Haskell with some (new?) monad. I will observe your examples, thanks a lot!

@Joachim.
Hello again. Let’s talk about Haskell and not persons. I suppose that my not good English may lead to misunderstanding. Excuse me, in this case. If you allow me, I would like to show reasons why I said “imperative” and not declarative.

In Haskell I can write:

factorial 0 = 1
factorial n = n * factorial (n - 1)

I can call it: factorial 5 => 120.

And often I meet in Web similar examples with note: “You see – Haskell is declarative language, it really looks declaratively”. IMHO it looks only (you can check Erlang syntax, which is similar to Prolog even, but Erlang is not declarative language). Let’s try the same in Prolog.

factorial(0, 1).
factorial(N, F) :-
        N #> 0,
        N1 #= N - 1,
        F #= N * F1,
        factorial(N1, F1).

I can call it: factorial(5, X) => X=120.
But also: factorial(X, 120) => X=5.

We see principal difference:
1. In Haskell we map inputs (arguments) to result. In Prolog we define not mapping but relation, which is bi-directional while Haskell is one-directional, like C, Java, etc. We can find also arguments from result in Prolog.
2. In Haskell like in any imperative language we describe exact algorithm/solution. We define HOW. In declarative language we define WHAT: we restrict result and don’t know actually how it will be evaluated.
3. In Haskell all is evaluated as you wrote code. Exactly. No magic. But in Prolog we restrict some solver to find answer (or answers). In the example this solver is called CLP(FD). Sure, there are other solvers. Modern Prolog systems contain a lot of solvers, expert system engines, etc, etc. So, Haskell has not solvers/engines. Prolog has. Prolog is DSL for solvers. Interesting analogue is SQL as DSL for RDBMS😊

If we want to achieve the same magic in Haskell, we must write such solver explicitly (ie. “how”).

Another interesting speculation about real nature of Haskell is List monad. We often see “Haskell is declarative because it has backtracking” with attached some example of List monad/do/guard. But we can say that Python is declarative because it has permutations in its itertools module which allows to solve similar tasks. We understand that List monad is not backtracking, and “guard” is similar to Smalltalk “ifTrue” – no magic, no real backtracking. But like Python itertools can be used to solve some logic tasks in bruteforce/permutations style (as many other modern languages with sequences, F#, for example).

You said that “imperative” term is based on term of side-effects. May be I’m seriously wrong, but please, correct me in this case. IMHO side-effects are totally unrelated to imperative/declarative “dichotomy”. For example,

int sum(int a, int b) { return (a + b); }

I don’t see here side-effects. I have not problems to write all my C code in such style. Without any side-effects. Also I find “pure” functions in D language, “function” keyword in Pascal and Basic. But also I see

main :: IO ()

in Haskell. So, I don’t think side-effects are relative to declarative/imperative dichotomy at whole. When I was student, criteria of declarative/imperative was: functional, procedural, OOP languages are imperative, due to one-directional evaluation/execution and you code HOW to be evaluated, but declarative is bi-directional, you code relations (WHAT), between predicates and apply some restrictions.

I am surprised that there is another classification: based on side-effects. Please, correct me, where I’m wrong and if you can do it without such emotion – I will be very glad to get new knowledge.

PS. Out of scope is declarative DSLs written in imperative languages: like Scons Python build system. Sure, there are a lot of similar Haskell libraries/tools. IMHO more correct is to say “Scons has declarative Python-based DSL, but not Python is declarative itself”.

From: Joachim Durchholz
Sent: 7 июля 2018 г. 11:17
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Bool is not...safe?!

Am 07.07.2018 um 07:15 schrieb Paul:
> By the way, there are a lot of articles why checked exceptions are bad 
> design (more problems than benefit).

That's because exceptions disrupt control flow.
If they're used as an alternative to pattern matching, i.e. thrown only 
in tail position and always either fully handled or rethrown unchanged, 
then they're fine.

I.e. checked exceptions are bad because they make it easy to construct 
bad design. Unchecked exceptions can be abused in the same way but there 
seem to be psychological reasons why this isn't done so often.

> More interesting for me is this snippet:
> 
> case (action :: Either err a) of
>     Right result -> ...
>     Left err -> deal_with err
> 
> Somebody says me that to use Bool in such way is “not safe” because no 
> way to know what does “True” returning from “action” mean. Success or 
> failure? But with some ADT (Success|Failure) code is more Haskellish and 
> safe.

Terminology N.B.: (Success|Failure) is not an abstract data type (ADT). 
It's pretty much the opposite of abstract.

> But is it true? We are talking about semantics, not type-safety because 
> type-checker passes both cases (positive branch under False/Failure, 
> negative branch under True/Success). But the same with Right/Left: 
> nothing says you to use Right for positive and Left for error case. Is 
> it true?

There's no good way to use Bool as the type of action, so the point is moot.
Of course you can reconstruct action's type to be a struct consisting of 
a Bool, a SuccessResult, and a FailureResult, but that's just awkward so 
nobody is doing this.

> Bool is algebra <1, 0, +, *>

Let me repeat: the algebraic and mathematical properties of Bool are 
irrelevant.

> Problem with Haskell is that it’s imperative and not declarative 
> language.

Haskell isn't imperative.
I.e. it matches almost none of the definitions for "imperative" that I 
have ever seen.
It matches a substantial percentage of the definitions for "declarative" 
actually, but not enough of them that I'd instinctively say it is really 
declarative - others with a different set of definitions encountered may 
feel differently.

> The root of the problem is that imperative nature of Haskell leads to 
> missing term “evaluation to something”.

The most compact definition of "imperative" that I have seen is 
"computation progresses by applying side effects".
By that definition, the ability to distinguish evaluated and unevaluated 
expressions is irrelevant.

> Haskell program is not evaluated
> expression and in the same as in Java or C: it is IO action. But in 
> Prolog every piece of code is evaluated to TRUTH or to FALSE. Each 
> sentence is a goal which can be achieved and becomes a fact or can not 
> be – and becomes lie.

Wrong terminology. Nothing in a computer is a lie.

Prolog works by turning stuff into either tautologies or contradictions.
A lie is something entirely different: a statement that intentionally 
contradicts reality. Programming language semantics does not have 
intention; programs may have state that matches or contradicts reality, 
but take this message which isn't a lie but still does not match any 
reality because no sheet of paper with these glyphs ever existed (there 
may be in the future if somebody prints this message, but that doesn't 
turn this message from a lie into a truth).

Please, get your terminology right. If you keep working with "almost 
right" terminology in your head, you will continuously "almost 
misunderstand" whatever you read, leading you to conclusions which are 
almost right but take a huge amount of effort to clean up. People who 
know the concepts and the terminology will find it too tiresome to talk 
with you because it is all about educating you (which is not the right 
level to talk with a person anyway), and will eventually drop out of 
discussions with you; the only persons who talk to you will be those who 
happen to have similarly vague ideas, placing you in an echo chamber of 
ideas that lead nowhere because everything is subtly wrong.
Just saying. I'm not going to force anything on you - but I find that 
this message is entirely about terminology correction and almost nothing 
about the topics that really interest you, which means it's been mostly 
a waste of time of both of us.

Regards,
Jo
_______________________________________________
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/20180708/6a03df29/attachment.html>

From jo at durchholz.org  Sun Jul  8 08:28:04 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 8 Jul 2018 10:28:04 +0200
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <5b41c09c.1c69fb81.26ce5.6302@mx.google.com>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <CALujEfh6OPhMujcmesEqhD0eL7cw67pCpsYOFwrb+XMBq1C65g@mail.gmail.com>
 <2BD6E857-38C6-429C-8C50-49B435E400F0@aatal-apotheke.de>
 <662dfc9a-e489-39b6-e6c8-b87eb711947e@durchholz.org>
 <5b404c5c.1c69fb81.d9341.d99c@mx.google.com>
 <cc861580-8b00-bad8-a1d1-787a2ce9a2c5@durchholz.org>
 <5b41c09c.1c69fb81.26ce5.6302@mx.google.com>
Message-ID: <fb2d7dc7-bd67-f35b-e805-340740c9dead@durchholz.org>

Am 08.07.2018 um 09:43 schrieb Paul:
> @Joachim.
> 
> Hello again. Let’s talk about Haskell and not persons. I suppose that my 
> not good English may lead to misunderstanding. Excuse me, in this case. 

Nah, you are mixing up terminology that is easily looked up.

> If you allow me, I would like to show reasons why I said “imperative” 
> and not declarative.
> 
> In Haskell I can write:
> 
> factorial 0 = 1
> 
> factorial n = n * factorial (n - 1)
> 
> I can call it: factorial 5 => 120.
> 
> And often I meet in Web similar examples with note: “You see – Haskell 
> is declarative language, it really looks declaratively”.

"It's declarative because it looks declarative" is a circular argument, 
and misses whatever definition of "declarative" was actually used.

BTW you don't define it either. Arguing around an undefined term is 
pointless.

> We see principal difference:
> 
>  1. In Haskell we map inputs (arguments) to result. In Prolog we define
>     not mapping but *relation*, which is *bi-directional* while Haskell
>     is *one-directional*, like C, Java, etc. We can find also arguments
>     from result in Prolog.

Yeah, that's the defining feature of Prolog-style languages.
And where the pure subset of Prolog is conceptually different from the 
pure subset of Haskell.

>  2. In Haskell like in any imperative language we describe exact
>     algorithm/solution. We define *HOW*. In declarative language we
>     define *WHAT*: we *restrict result* and don’t know actually how it
>     will be evaluated.
>  3. In Haskell all is evaluated as you wrote code. Exactly. No magic.

Just as much or little magic as in Prolog.
Hey, FORTRAN's expression sublanguage was considered magic at the time 
FORTRAN was written in all upper-case letters: You just write down the 
expression, and the compiler magically determines what data to move 
where to make it all happen.

So... "no magic" is not suitable as a criterion, because what's magic 
and what's not is in the eye of the beholder.
Having written a Prolog interpreter, Prolog is as non-magical as C or 
C++ to me; in fact I find Haskell's implementation slightly "more magic" 
simply because I have not yet written a run-time for a lazy language, 
but not *much* "more magic" because I happen to know the essential 
algorithms. Still, Haskell's type system and the possibilities it offers 
are pretty baffling.

>     But in Prolog we restrict some *solver* to find answer (or answers).

Except in cases where the solver is too slow or goes into an endless 
loop. At which point we start to mentally trace the solver's mechanisms 
so whe know where to place the cut, and suddenly that magic thing turns 
into a complex-but-mundane machinery.

>     In the example this solver is called CLP(FD). Sure, there are other
>     solvers. Modern Prolog systems contain a lot of solvers, expert
>     system engines, etc, etc. So, Haskell has not solvers/engines.
>     Prolog has. Prolog is DSL for solvers. Interesting analogue is SQL
>     as DSL for RDBMS😊

Agreed.

> If we want to achieve the same magic in Haskell, we must write such 
> solver explicitly (ie. “how”).

I got pretty disillusioned about Prolog when I tried to use it for 
real-world problems. So I don't consider it much of a loss if you have 
to code a solver if you want a solver.

> Another interesting speculation about real nature of Haskell is List 
> monad. We often see “Haskell is declarative because it has backtracking”

Where did you see that claim?
Because at face value, this claim is hogwash. Haskell's semantics does 
not have backtracking at all, and I doubt you'll find any runtime that 
uses backtracking even as a mere implementation strategy.

> with attached some example of List monad/do/guard.

Which is unrelated to backtracking.

 > But we can say that
> Python is declarative because it has permutations in its itertools 
> module which allows to solve similar tasks.

Python is a language where even class and function "declarations" are 
executable statements (making it really hard to work with 
mutually-referencing declarations so this isn't a mere theoretical 
quibble but a hard, real-life problem), and that's as non-declarative as 
you can get without becoming totally useless.

I'm awfully sorry, but this is the most ridiculous claim I heard in a 
long time.
I am even more sorry but I do have to talk about humans: Please get your 
definitions right. It's easy, even if English isn't your native language 
(it isn't mine either).

 >
  We understand that List
> monad is not backtracking, and “guard” is similar to Smalltalk “ifTrue” 
> – no magic, no real backtracking.

Well if that example was hogwash, why did you bring it up?

 >
  But like Python itertools can be used
> to solve some logic tasks in bruteforce/permutations style (as many 
> other modern languages with sequences, F#, for example).

Sure. You can to functional, pure, declarative, context-free etc. stuff 
in imperative languages no problem. You can even do that in assembler - 
large systems have been built using such approaches.

That doesn't make the languages themselves functional/pure/etc.; the 
definition for that is that the language does not allow doing anything 
that is not functional/pure/whatever.
Very few languages are really one of these properties, it's almost 
always just a subset of a language; still we say that Haskell "is pure" 
because the pure subset is very useful and in fact most programmers 
avoid going outside that subset. (People rarely use UnsafeIO. Whether 
_|_, or equality under lazy evaluation, are compatible with purity 
depends on details of your definition of pure, some people would say 
yes, some would say no.)

> You said that “imperative” term is based on term of side-effects. May be 
> I’m seriously wrong, but please, correct me in this case. IMHO 
> side-effects are totally unrelated to imperative/declarative 
> “dichotomy”.

That depends on what you consider declarative.
I am not aware of any widely-agreed-upon definition, so you have to 
provide one before we can talk.

 >
  But
> also I see
> 
> main :: IO ()
> 
> in Haskell.

As far as I know, the IO monad does not execute any IO. It merely 
constructs descriptions of what effects to invoke given what descriptions.
The actual execution happens outside the program, in the runtime.

That's why UnsafeIO is unsafe: It triggers IO execution inside the pure 
Haskell world, possibly creating impurities where the language semantics 
assumes purity (IOW you may find that compiler optimizations may change 
the behaviour of the program).

> When I was student, criteria 
> of declarative/imperative was: functional, procedural, OOP languages are 
> imperative, due to one-directional evaluation/execution and you code HOW 
> to be evaluated, but declarative is bi-directional, you code relations 
> (WHAT), between predicates and apply some restrictions.

That's Prolog's idea of "declarative".
HTML, CSS, and most Turing-incomplete languages are considered 
declarative, too.
Some people define "declarative" to be exactly the opposite of "imperative".

It's really a matter of definition.


From monkleyon at gmail.com  Sun Jul  8 09:04:19 2018
From: monkleyon at gmail.com (MarLinn)
Date: Sun, 8 Jul 2018 11:04:19 +0200
Subject: [Haskell-cafe] functions making their own memos
In-Reply-To: <CAKxLvorFVrSmdMGDnKdJ7N63f4zaY1CkHizNu3QaC6fXnAdM+g@mail.gmail.com>
References: <CAKxLvorFVrSmdMGDnKdJ7N63f4zaY1CkHizNu3QaC6fXnAdM+g@mail.gmail.com>
Message-ID: <a57fed3b-9b9d-ce79-f8aa-32f738bbe65d@gmail.com>


> So this would generate a large circular movement:
>
> circularMovement :: MovementFunc
>
> This generates a small wobble.
>
> wobble :: MovementFunc
>
> Then I can compute the final position once per animation frame by
> superimposing or composing individual movements:
>
> computePosition :: [MovementFunc] -> Time -> IO Position

Is there any specific reason why you can't compute the wobbles all at 
once beforehand? I'm thinking something along the lines of FRP:

type Behaviour a  = Time -> a
type MovementFunc = Behaviour RelativeMovement

So you still have wobble :: MovementFunc, but MovementFunc is pure. And 
you combine them not with (.) but with (<*>):

mergeMovements :: [Behaviour RelativeMovement] -> Behaviour RelativeMovement
mergeMovements = (mconcat .) . sequenceA

computePosition :: [Behaviour RelativeMovement] -> Behaviour Position
computePosition movements time = moveBy (mergeMovements movements time) origin

Look, Ma, I'm still not using any IO! Wheeee!

Cheers,
MarLinn


From dennis.raddle at gmail.com  Sun Jul  8 09:28:29 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Sun, 8 Jul 2018 02:28:29 -0700
Subject: [Haskell-cafe] functions making their own memos
In-Reply-To: <a57fed3b-9b9d-ce79-f8aa-32f738bbe65d@gmail.com>
References: <CAKxLvorFVrSmdMGDnKdJ7N63f4zaY1CkHizNu3QaC6fXnAdM+g@mail.gmail.com>
 <a57fed3b-9b9d-ce79-f8aa-32f738bbe65d@gmail.com>
Message-ID: <CAKxLvopKn_PvXXUVoxFnAwwUky4TS4Dhs4901Jq3irVmLF79HA@mail.gmail.com>

In this one use case, there might be a simpler solution, but I have
encountered lots of situations in which a particular algorithm could
benefit from an associated stored cache of information. The most natural
way to write an algorithm, sometimes, is in terms of its past decisions or
past state of the program, interacting with current state.

D
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180708/525adcb6/attachment.html>

From gregmainland at gmail.com  Sun Jul  8 11:15:51 2018
From: gregmainland at gmail.com (Greg Horn)
Date: Sun, 8 Jul 2018 04:15:51 -0700
Subject: [Haskell-cafe] functions making their own memos
In-Reply-To: <CAKxLvopKn_PvXXUVoxFnAwwUky4TS4Dhs4901Jq3irVmLF79HA@mail.gmail.com>
References: <CAKxLvorFVrSmdMGDnKdJ7N63f4zaY1CkHizNu3QaC6fXnAdM+g@mail.gmail.com>
 <a57fed3b-9b9d-ce79-f8aa-32f738bbe65d@gmail.com>
 <CAKxLvopKn_PvXXUVoxFnAwwUky4TS4Dhs4901Jq3irVmLF79HA@mail.gmail.com>
Message-ID: <CAAr-h4tc41u8s6H+Kkupngc6V5fESyoJEMR3Y2wuJCZbtd0=gg@mail.gmail.com>

What about something like:

import Data.IORef ( IORef, newIORef, readIORef, writeIORef )

newCounter :: IO (IO Int)
newCounter = do
  counterRef <- newIORef 0 :: IO (IORef Int)
  let getCount :: IO Int
      getCount = do
        count <- readIORef counterRef
        writeIORef counterRef (count + 1)
        return count
  return getCount

The user calls this function which creates the cache and returns the
stateful function. You can use MVars instead of IORefs if you want it to
work concurrently.

On Sun, Jul 8, 2018 at 2:29 AM Dennis Raddle <dennis.raddle at gmail.com>
wrote:

> In this one use case, there might be a simpler solution, but I have
> encountered lots of situations in which a particular algorithm could
> benefit from an associated stored cache of information. The most natural
> way to write an algorithm, sometimes, is in terms of its past decisions or
> past state of the program, interacting with current state.
>
> D
> ​
> _______________________________________________
> 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/20180708/d9eee454/attachment.html>

From brucker at spamfence.net  Sun Jul  8 17:22:25 2018
From: brucker at spamfence.net (Achim D. Brucker)
Date: Sun, 8 Jul 2018 18:22:25 +0100
Subject: [Haskell-cafe] Call for paper: Only one *week* left to prepare your
 paper for the Workshop in OCL and Textual Modeling (OCL 2018)
Message-ID: <20180708172224.cjf7haldrhw7g7yz@kandagawa.home.brucker.ch>

(Apologies for duplicates)



  **********************************************************
  ** Only one week left until the submission deadline!   ***
  **********************************************************

                        CALL FOR PAPERS
       18th International Workshop on OCL and Textual Modeling

                       Co-located with 
       MODELS 2018: ACM/IEEE 21th International Conference on Model
              Driven Engineering Languages and System,
            October 14, 2018, Copenhagen, Denmark
                     http://oclworkshop.github.io


Modeling started out with UML and its precursors as a graphical notation.
Such visual representations enable direct intuitive capturing of reality,
but they have weaknesses: for example, detailed visual representations bear
the risk of becoming overcrowded faster than textual models and some of
the visual features lack the level of precision required to create complete
and unambiguous specifications. These weaknesses of graphical notations
encouraged the development of text-based modeling languages that either
integrate with or replace graphical notations for modeling. Typical examples
of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual
modeling languages have their roots in formal language paradigms like logic,
programming and databases.

The goal of this workshop is to create a forum where researchers and practitioners
interested in building models using OCL or other kinds of textual
languages can directly interact, report advances, share results, identify tools
for language development, and discuss appropriate standards. In particular,
the workshop will encourage discussions for achieving synergy from different
modeling language concepts and modeling language use. The close interaction
will enable researchers and practitioners to identify common interests
and options for potential cooperation.

## Topics of interest

Topics of interest include (but are not limited to):

- Mappings between textual modeling languages and other languages/formalisms
- Mathematical models and/or formal semantics for textual modeling languages
- Algorithms, evaluation strategies and optimizations in the context
  of textual modeling languages for:
  - validation, verification, and testing,
  - model transformation and code generation,
  - meta-modeling and DSLs, and
  - query and constraint specifications
- Alternative graphical/textual notations for textual modeling languages
- Evolution, transformation and simplification of textual modeling
  expressions
- Libraries, templates and patterns for textual modeling languages
- Tools that support textual modeling languages (e.g., verification of
  OCL formulae, runtime monitoring of invariants)
- Model-driven security using textual modeling languages 
- Complexity results for textual modeling languages
- Quality models and benchmarks for comparing and evaluating
  textual modeling tools and algorithms
- Successful applications of textual modeling languages
- Case studies on industrial applications of textual modeling languages
- Experience reports:
  - usage of textual modeling languages and tools in complex domains,
  - usability of textual modeling languages and tools for end-users
- Empirical studies about the benefits and drawbacks of textual modeling
  languages
- Innovative textual modeling tools
- Comparison, evaluation and integration of modeling languages
- Correlation between modeling languages and modeling tasks

We particularly encourage submissions describing applications and case studies 
of textual modeling as well as test suites and benchmark collections for evaluating 
textual modeling tools.

## Venue
This workshop will be organized as a part of MODELS 2018 Conference in 
Copenhagen, Denmark. Similar to its predecessors, the workshop addresses both 
people from academia and industry. The aim is to provide a forum for addressing 
integration of OCL and other textual modeling languages, as well as tools for 
textual modeling, and for disseminating good practice and discussing the new
requirements for textual modeling.


## Workshop Format

The workshop will include short (about 15 min) presentations, parallel
sessions of working groups, and sum-up discussions.

## Submissions

Two types of papers will be considered:

* Short contributions (between 5 and 7 pages) describing new ideas, innovative 
  tools or position papers.
* Full papers (between 10 and 14 pages).

in LNCS format. Submissions should be uploaded to
[EasyChair](https://easychair.org/conferences/?conf=ocl2018).
The program committee will review the submissions (minimum 2 reviews per
paper, usually 3 reviews) and select papers according to their
relevance and interest for discussions that will take place at the
workshop. Accepted papers will be published online, as part of the
MODELS workshop proceedings, in [CEUR](http://www.ceur-ws.org).

## Important Dates

- Submission of papers:      July  17, 2018
- Notification:              August 17, 2018
- Workshop date:             October 14, 2018 



-- 
Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield
               https://www.brucker.ch | https://logicalhacking.com/blog
                           @adbrucker | @logicalhacking 

From ppbalaga at gmail.com  Sun Jul  8 17:57:03 2018
From: ppbalaga at gmail.com (=?UTF-8?B?UGF3ZcWCIEJhxYJhZ2E=?=)
Date: Sun, 8 Jul 2018 19:57:03 +0200
Subject: [Haskell-cafe] hspec - type issue in error assertion
Message-ID: <CABA1_NjFCv6XXCzM+_wWXz6skqe=aVcuCsQeRpv2U6CiZxY89Q@mail.gmail.com>

Hello fellow Haskellers!

I'm approaching learning the basics of Haskell by going through
https://wiki.haskell.org/99_questions. At the same time I write tests for
my code in Hspec. Consider question no. 2: "Find the last but one element
of a list".

My solution:
-- Problem 02
myButLast :: [a] -> a
myButLast [] = error "Empty list"
myButLast [x] = error "List has only one element"
myButLast [x1,x2] = x1
myButLast (x:xs) = myButLast xs

and a  a test:
describe "02 myButLast" $ do
it "returns the last but one element of a list" $ do
myButLast [] `shouldThrow` anyErrorCall
myButLast [1] `shouldThrow` anyErrorCall -- <- this line causes the problem
myButLast [1..4] `shouldBe` 3
myButLast ['x','y','z'] `shouldBe` 'y'
myButLast "abc" `shouldBe` 'b'


Building tests with stack test command causes the below compilation error:

    • No instance for (Num (IO a0)) arising from the literal ‘1’
>     • In the expression: 1
>       In the first argument of ‘myButLast’, namely ‘[1]’
>       In the first argument of ‘shouldThrow’, namely ‘myButLast [1]’
>    |
> 27 |             myButLast [1] `shouldThrow` anyErrorCall
>    |
>


>From what I understand, type of myButLast [1] is different than expected by
shouldThrow. What I don't understand is why exactly it behaves so and how
to fix this problem. Only that one assertion doesn't compile. The others
are fine. Particularly, why does myButLast [] `shouldThrow` anyErrorCall
work but with one element it doesn't?

Can you please give me a hand?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180708/10194683/attachment.html>

From olf at aatal-apotheke.de  Sun Jul  8 20:56:46 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sun, 8 Jul 2018 22:56:46 +0200
Subject: [Haskell-cafe] Imperative vs. declarative (was: Bool is
	not...safe?!)
Message-ID: <7A9C955B-E3ED-4C06-84CB-6290BD85A6CD@aatal-apotheke.de>

Although there is little to add to Joachim's patient explanations, and there are certainly better resources, here is my own attempt at a definition of imperative vs. declarative.

The word "imperative" stems from Latin and means to command, to rule. Imperative programs tell the computer what to do, and when. Now allocate some memory, now assign this value to this variable, now check this condition and branch on it, etc. 

The word "declarative" also stems from Latin, meaning to make precise. Declarative languages tell the computer what data is, not when and how exactly to compute it. Haskell as a lazy language takes this even further - some code you have declared may actually never get executed. These decisions are abstracted away and made by the Haskell runtime system, in our case. 

Your own example of factorial is very much declarative in the above sense, because it only declares what the factorial function is, in terms of the relationship between factorial(n) and factorial(n-1). Of course the functional programmer must have a mental model of the runtime's behaviour in mind. (Recursively calling the function, in this case.) But what happens on the lower, imperative level when computing factorial(n) is not relevant for the definition of the function. 

Whether the principal programming constructs are functions or relations is not relevant to being declarative. In fact, the Prolog beginner can easily run into traps by declaring rules that make the solver (the low-level, imperative part of the execution) go into infinite loops, although all declarations are logically correct. Hence in Haskell as in Prolog, although both are declarative, the programmer must have some knowledge of the imperative nature of the runtime system. 

Olaf

From asm13243546 at gmail.com  Sun Jul  8 21:17:25 2018
From: asm13243546 at gmail.com (Alfred Matthews)
Date: Sun, 8 Jul 2018 17:17:25 -0400
Subject: [Haskell-cafe] Fwd: [livecode] haskell-art is back
In-Reply-To: <CANqT-v21dr=sJboz7BhcbBGX6o1dpGh3h1f5VwAx58WWbSjc1Q@mail.gmail.com>
References: <CANqT-v21dr=sJboz7BhcbBGX6o1dpGh3h1f5VwAx58WWbSjc1Q@mail.gmail.com>
Message-ID: <CAAZLhTfq_X4pWZCWF7jjQRu70-tWk60_WowPsM97r4t8un5yng@mail.gmail.com>

Here.

---------- Forwarded message ---------
From: Alex McLean <alex at slab.org>
Date: Sun, Jul 8, 2018, 5:16 PM
Subject: [livecode] haskell-art is back
To: livecode <livecode at we.lurk.org>


I finally found some time to recreate the haskell-art list here:
  https://we.lurk.org/postorius/lists/haskell-art.we.lurk.org/

So vivid and other in-depth haskell discussion can move back there. Cheers !

-- 
blog: http://slab.org/
_______________________________________________
Livecode mailing list -- livecode at we.lurk.org
To unsubscribe send an email to livecode-leave at we.lurk.org
-- 


Alfred.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180708/6ebd0cf7/attachment.html>

From dennis.raddle at gmail.com  Sun Jul  8 22:09:51 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Sun, 8 Jul 2018 15:09:51 -0700
Subject: [Haskell-cafe] functions making their own memos
In-Reply-To: <CAAr-h4tc41u8s6H+Kkupngc6V5fESyoJEMR3Y2wuJCZbtd0=gg@mail.gmail.com>
References: <CAKxLvorFVrSmdMGDnKdJ7N63f4zaY1CkHizNu3QaC6fXnAdM+g@mail.gmail.com>
 <a57fed3b-9b9d-ce79-f8aa-32f738bbe65d@gmail.com>
 <CAKxLvopKn_PvXXUVoxFnAwwUky4TS4Dhs4901Jq3irVmLF79HA@mail.gmail.com>
 <CAAr-h4tc41u8s6H+Kkupngc6V5fESyoJEMR3Y2wuJCZbtd0=gg@mail.gmail.com>
Message-ID: <CAKxLvoqoPxMVmYbd-QKsw+vhE+6Npd54gUCFeTeRJEbNQfeA=Q@mail.gmail.com>

Thanks, that's a cool solution. Here's another thought to avoid IO. What if
we're operating inside a state monad which has a list of memos. The
creation function newCounter then adds a memo to the list and creates
getCount as a closure with that index. The problem is that when we define
the state with its list of memos, we don't know what data type each
individual function will want to use.

D

On Sun, Jul 8, 2018 at 4:15 AM, Greg Horn <gregmainland at gmail.com> wrote:

> What about something like:
>
> import Data.IORef ( IORef, newIORef, readIORef, writeIORef )
>
> newCounter :: IO (IO Int)
> newCounter = do
>   counterRef <- newIORef 0 :: IO (IORef Int)
>   let getCount :: IO Int
>       getCount = do
>         count <- readIORef counterRef
>         writeIORef counterRef (count + 1)
>         return count
>   return getCount
>
> The user calls this function which creates the cache and returns the
> stateful function. You can use MVars instead of IORefs if you want it to
> work concurrently.
>
> On Sun, Jul 8, 2018 at 2:29 AM Dennis Raddle <dennis.raddle at gmail.com>
> wrote:
>
>> In this one use case, there might be a simpler solution, but I have
>> encountered lots of situations in which a particular algorithm could
>> benefit from an associated stored cache of information. The most natural
>> way to write an algorithm, sometimes, is in terms of its past decisions or
>> past state of the program, interacting with current state.
>>
>> D
>> ​
>> _______________________________________________
>> 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/20180708/4fe09912/attachment.html>

From whosekiteneverfly at gmail.com  Sun Jul  8 23:06:55 2018
From: whosekiteneverfly at gmail.com (Yuji Yamamoto)
Date: Mon, 9 Jul 2018 08:06:55 +0900
Subject: [Haskell-cafe] hspec - type issue in error assertion
In-Reply-To: <CABA1_NjFCv6XXCzM+_wWXz6skqe=aVcuCsQeRpv2U6CiZxY89Q@mail.gmail.com>
References: <CABA1_NjFCv6XXCzM+_wWXz6skqe=aVcuCsQeRpv2U6CiZxY89Q@mail.gmail.com>
Message-ID: <CA+6J5GGbmBgUnNPWZOrS+z6Oey+nN7vbJQyG9+D8xT-fdKcO4w@mail.gmail.com>

According to my guess:

   1. shouldThrow receives `IO a` as a first argument.
   <https://www.stackage.org/haddock/lts-11.17/hspec-expectations-0.8.2/Test-Hspec-Expectations.html#v:shouldThrow>
   2. So, both ` myButLast [] ` and ` myButLast [1] ` must be some `IO a`
   3. Then,  ` myButLast` 's type is inferred as `[IO a] -> IO a` when
   given `[]`: the element of the list is `IO a` (Which actually would be `IO
   ()` by the default rule).
   4. Similarly,  ` myButLast [1] ` 's `a` (the type of the element of the
   list) must be `IO something`. But any of `IO something` can't be a `Num`'s
   instance (as the error message " No instance for (Num (IO a0)) arising
   from the literal ‘1’ " says).

That's why  ` myButLast [1] ` can't be compiled.

To fix it, use `evaluate
<https://www.stackage.org/haddock/lts-11.17/base-4.10.1.0/Control-Exception.html#v:evaluate>
`:
`evaluate  myButLast [1]`

One more note: maybe you know we usually should not use `error`, which
raises an error in a pure function.
So, we usually handle errors in an `IO` context. That's why `shouldThrow`
receives an `IO a`.



2018年7月9日(月) 2:57 Paweł Bałaga <ppbalaga at gmail.com>:

> Hello fellow Haskellers!
>
> I'm approaching learning the basics of Haskell by going through
> https://wiki.haskell.org/99_questions. At the same time I write tests for
> my code in Hspec. Consider question no. 2: "Find the last but one element
> of a list".
>
> My solution:
> -- Problem 02
> myButLast :: [a] -> a
> myButLast [] = error "Empty list"
> myButLast [x] = error "List has only one element"
> myButLast [x1,x2] = x1
> myButLast (x:xs) = myButLast xs
>
> and a  a test:
> describe "02 myButLast" $ do
> it "returns the last but one element of a list" $ do
> myButLast [] `shouldThrow` anyErrorCall
> myButLast [1] `shouldThrow` anyErrorCall -- <- this line causes the
> problem
> myButLast [1..4] `shouldBe` 3
> myButLast ['x','y','z'] `shouldBe` 'y'
> myButLast "abc" `shouldBe` 'b'
>
>
> Building tests with stack test command causes the below compilation error:
>
>     • No instance for (Num (IO a0)) arising from the literal ‘1’
>>     • In the expression: 1
>>       In the first argument of ‘myButLast’, namely ‘[1]’
>>       In the first argument of ‘shouldThrow’, namely ‘myButLast [1]’
>>    |
>> 27 |             myButLast [1] `shouldThrow` anyErrorCall
>>    |
>>
>
>
> From what I understand, type of myButLast [1] is different than expected
> by shouldThrow. What I don't understand is why exactly it behaves so and
> how to fix this problem. Only that one assertion doesn't compile. The
> others are fine. Particularly, why does myButLast [] `shouldThrow`
> anyErrorCall  work but with one element it doesn't?
>
> Can you please give me a hand?
>
> _______________________________________________
> 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.



-- 
山本悠滋
twitter: @igrep
GitHub: https://github.com/igrep
GitLab: https://gitlab.com/igrep
Facebook: http://www.facebook.com/igrep
Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180709/bf49bd1e/attachment.html>

From aquagnu at gmail.com  Mon Jul  9 06:09:48 2018
From: aquagnu at gmail.com (PY)
Date: Mon, 9 Jul 2018 09:09:48 +0300
Subject: [Haskell-cafe] Imperative vs. declarative (was: Bool is
	not...safe?!)
In-Reply-To: <7A9C955B-E3ED-4C06-84CB-6290BD85A6CD@aatal-apotheke.de>
References: <7A9C955B-E3ED-4C06-84CB-6290BD85A6CD@aatal-apotheke.de>
Message-ID: <c23965ba-2847-5f2f-65fe-c0894d17e6e4@gmail.com>

Hello, Olaf!

08.07.2018 23:56, Olaf Klinke wrote:
> Your own example of factorial is very much declarative in the above sense, because it only declares what the factorial function is, in terms of the relationship between factorial(n) and factorial(n-1). Of course the functional programmer must have a mental model of the runtime's behaviour in mind. (Recursively calling the function, in this case.) But what happens on the lower, imperative level when computing factorial(n) is not relevant for the definition of the function.
My point was that in Haskell we define how to calculate result from 
arguments, exactly as in C# and with the same pattern-matching. But in 
Prolog I coded relation, so Prolog know how to calculate not only 
factorial but also argument from the result like we have 2 different 
evaluation coded in Prolog. Currently it's obvious: there are different 
classification. I showed only what I myself studied as a student :)
Another interesting note is: are XML, HTML, CSS declarative language? 
When I was student they were called formats and not languages. Because 
Haskell execution/evaluation is based on lambda calculus, classical 
Prolog on formal logic on 1st order predicates, but on what calculation 
model are based XML? There are a lot of XML or CSS parsers on any 
language :) So, they don't subscribe evaluation model but only data.
But another contra-example: XML -> DocBook ->  Postscript. Is it format 
or language? :) I think currently there are a lot of hybrid-languages: 
OOP+FP (F#, C#, Ocaml, CL...), FP+PL (Mercury, Curry...). Also there are 
a lot of PL libraries, for example: yieldProlog for Python :) So, there 
are a lot of cases when it's difficult to make right classification. So, 
I understand that classification becomes more unclear and difficult, 
that's true. Like that may be different way to classify them.
Olaf, but I have another question. You was talking about commutative 
monads. I check it, something like this:

|doa <-ma b <-mb f a b is equal to: ||dob <-mb a <-ma f a b|

&& and || are commutative sure. But question is: why in this case in C/C++, Bash (what else) order has matter, even more: order is fixed in standard.

`e1 && e2` is equals to `if e1 then e2`. And there is a lot of code 
which relies on this. Why they implements boolean operations in such 
way? Order has not matter for +, -, *, etc in the same languages (they 
are commutative). Why so many languages have not commutative bool 
operations? When i think about it, i find next example: Haskell function 
is pure, but is it really true? :) In practical world we can have 2 
functions one like `f a b = a + b`. And another `g` may be some wavelet 
transformation or calculation of some super big fractal. No side effects 
(effects in external world), but when you evaluate `f` - you can not see 
effect. But when you calculate `g` - you can even touch the effect on 
CPU case with fingers (it will be hot!) :-) So, there is difference to 
write `f && g` or `g && f`. If some code relies on order of execution 
and use `&&` instead of `if` - it has matter. May be bool operations 
were not implemented commutative in those languages because it allows to 
write "multi-ifs" (a & b & c & d ...) in short circuit way? I never 
though about this early :)  I remember that there were orelse and 
andalso in Basic and Ocaml... So, seems there is such tradition in CS: 
to have mandatory non-commutative and's/or's and optionally commutative 
and's/or's ?

===
Best regards, Paul
||
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180709/329971e4/attachment.html>

From aquagnu at gmail.com  Mon Jul  9 08:22:15 2018
From: aquagnu at gmail.com (PY)
Date: Mon, 9 Jul 2018 11:22:15 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <2239896.n8XztdG4Tx@pckolar>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <cc861580-8b00-bad8-a1d1-787a2ce9a2c5@durchholz.org>
 <5b41c09c.1c69fb81.26ce5.6302@mx.google.com> <2239896.n8XztdG4Tx@pckolar>
Message-ID: <9be789cc-1616-e261-37c3-972634b6c0e3@gmail.com>

Hello, Dušan!

 > This is not Prolog, it is a Prolog with CLP extension over integers.

as well as Haskell has a lot of extensions. I mentioned CLP as solver 
but modern Prologs is not ISO only and has a lot of solvers (CHR, 
different CLP, FuzzyLogic, Tabulating, etc). Actually CLP(x) in included 
in most modern implementations.


09.07.2018 10:58, Dušan Kolář wrote:
>
> Hello PY/Paul,
>
> You are using misleading arguments!
>
> This is not Prolog, it is a Prolog with CLP extension over integers.
>
> >
>
> > factorial(0, 1).
>
> > factorial(N, F) :-
>
> > N #> 0,
>
> > N1 #= N - 1,
>
> > F #= N * F1,
>
> > factorial(N1, F1).
>
> >
>
> > I can call it: factorial(5, X) => X=120.
>
> > But also: factorial(X, 120) => X=5.
>
> >
>
> Pure Prolog is:
>
> factorial(0, 1) :- !.
>
> factorial(N, F) :-
>
> NN is N - 1,
>
> factorial(NN, FF),
>
> F is FF * N.
>
> which is a function, not a relation, as you write.
>
> Dušan Kolář
>

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

From sivanov at colimite.fr  Mon Jul  9 08:51:27 2018
From: sivanov at colimite.fr (Sergiu Ivanov)
Date: Mon, 09 Jul 2018 10:51:27 +0200
Subject: [Haskell-cafe] Imperative vs. declarative (was: Bool is
	not...safe?!)
In-Reply-To: <c23965ba-2847-5f2f-65fe-c0894d17e6e4@gmail.com>
References: <7A9C955B-E3ED-4C06-84CB-6290BD85A6CD@aatal-apotheke.de>
 <c23965ba-2847-5f2f-65fe-c0894d17e6e4@gmail.com>
Message-ID: <87wou4yepc.fsf@colimite.fr>

Hi Paul,

1. What exactly is the difference between "what to do?" and "how to do
   it?" for you?  For example: in Prolog, we write _how to_ build a
   relation between some variables.

2. Of course, function purity is an abstraction.  Now imagine a scale of
   impurity; a Haskell pure function is purer than a typical Bash
   function.

I'm genuinely interested in your reasoning, but I will join the small
chorus of people asking you for definitions.  Perhaps, you could write
up your ideas in a blog post somewhere that we can then discuss?

-
Sergiu


Thus quoth  PY  on Mon Jul 09 2018 at 08:09 (+0200):
> Hello, Olaf!
>
> 08.07.2018 23:56, Olaf Klinke wrote:
>> Your own example of factorial is very much declarative in the above sense, because it only declares what the factorial function is, in terms of the relationship between factorial(n) and factorial(n-1). Of course the functional programmer must have a mental model of the runtime's behaviour in mind. (Recursively calling the function, in this case.) But what happens on the lower, imperative level when computing factorial(n) is not relevant for the definition of the function.
> My point was that in Haskell we define how to calculate result from
> arguments, exactly as in C# and with the same pattern-matching. But in
> Prolog I coded relation, so Prolog know how to calculate not only
> factorial but also argument from the result like we have 2 different
> evaluation coded in Prolog. Currently it's obvious: there are different
> classification. I showed only what I myself studied as a student :)
> Another interesting note is: are XML, HTML, CSS declarative language?
> When I was student they were called formats and not languages. Because
> Haskell execution/evaluation is based on lambda calculus, classical
> Prolog on formal logic on 1st order predicates, but on what calculation
> model are based XML? There are a lot of XML or CSS parsers on any
> language :) So, they don't subscribe evaluation model but only data.
> But another contra-example: XML -> DocBook -> Postscript. Is it format
> or language? :) I think currently there are a lot of hybrid-languages:
> OOP+FP (F#, C#, Ocaml, CL...), FP+PL (Mercury, Curry...). Also there are
> a lot of PL libraries, for example: yieldProlog for Python :) So, there
> are a lot of cases when it's difficult to make right classification. So,
> I understand that classification becomes more unclear and difficult,
> that's true. Like that may be different way to classify them.
> Olaf, but I have another question. You was talking about commutative
> monads. I check it, something like this:
>
> |doa <-ma b <-mb f a b is equal to: ||dob <-mb a <-ma f a b|
>
> && and || are commutative sure. But question is: why in this case in C/C++, Bash (what else) order has matter, even more: order is fixed in standard.
>
> `e1 && e2` is equals to `if e1 then e2`. And there is a lot of code
> which relies on this. Why they implements boolean operations in such
> way? Order has not matter for +, -, *, etc in the same languages (they
> are commutative). Why so many languages have not commutative bool
> operations? When i think about it, i find next example: Haskell function
> is pure, but is it really true? :) In practical world we can have 2
> functions one like `f a b = a + b`. And another `g` may be some wavelet
> transformation or calculation of some super big fractal. No side effects
> (effects in external world), but when you evaluate `f` - you can not see
> effect. But when you calculate `g` - you can even touch the effect on
> CPU case with fingers (it will be hot!) :-) So, there is difference to
> write `f && g` or `g && f`. If some code relies on order of execution
> and use `&&` instead of `if` - it has matter. May be bool operations
> were not implemented commutative in those languages because it allows to
> write "multi-ifs" (a & b & c & d ...) in short circuit way? I never
> though about this early :) I remember that there were orelse and
> andalso in Basic and Ocaml... So, seems there is such tradition in CS:
> to have mandatory non-commutative and's/or's and optionally commutative
> and's/or's ?
>
> ===
> Best regards, Paul
> ||
> _______________________________________________
> 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 --------------
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/20180709/dab27238/attachment-0001.sig>

From aquagnu at gmail.com  Mon Jul  9 10:08:34 2018
From: aquagnu at gmail.com (PY)
Date: Mon, 9 Jul 2018 13:08:34 +0300
Subject: [Haskell-cafe] Bool is not...safe?!
In-Reply-To: <18904205.LUJ1HdeKrs@pckolar>
References: <07D499E4-501B-434F-9DD5-CDAF595A92C2@aatal-apotheke.de>
 <2239896.n8XztdG4Tx@pckolar> <9be789cc-1616-e261-37c3-972634b6c0e3@gmail.com>
 <18904205.LUJ1HdeKrs@pckolar>
Message-ID: <658d0644-711c-3f6f-0798-24207967518c@gmail.com>

09.07.2018 11:50, Dušan Kolář wrote:
>
> Hmm, but CLP has completely different way of evaluation and program 
> construction than Prolog has. Moreover, stating it is a Prolog is not 
> so much true then. That's the point as I can see it.
>
I got you. And this was my point, "declarative" for me, means some 
declarations/restrictions about answer/answers. No exact algorithm: you 
can even don't know how this is evaluated/executed. You only find some 
relations and declare them. And set of solvers tries to find solutions. 
So, modern Prolog/Logic systems are Prolog as DSL and set of solvers, 
right. For example, to find factorial as well as it's argument, you need 
to implement CLP library in Haskell explicitly (if you want to use CLP 
way). This is the Haskell tradition. Sure, you can do it in Python, in C 
(sure, such libraries already exist). But it's not declarative 
tradition: predicates calculus is based on backtracking and variables 
unification. Haskell, like Scheme is based on lambda calculus. So, 
evaluation is totally different.

But more interesting here (regarding to Bool subj)  is that Haskell can 
return to you 120 as factorial result, but Prolog will answer you (if it 
finds several results) "do you need next one?" and *result in Prolog is 
"Yes."*. This is important. Which can be imagine in terms of Haskell 
like you have not top-level `IO ()` but some `LogicMonad ()`. And all 
evaluations in Haskell will lead to Boolean (OK, truth/lie/yes/no) 
result. Evaluated (integers/floats/etc) result must be returned as 
output variables (your factorial is: `factorial(+N, -F)` i.e. it's 
one-directional only, so all functions in such Haskell also can return 
results in some reference/output var and evaluated to Bool). I can 
imagine this. Also if result is "No.", output variables unifications 
(bindings - in Haskell terms) will be dropped out. Unfortunately I dont 
know Curry and absolutely can not say: is it implemented in such way. 
But I'm sure that it's possible :)

Joachim pointed out "cut" operation which leads to more effective code, 
but eliminates pure logic constructs. There are "green cuts" (does not 
change semantic) and "red cuts" and this shows that practical real world 
languages mostly are not pure functional/pure logical.

But there is another point: it makes sense to have pure logical 
application which can be driven from C# or Java application (there are 
such puzzles and other games, on Android, Windows, tables/plane 
schedulers, expert systems, etc), but I can not imagine why I'll call 
for example, Haskell from the Java, because their area mostly are 
intersected in contrast with Java/Prolog, for example. This is some 
marker too, about which languages have similar "nature".

I have already agreed that are possible another classifications 
coordinates as well as it's difficult to classify some languages because 
they are totally hybrid (I remember yet another such: Racket, Oz/Mozart).

PS. I'm application developer only, not researcher, but I'm absolutely 
sure: there are people in the list which are totally in the subject, 
even may be some of them are devs of Curry or Mercury for example, and 
maybe they are laughing at me and my naive intuitions now :)


> And it has nothing to do with Haskell extensions. In Haskell, the 
> principle remains the same, though.
>
> Dušan
>
> On pondělí 9. července 2018 10:22:15 CEST you wrote:
>
> > Hello, Dušan!
>
> >
>
> > > This is not Prolog, it is a Prolog with CLP extension over integers.
>
> >
>
> > as well as Haskell has a lot of extensions. I mentioned CLP as solver
>
> > but modern Prologs is not ISO only and has a lot of solvers (CHR,
>
> > different CLP, FuzzyLogic, Tabulating, etc). Actually CLP(x) in included
>
> > in most modern implementations.
>
> >
>
> > 09.07.2018 10:58, Dušan Kolář wrote:
>
> > > Hello PY/Paul,
>
> > >
>
> > > You are using misleading arguments!
>
> > >
>
> > > This is not Prolog, it is a Prolog with CLP extension over integers.
>
> > >
>
> > > > factorial(0, 1).
>
> > > >
>
> > > > factorial(N, F) :-
>
> > > >
>
> > > > N #> 0,
>
> > > >
>
> > > > N1 #= N - 1,
>
> > > >
>
> > > > F #= N * F1,
>
> > > >
>
> > > > factorial(N1, F1).
>
> > > >
>
> > > >
>
> > > >
>
> > > > I can call it: factorial(5, X) => X=120.
>
> > > >
>
> > > > But also: factorial(X, 120) => X=5.
>
> > >
>
> > > Pure Prolog is:
>
> > >
>
> > > factorial(0, 1) :- !.
>
> > >
>
> > > factorial(N, F) :-
>
> > >
>
> > > NN is N - 1,
>
> > >
>
> > > factorial(NN, FF),
>
> > >
>
> > > F is FF * N.
>
> > >
>
> > > which is a function, not a relation, as you write.
>
> > >
>
> > > Dušan Kolář
>

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

From gershomb at gmail.com  Mon Jul  9 16:19:01 2018
From: gershomb at gmail.com (Gershom B)
Date: Mon, 9 Jul 2018 17:19:01 +0100
Subject: [Haskell-cafe] Announce: Haskell Platform 8.4.3
In-Reply-To: <CAM8RHpFCz5yQYNTPVR=Bb9ecZUM8JkYMZu8a-sbVR2hrgvu1hg@mail.gmail.com>
References: <CAM8RHpFCz5yQYNTPVR=Bb9ecZUM8JkYMZu8a-sbVR2hrgvu1hg@mail.gmail.com>
Message-ID: <CAM8RHpGrYoMM8ttyXr0myyD3QwN7orG3DjTJ5d2sMtbORJDdMA@mail.gmail.com>

As  a brief followup, new 8.4.3 installers for windows have been
released (both core and full), which resolve a few issues brought
about by the switch to automatic modification of "extra-prog-path" and
related, and the corresponding hashes have been updated.

Best,
Gershom


On Tue, Jun 12, 2018 at 7:27 AM Gershom B <gershomb at gmail.com> wrote:
>
> On behalf of the Haskell Platform team, I'm happy to announce the release of
>
> Haskell Platform 8.4.3
>
> Now available at
>
> https://www.haskell.org/platform/
>
> This includes GHC 8.4.3, cabal-install 2.2.0.0, and stack 1.7.1.
>
> A full list of contents is available at
> https://www.haskell.org/platform/contents.html
>
> Outside of the update of the GHC to 8.4.3, the only substantive change
> in this release is to the new version of the primitive library, which
> includes a range of fixes and improvements.
>
> The list of GHC changes is available at:
> https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.3-released
>
> And the list of changes to Primitive is available at:
> http://hackage.haskell.org/package/primitive-0.6.4.0/changelog
>
> There are (still) currently no 32 bit Windows builds available. We're
> looking into the issues preventing us from building an installer for
> that platform. The components all appear to work individually in such
> a case, and can be installed separately by users who so desire.
>
> Happy Haskell Hacking all,
> Gershom

From johannes.waldmann at htwk-leipzig.de  Mon Jul  9 17:20:11 2018
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 9 Jul 2018 19:20:11 +0200
Subject: [Haskell-cafe] if-then without -else?
Message-ID: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>

Dear Cafe,

a student in my class detected
this inconsistency in the design of Haskell:

> Why require that each "if-then" has an "else"
> while still allowing incomplete sets of patterns?
> We could define "if p then a"
> by translating to "case p of { True -> a }"

I think that "but then we'd have the dangling-else problem"
is not a good answer because this is really about semantics,
not surface syntax.

For reference, Scheme has short-if, see
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.4.3
(value is "unspecified" if condition is false)
and Common LISP does as well
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node84.html#SECTION001160000000000000000
(value is "nil")

Was this considered at some point in Haskell's design process?
There is Section 5.2 on pattern matching in
http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf (*)
but it does not mention if-then(-else).

- J.W.

(*) can we please add this to https://www.haskell.org/documentation
Upvote this: https://github.com/haskell-infra/hl/issues/86

From arjenvanweelden at gmail.com  Mon Jul  9 17:30:05 2018
From: arjenvanweelden at gmail.com (arjenvanweelden at gmail.com)
Date: Mon, 09 Jul 2018 19:30:05 +0200
Subject: [Haskell-cafe] if-then without -else?
In-Reply-To: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
References: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
Message-ID: <6794bc1d4e2669ca48ba1918ba4382abfa9b66cb.camel@gmail.com>

On Mon, 2018-07-09 at 19:20 +0200, Johannes Waldmann wrote:
> Dear Cafe,
> 
> a student in my class detected
> this inconsistency in the design of Haskell:
> 
> > Why require that each "if-then" has an "else"
> > while still allowing incomplete sets of patterns?
> > We could define "if p then a"
> > by translating to "case p of { True -> a }"

This is the same as (case p of { True -> a; _ -> throw
PatternDoesNotMatchException }). Therefore (if False then a) would give
an exception.

Normally, every expression has a value. The value of (if p then x else
y) is properly defined. What would be the value of (if p then x)? If it
is (), then x should also have type (), I think.

You can do something like that in a Monad, and the function is called
when. And there is an unless, which is an if-else without a then.

> I think that "but then we'd have the dangling-else problem"
> is not a good answer because this is really about semantics,
> not surface syntax.
> 
> For reference, Scheme has short-if, see
> http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.4.3
> (value is "unspecified" if condition is false)
> and Common LISP does as well
> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node84.html#SECTION001
> 160000000000000000
> (value is "nil")
> 
> Was this considered at some point in Haskell's design process?
> There is Section 5.2 on pattern matching in
> http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf (*)
> but it does not mention if-then(-else).
> 
> - J.W.
> 
> (*) can we please add this to https://www.haskell.org/documentation
> Upvote this: https://github.com/haskell-infra/hl/issues/86
> _______________________________________________
> 

Hope this helps and kind regards, Arjen

From johannes.waldmann at htwk-leipzig.de  Mon Jul  9 18:39:49 2018
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 9 Jul 2018 20:39:49 +0200
Subject: [Haskell-cafe] if-then without -else?
Message-ID: <5e0d0e93-2a48-b77d-ae9c-83479d6170f1@htwk-leipzig.de>

> Therefore (if False then a) would give an exception.

Yes. And the question is, why is possible to write
this program using "case" but not with "if".

For the first part (allow incomplete sets of patterns in "case"):

No matter how hard we try, Haskell is not a total language -
there'll always be programs that denote bottom,
by raising exceptions (e.g., from incomplete patterns),
or by non-termination - which cannot be prohibited statically
if we want both the language to be Turing complete,
and type inference to be decidable.

Cf. Agda, which is total, and therefore
has a coverage checker (for patterns)
as well as a termination checker.

But then the second part (do not allow incomplete "if")
appears to be an inconsistency in the design.

Mind you - I don't propose to change this.
The question is just about justification for the design.

Are there applications for an incomplete "if"?
I can imagine something like assertions,
as in "f x = if some-precondition x then some-computation x"
Of course, that's only helpful if the exception
contains source information.

- J.W.

From blaze at ruddy.ru  Mon Jul  9 18:54:57 2018
From: blaze at ruddy.ru (Olga Ershova)
Date: Mon, 9 Jul 2018 14:54:57 -0400
Subject: [Haskell-cafe] if-then without -else?
In-Reply-To: <5e0d0e93-2a48-b77d-ae9c-83479d6170f1@htwk-leipzig.de>
References: <5e0d0e93-2a48-b77d-ae9c-83479d6170f1@htwk-leipzig.de>
Message-ID: <CALujEfh8sFz72nmTJkvcDjqt4kdq5oPUg-2yWspcUY2pvmA5Ew@mail.gmail.com>

In hindsight, maybe non-exhaustive case expression should be errors, not
warnings. But then adding new constructor to the type could break existing
code in multiple places, even if constructor is never used. Not everybody
ready to pay this price.

For the "if" expressions, condition type is always Bool with two
constructors, so enforcing totality looks like natural choice here.

On Mon, Jul 9, 2018 at 2:40 PM Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> > Therefore (if False then a) would give an exception.
>
> Yes. And the question is, why is possible to write
> this program using "case" but not with "if".
>
> For the first part (allow incomplete sets of patterns in "case"):
>
> No matter how hard we try, Haskell is not a total language -
> there'll always be programs that denote bottom,
> by raising exceptions (e.g., from incomplete patterns),
> or by non-termination - which cannot be prohibited statically
> if we want both the language to be Turing complete,
> and type inference to be decidable.
>
> Cf. Agda, which is total, and therefore
> has a coverage checker (for patterns)
> as well as a termination checker.
>
> But then the second part (do not allow incomplete "if")
> appears to be an inconsistency in the design.
>
> Mind you - I don't propose to change this.
> The question is just about justification for the design.
>
> Are there applications for an incomplete "if"?
> I can imagine something like assertions,
> as in "f x = if some-precondition x then some-computation x"
> Of course, that's only helpful if the exception
> contains source information.
>
> - J.W.
> _______________________________________________
> 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/20180709/03c1bacf/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Mon Jul  9 19:34:22 2018
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 9 Jul 2018 20:34:22 +0100
Subject: [Haskell-cafe] if-then without -else?
In-Reply-To: <5e0d0e93-2a48-b77d-ae9c-83479d6170f1@htwk-leipzig.de>
References: <5e0d0e93-2a48-b77d-ae9c-83479d6170f1@htwk-leipzig.de>
Message-ID: <20180709193422.slbxzc5poyq5l2qi@weber>

On Mon, Jul 09, 2018 at 08:39:49PM +0200, Johannes Waldmann wrote:
> > Therefore (if False then a) would give an exception.
> 
> Yes. And the question is, why is possible to write
> this program using "case" but not with "if".

Because the error conditions around case were badly designed.  My
understanding is that a large majority of Haskell developers believe that it
should not be possible to omit a branch in a case statement.

From aquagnu at gmail.com  Mon Jul  9 19:37:30 2018
From: aquagnu at gmail.com (Paul)
Date: Mon, 9 Jul 2018 22:37:30 +0300
Subject: [Haskell-cafe] if-then without -else?
In-Reply-To: <CALujEfh8sFz72nmTJkvcDjqt4kdq5oPUg-2yWspcUY2pvmA5Ew@mail.gmail.com>
References: <5e0d0e93-2a48-b77d-ae9c-83479d6170f1@htwk-leipzig.de>
 <CALujEfh8sFz72nmTJkvcDjqt4kdq5oPUg-2yWspcUY2pvmA5Ew@mail.gmail.com>
Message-ID: <5b43b979.1c69fb81.b105d.0467@mx.google.com>

If-without-else implies “empty-else”. It’s possible in monad context in “return ()” form. There are “when”, “unless” functions already. But in pure context “empty-else” can not imply empty result for “else” branch (what value should be used in “else” branch?). Empty-if exists in most languages in statements, i.e. under “IO a”, but not in expressions, so “a ? x : y” in C/C++, “x if a else y” in Python needs “else” branch. Non-exhaustive case is like “if ... then ... else undefined” IMHO.



From: Olga Ershova
Sent: 9 июля 2018 г. 21:55
To: Johannes Waldmann
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] if-then without -else?

In hindsight, maybe non-exhaustive case expression should be errors, not warnings. But then adding new constructor to the type could break existing code in multiple places, even if constructor is never used. Not everybody ready to pay this price.

For the "if" expressions, condition type is always Bool with two constructors, so enforcing totality looks like natural choice here.

On Mon, Jul 9, 2018 at 2:40 PM Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> wrote:
> Therefore (if False then a) would give an exception.

Yes. And the question is, why is possible to write
this program using "case" but not with "if".

For the first part (allow incomplete sets of patterns in "case"):

No matter how hard we try, Haskell is not a total language -
there'll always be programs that denote bottom,
by raising exceptions (e.g., from incomplete patterns),
or by non-termination - which cannot be prohibited statically
if we want both the language to be Turing complete,
and type inference to be decidable.

Cf. Agda, which is total, and therefore
has a coverage checker (for patterns)
as well as a termination checker.

But then the second part (do not allow incomplete "if")
appears to be an inconsistency in the design.

Mind you - I don't propose to change this.
The question is just about justification for the design.

Are there applications for an incomplete "if"?
I can imagine something like assertions,
as in "f x = if some-precondition x then some-computation x"
Of course, that's only helpful if the exception
contains source information.

- J.W.
_______________________________________________
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/20180709/11ca5a3c/attachment.html>

From david.feuer at gmail.com  Mon Jul  9 19:42:55 2018
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 9 Jul 2018 15:42:55 -0400
Subject: [Haskell-cafe] if-then without -else?
In-Reply-To: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
References: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
Message-ID: <CAMgWh9tw4VJ_LH7Gamiczgg1X9KhpG8=sLgo8b7nh+kq-fPADQ@mail.gmail.com>

If-then-else is a syntactic convenience. Missing cases are usually wrong.
We don't want to go out of our way to make it convenient to write wrong
code.

On Mon, Jul 9, 2018, 1:20 PM Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Dear Cafe,
>
> a student in my class detected
> this inconsistency in the design of Haskell:
>
> > Why require that each "if-then" has an "else"
> > while still allowing incomplete sets of patterns?
> > We could define "if p then a"
> > by translating to "case p of { True -> a }"
>
> I think that "but then we'd have the dangling-else problem"
> is not a good answer because this is really about semantics,
> not surface syntax.
>
> For reference, Scheme has short-if, see
> http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.4.3
> (value is "unspecified" if condition is false)
> and Common LISP does as well
>
> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node84.html#SECTION001160000000000000000
> (value is "nil")
>
> Was this considered at some point in Haskell's design process?
> There is Section 5.2 on pattern matching in
> http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf (*)
> but it does not mention if-then(-else).
>
> - J.W.
>
> (*) can we please add this to https://www.haskell.org/documentation
> Upvote this: https://github.com/haskell-infra/hl/issues/86
> _______________________________________________
> 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/20180709/a2308bf6/attachment.html>

From monnier at iro.umontreal.ca  Mon Jul  9 20:03:26 2018
From: monnier at iro.umontreal.ca (Stefan Monnier)
Date: Mon, 09 Jul 2018 16:03:26 -0400
Subject: [Haskell-cafe] if-then without -else?
References: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
Message-ID: <jwvsh4sb2p8.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>

> Was this considered at some point in Haskell's design process?

I don't know, but such an `if .. then` without `else` would encourage
bad coding practices, IMO.

On a related note: in C and friends if can do

   if () { .... };

but you can't do

   int x = E1 ? E2;

So, even those pragmatic people (including those C++ people who like to
include not just the kitchen sink but the surrounding farm as
well) agree with Haskell's designers.


        Stefan


From neil_mayhew at users.sourceforge.net  Mon Jul  9 21:22:08 2018
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Mon, 9 Jul 2018 15:22:08 -0600
Subject: [Haskell-cafe] if-then without -else?
In-Reply-To: <CALujEfh8sFz72nmTJkvcDjqt4kdq5oPUg-2yWspcUY2pvmA5Ew@mail.gmail.com>
References: <5e0d0e93-2a48-b77d-ae9c-83479d6170f1@htwk-leipzig.de>
 <CALujEfh8sFz72nmTJkvcDjqt4kdq5oPUg-2yWspcUY2pvmA5Ew@mail.gmail.com>
Message-ID: <e60eb811-26e9-81a1-a7f2-fa994b5da736@users.sourceforge.net>

On 2018-07-09 12:54 PM, Olga Ershova wrote:
> In hindsight, maybe non-exhaustive case expression should be errors, 
> not warnings. But then adding new constructor to the type could break 
> existing code in multiple places, even if constructor is never used. 
> Not everybody ready to pay this price.

You make a good point, and this is the best explanation I've seen in 
this discussion. However, even if the constructor is never used in your 
own code, it may well be used in library code that you call. I think 
it's dangerous for for the programmer not to know when a new constructor 
is added. I prefer to have this warning enabled, and my policy is to use 
-Wall -Werror from the start of any new project. I then turn off 
specific warnings (eg orphans) with a pragma in individual source files 
when I really need to use something.

I was interested to see that GHC allows you to turn any warning into an 
error, so I assume Haskell could be made total for pattern matching with:

-Werror=incomplete-patterns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180709/028a20a2/attachment.html>

From jgbm at acm.org  Tue Jul 10 00:11:04 2018
From: jgbm at acm.org (J. Garrett Morris)
Date: Mon, 9 Jul 2018 19:11:04 -0500
Subject: [Haskell-cafe] if-then without -else?
In-Reply-To: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
References: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
Message-ID: <CALqZiMzcCV2VH=fRyYV8MMd2URA+5P=KcfnZBAHtQXdSmbVgCQ@mail.gmail.com>

On Mon, Jul 9, 2018 at 12:20 PM Johannes Waldmann
<johannes.waldmann at htwk-leipzig.de> wrote:
> > Why require that each "if-then" has an "else"
> > while still allowing incomplete sets of patterns?
> > We could define "if p then a"
> > by translating to "case p of { True -> a }"

Hi Johannes,

`if p then a` can only ever have value `a`, so why not just write `a`
in the first place?

Of course, it could fail to evaluate... but that's not something (as a
Haskell 1.0 program anyway) you could detect or recover.

Incomplete case matches, in contrast, can do meaningful things---to
name parts of a data structure, or perhaps reflecting a
programmer-believed invariant.  Sure, they let in degenerate cases,
like `case p of {True -> a}`, but that's different from adding syntax
to the language that only expresses degenerate cases.

 /g

From anthony_clayden at clear.net.nz  Tue Jul 10 00:14:37 2018
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Tue, 10 Jul 2018 12:14:37 +1200
Subject: [Haskell-cafe] if-then without -else?
Message-ID: <CAM7nRYQgdLdjQ7Ua0CVoPDxCReotZqfeE5z1EcQbpJcAEPUoiA@mail.gmail.com>

>* Why require that each "if-then" has an "else"*


Never mind the semantics, this is a piece of syntactic history.

ALGOL 60 allowed omitted "else". That gave ambiguity:

    if p
       then if q
               then ...
           ...
           else ...

There was no layout rule. Does the "else" match to the outer "if-then"
or the inner?

BCPL ~1965 had two constructs

    if p
       then test q
                 then ...
           ...
           else ...

"if-then" has no "else". If you want an "else" use "test-then-else".


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

From simonpj at microsoft.com  Wed Jul 11 12:10:21 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 11 Jul 2018 12:10:21 +0000
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
Message-ID: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Friends
In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger Institute<https://www.sanger.ac.uk/> about Haskell.   They do lots of programming, but they aren't computer scientists.
I can tell them plenty about Haskell, but I'm ill-equipped to answer the main question in their minds: why should I even care about Haskell?  I'm too much of a biased witness.

So I thought I'd ask you for help.  War stories perhaps - how using Haskell worked (or didn't) for you.  But rather than talk generalities, I'd love to illustrate with copious examples of beautiful code.

  *   Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about?   Something that gave you an "aha" moment, or that feeling of joy when you truly make sense of something for the first time.
The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn't going to do it for them.  I need examples that I can present in 5 minutes, without needing a long setup.
To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C.  It's so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc.  But it also makes much less good use of memory, and is likely to run slower.  I think I can do that in 5 minutes.
Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done.
Pointers to your favourite blog posts would be another avenue.  (I love the Haskell Weekly News.)
Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience.
Thank you!  Perhaps your responses on this thread (if any) may be helpful to more than just me.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/036ffb8b/attachment.html>

From david.feuer at gmail.com  Wed Jul 11 12:18:07 2018
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 11 Jul 2018 08:18:07 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAMgWh9ta1Qd=0MJ7xgt_=osQOO-tR=WtJx7=z8SzediZrsJkFw@mail.gmail.com>

If you want a sorting algorithm, go for bottom-up merge sort. That's a
*real* merge sort (unlike the non-randomized "QuickSort" you mention), and
dead simple.

On Wed, Jul 11, 2018, 8:10 AM Simon Peyton Jones via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> main question in their minds: *why should I even care about Haskell*?
> I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
> love to illustrate with copious examples of beautiful code.
>
>    - Can you identify a few lines of Haskell that best characterise what
>    you think makes Haskell distinctively worth caring about?   Something that
>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>    of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell, so
> muttering about Cartesian Closed Categories isn’t going to do it for them.
> I need examples that I can present in 5 minutes, without needing a long
> setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in C
> notoriously prone to fencepost errors etc.  But it also makes much less
> good use of memory, and is likely to run slower.  I think I can do that in
> 5 minutes.
>
> Another thing that I think comes over easily is the ability to abstract:
> generalising sum and product to fold by abstracting out a functional
> argument; generalising at the type level by polymorphism, including
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>
> But you will have more and better ideas, and (crucially) ideas that are
> more credibly grounded in the day to day reality of writing programs that
> get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I love
> the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant for
> the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be helpful
> to more than just me.
>
> Simon
> _______________________________________________
> 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/20180711/28507938/attachment.html>

From fa-ml at ariis.it  Wed Jul 11 12:31:04 2018
From: fa-ml at ariis.it (Francesco Ariis)
Date: Wed, 11 Jul 2018 14:31:04 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <20180711123104.e4cdjdlycfjq5e4m@x60s.casa>

On Wed, Jul 11, 2018 at 12:10:21PM +0000, Simon Peyton Jones via Haskell-Cafe wrote:
> So I thought I'd ask you for help.  War stories perhaps - how using
> Haskell worked (or didn't) for you.  But rather than talk generalities,
> I'd love to illustrate with copious examples of beautiful code.
>   *   Can you identify a few lines of Haskell that best characterise
> what you think makes Haskell distinctively worth caring about?
> Something that gave you an "aha" moment, or that feeling of joy when
> you truly make sense of something for the first time.

If your most of your audience uses a dynamically typed language,
I would introduce type inference and how small, painful bugs can
be tracked down by the compiler without having to write a single
type signature bar top level.

Another good one is implementing a tricky function with holes
(in what I have seen described as `hole-driven` development.

Unfortunately, one of Haskell strongest suit (ease of refactoring)
doesn't really shine in bite-sized examples!

From aquagnu at gmail.com  Wed Jul 11 12:41:24 2018
From: aquagnu at gmail.com (PY)
Date: Wed, 11 Jul 2018 15:41:24 +0300
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <20180711123104.e4cdjdlycfjq5e4m@x60s.casa>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <20180711123104.e4cdjdlycfjq5e4m@x60s.casa>
Message-ID: <d248f6d8-ee42-f3c4-865c-4fb86c334d96@gmail.com>

Hello, Francesco! For me - phantom types. And may be types families.

Also good is "map" function which replace visitor pattern is short way, 
but it exists in most modern languages


11.07.2018 15:31, Francesco Ariis wrote:
> On Wed, Jul 11, 2018 at 12:10:21PM +0000, Simon Peyton Jones via Haskell-Cafe wrote:
>> So I thought I'd ask you for help.  War stories perhaps - how using
>> Haskell worked (or didn't) for you.  But rather than talk generalities,
>> I'd love to illustrate with copious examples of beautiful code.
>>    *   Can you identify a few lines of Haskell that best characterise
>> what you think makes Haskell distinctively worth caring about?
>> Something that gave you an "aha" moment, or that feeling of joy when
>> you truly make sense of something for the first time.
> If your most of your audience uses a dynamically typed language,
> I would introduce type inference and how small, painful bugs can
> be tracked down by the compiler without having to write a single
> type signature bar top level.
>
> Another good one is implementing a tricky function with holes
> (in what I have seen described as `hole-driven` development.
>
> Unfortunately, one of Haskell strongest suit (ease of refactoring)
> doesn't really shine in bite-sized examples!
> _______________________________________________
> 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 johannes.waldmann at htwk-leipzig.de  Wed Jul 11 12:46:02 2018
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Wed, 11 Jul 2018 14:46:02 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
Message-ID: <cacf7a0f-e022-a1f7-d05b-1edbdf1f3528@htwk-leipzig.de>

When teaching, I like to present

Property based testing - because it is so useful in itself,
and it shows the power of type-level computation -
the compiler constructs the dictionaries,
both for testing (class Testable p),
and for generating test data (class Serial a),
just from the type of the property to be tested.

I guess that Java folks could do this via reflection?
But the popular benchmark these days is not Java - it's Python?
Then it's good because there's no types that would help.

Exact choice of framework - (quick|small|lean)check
does not matter much for an introductory presentation.
I do have a preference for enumeration by size (leancheck)
not by depth (smallcheck) or randomly (quick).
But then, smallcheck can enumerate functions, which is useful
from the beginning (if you want to show properties
of higher order functions).

But then, proving is better than testing,
so you might want to mention "theorems for free"?
But again - the JS programmer's reaction will be:
obtain a theorem from a type? what's a type?

- J.W.

From aquagnu at gmail.com  Wed Jul 11 12:59:31 2018
From: aquagnu at gmail.com (PY)
Date: Wed, 11 Jul 2018 15:59:31 +0300
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <cacf7a0f-e022-a1f7-d05b-1edbdf1f3528@htwk-leipzig.de>
References: <cacf7a0f-e022-a1f7-d05b-1edbdf1f3528@htwk-leipzig.de>
Message-ID: <118a0e9b-3b82-dac3-fcf7-c8d7129e2493@gmail.com>

11.07.2018 15:46, Johannes Waldmann wrote:
> But the popular benchmark these days is not Java - it's Python?
> Then it's good because there's no types that would help.
Already..
   import typing
;)

From jerzy.karczmarczuk at unicaen.fr  Wed Jul 11 13:07:56 2018
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Wed, 11 Jul 2018 15:07:56 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <d248f6d8-ee42-f3c4-865c-4fb86c334d96@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <20180711123104.e4cdjdlycfjq5e4m@x60s.casa>
 <d248f6d8-ee42-f3c4-865c-4fb86c334d96@gmail.com>
Message-ID: <0ea6e710-75b1-81b1-7306-8746796176ae@unicaen.fr>

My goodness...
Neither Simon, nor the five  responders ever mention *laziness*!

For me it was THE "aha" moment, or rather a long period...

The problem with popularizing laziness is that too many short comments 
(on Internet) on it are not serious. People speak mainly about infinite 
lists (as if somebody really cared about this "infinity"), or that lazy 
program do not evaluate some expressions, which should *economise* some 
time, which usually is not true...

*

For me, lazy programs permit to represent dynamic processes as data.

Iterations as mathematical structures.

Co-recursive perturbational schemes (or asymptotic expansions, etc.), 
which are 10 or more times shorter than the orthodox approaches, and 
remain readable, and natural.

Laziness makes it possible to play with continuations, thus: "making 
future explicit",  in a particularly constructive manner.

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

Second section...

Somebody mentioned "type families".

Why not, but for an audience outside of the FP realm??
If something about types, then for sure the automatic polymorphic 
inference, which remains a bit mysterious for many people, including my 
(comp. sci.) students. And the /*Curry-Howard correspondence*/.

All the best.


Jerzy Karczmarczuk

/Caen, France/




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/430e2661/attachment.html>

From alan.zimm at gmail.com  Wed Jul 11 13:26:12 2018
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 11 Jul 2018 15:26:12 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <0ea6e710-75b1-81b1-7306-8746796176ae@unicaen.fr>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <20180711123104.e4cdjdlycfjq5e4m@x60s.casa>
 <d248f6d8-ee42-f3c4-865c-4fb86c334d96@gmail.com>
 <0ea6e710-75b1-81b1-7306-8746796176ae@unicaen.fr>
Message-ID: <CANma=H9HfWC7EghvKxtBCcDWptxRi80eOLwZOHnaZotC_mNoTQ@mail.gmail.com>

There was a Functional Programming Meetup in CT recently, by people doing
genomics[1]

Things they emphasized were DSLs, and using parser-combinators and
pretty-printers to do so.

A lot of the work relates to reading data in from standard genomic
databases, and being able to represent what comes out.

Alan



[1]
https://www.meetup.com/Cape-Town-Functional-Programmers/events/242900483/

On 11 July 2018 at 15:07, Jerzy Karczmarczuk <jerzy.karczmarczuk at unicaen.fr>
wrote:

> My goodness...
> Neither Simon, nor the five  responders ever mention *laziness*!
>
> For me it was THE "aha" moment, or rather a long period...
>
> The problem with popularizing laziness is that too many short comments (on
> Internet) on it are not serious. People speak mainly about infinite lists
> (as if somebody really cared about this "infinity"), or that lazy program
> do not evaluate some expressions, which should *economise* some time, which
> usually is not true...
>
> *
>
> For me, lazy programs permit to represent dynamic processes as data.
>
> Iterations as mathematical structures.
>
> Co-recursive perturbational schemes (or asymptotic expansions, etc.),
> which are 10 or more times shorter than the orthodox approaches, and remain
> readable, and natural.
>
> Laziness makes it possible to play with continuations, thus: "making
> future explicit",  in a particularly constructive manner.
>
> ===========================
>
> Second section...
>
> Somebody mentioned "type families".
>
> Why not, but for an audience outside of the FP realm??
> If something about types, then for sure the automatic polymorphic
> inference, which remains a bit mysterious for many people, including my
> (comp. sci.) students. And the *Curry-Howard correspondence*.
>
> All the best.
>
>
> Jerzy Karczmarczuk
>
> /Caen, France/
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Garanti
> sans virus. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_5258079610623782001_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> 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/20180711/d28f9f25/attachment.html>

From damian.nadales at gmail.com  Wed Jul 11 13:36:37 2018
From: damian.nadales at gmail.com (Damian Nadales)
Date: Wed, 11 Jul 2018 15:36:37 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>

Not sure if this helps, but the following two code snippets (taken from
Rosetta code) for computing the generalized Cartesian product of a list of
lists might exemplify a very important aspect of Haskell: Haskell
programmers must invest a lot of time into learning functional programming,
but once they speak this common language, the code tends to be easier to
understand, maintain, and reason about.

The Java solution requires to think about all sort of lower level details
on how to iterate the lists and construct the result. It even mixes
iterations with more "functional" idioms:

import static java.util.Arrays.asList; import static
java.util.Collections.emptyList; import static java.util.Optional.of; import
static java.util.stream.Collectors.toList; import java.util.List; public
class CartesianProduct { public List<?> product(List<?>... a) { if
(a.length >= 2) { List<?> product = a[0]; for (int i = 1; i < a.length;
i++) { product = product(product, a[i]); } return product; } return
emptyList(); } private <A, B> List<?> product(List<A> a, List<B> b) { return
of(a.stream() .map(e1 -> of(b.stream().map(e2 -> asList(e1,
e2)).collect(toList())).orElse(emptyList())) .flatMap(List::stream)
.collect(toList())).orElse(emptyList()); } }

A programmer that spent a lot of time studying Monads and playing around
with them, and that understands the Monad instances for lists, might come
up with the following solution in Haskell:

cartProdN :: [[a]] -> [[a]] cartProdN = sequence

This also made me realize of two things:
0. Haskell will never be mainstream, because there are not a lot of
programmers out there who are willing to do the investment required for
learning the necessary concepts to understand and write code like the one
shown above.
1. Haskell has rendered me unemployable for almost all jobs that do not
involve Haskell codebases. Imagine having to maintain code like the first
snippet, replicated in a 10K LOC codebase.

And yes, I did use the code above in production :)


On Wed, Jul 11, 2018 at 2:10 PM Simon Peyton Jones via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> main question in their minds: *why should I even care about Haskell*?
> I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
> love to illustrate with copious examples of beautiful code.
>
>    - Can you identify a few lines of Haskell that best characterise what
>    you think makes Haskell distinctively worth caring about?   Something that
>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>    of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell, so
> muttering about Cartesian Closed Categories isn’t going to do it for them.
> I need examples that I can present in 5 minutes, without needing a long
> setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in C
> notoriously prone to fencepost errors etc.  But it also makes much less
> good use of memory, and is likely to run slower.  I think I can do that in
> 5 minutes.
>
> Another thing that I think comes over easily is the ability to abstract:
> generalising sum and product to fold by abstracting out a functional
> argument; generalising at the type level by polymorphism, including
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>
> But you will have more and better ideas, and (crucially) ideas that are
> more credibly grounded in the day to day reality of writing programs that
> get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I love
> the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant for
> the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be helpful
> to more than just me.
>
> Simon
> _______________________________________________
> 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/20180711/a167aac9/attachment.html>

From vanessa.mchale at iohk.io  Wed Jul 11 13:46:22 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Wed, 11 Jul 2018 08:46:22 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <e684e2b1-0eb2-bae3-bbd8-9f57987e2698@iohk.io>

I have several short examples that I quite like:

#1: changes a probability density function into a cumulative density
function

|

cdf :: (Num a) => [a] -> [a] cdf = drop 2 . (scanl (+) 0) . ((:) 0)

|

#2: enumerate all strings on an alphabet (this uses laziness!)

|

allStrings :: [a] -> [[a]] allStrings = sequence <=< (inits . repeat)

|


  ||

#3: enumerate the Fibonacci numbers (this one uses laziness too)

|

fibonacci :: (Integral a) => [a] fibonacci = 1 : 1 : zipWith (+)
fibonacci (tail fibonacci)

|

#4: Return all subsets of a list

|

allSubsets :: [a] -> [[a]] allSubsets = filterM (pure [True, False])

|


I also have two blog posts I wrote that contain lots of short examples.
The first contains lots of short-but-interesting programs and the second
contains examples of how expressive Haskell is (by doing the same thing
multiple times):

http://blog.vmchale.com/article/haskell-aphorisms
http://blog.vmchale.com/article/sum

On 07/11/2018 07:10 AM, Simon Peyton Jones via Haskell-Cafe wrote:
>
> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the
> Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They do
> lots of programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer
> the main question in their minds: /why should I even care about
> Haskell/?  I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk
> generalities, I’d love to illustrate with copious examples of
> beautiful code.
>
>   * Can you identify a few lines of Haskell that best characterise
>     what you think makes Haskell distinctively worth caring about?  
>     Something that gave you an “aha” moment, or that feeling of joy
>     when you truly make sense of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell,
> so muttering about Cartesian Closed Categories isn’t going to do it
> for them.  I need examples that I can present in 5 minutes, without
> needing a long setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in
> C notoriously prone to fencepost errors etc.  But it also makes much
> less good use of memory, and is likely to run slower.  I think I can
> do that in 5 minutes.
>
> Another thing that I think comes over easily is the ability to
> abstract: generalising sum and product to fold by abstracting out a
> functional argument; generalising at the type level by polymorphism,
> including polymorphism over higher-kinded type constructors.   Maybe 8
> minutes.
>
> But you will have more and better ideas, and (crucially) ideas that
> are more credibly grounded in the day to day reality of writing
> programs that get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I
> love the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant
> for the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be
> helpful to more than just me.
>
> Simon
>
>
>
> _______________________________________________
> 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/20180711/f5a96214/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/f5a96214/attachment.sig>

From krystal.maughan at gmail.com  Wed Jul 11 13:55:09 2018
From: krystal.maughan at gmail.com (Krystal Maughan)
Date: Wed, 11 Jul 2018 06:55:09 -0700
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <e684e2b1-0eb2-bae3-bbd8-9f57987e2698@iohk.io>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <e684e2b1-0eb2-bae3-bbd8-9f57987e2698@iohk.io>
Message-ID: <CAOrb2G6osubcqBR8=i++ehVsb1x_9wKWkyLjg=ke3nX23aN6rg@mail.gmail.com>

I'm more on the beginner side,
but reading up on the difference between print and putStrLn, and pure and
return.
Also, understanding the Maybe Monad.
Finally, reading through some probability randomness examples of rolling
dice (for the chapter on State Monad) and seeing how mathematical they look
(ie they are similar to how I would reason about them just knowing
statistics).
Oh yeah..and folds. Fold all the things.
- Krystal

On 11 July 2018 at 06:46, Vanessa McHale <vanessa.mchale at iohk.io> wrote:

> I have several short examples that I quite like:
>
> #1: changes a probability density function into a cumulative density
> function
>
> cdf :: (Num a) => [a] -> [a]
> cdf = drop 2 . (scanl (+) 0) . ((:) 0)
>
>
> #2: enumerate all strings on an alphabet (this uses laziness!)
>
> allStrings :: [a] -> [[a]]allStrings = sequence <=< (inits . repeat)
>
> #3: enumerate the Fibonacci numbers (this one uses laziness too)
>
> fibonacci :: (Integral a) => [a]fibonacci = 1 : 1 : zipWith (+) fibonacci (tail fibonacci)
>
>
> #4: Return all subsets of a list
>
> allSubsets :: [a] -> [[a]]allSubsets = filterM (pure [True, False])
>
>
> I also have two blog posts I wrote that contain lots of short examples.
> The first contains lots of short-but-interesting programs and the second
> contains examples of how expressive Haskell is (by doing the same thing
> multiple times):
>
> http://blog.vmchale.com/article/haskell-aphorisms
> http://blog.vmchale.com/article/sum
>
> On 07/11/2018 07:10 AM, Simon Peyton Jones via Haskell-Cafe wrote:
>
> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> main question in their minds: *why should I even care about Haskell*?
> I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
> love to illustrate with copious examples of beautiful code.
>
>    - Can you identify a few lines of Haskell that best characterise what
>    you think makes Haskell distinctively worth caring about?   Something that
>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>    of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell, so
> muttering about Cartesian Closed Categories isn’t going to do it for them.
> I need examples that I can present in 5 minutes, without needing a long
> setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in C
> notoriously prone to fencepost errors etc.  But it also makes much less
> good use of memory, and is likely to run slower.  I think I can do that in
> 5 minutes.
>
> Another thing that I think comes over easily is the ability to abstract:
> generalising sum and product to fold by abstracting out a functional
> argument; generalising at the type level by polymorphism, including
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>
> But you will have more and better ideas, and (crucially) ideas that are
> more credibly grounded in the day to day reality of writing programs that
> get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I love
> the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant for
> the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be helpful
> to more than just me.
>
> Simon
>
>
> _______________________________________________
> 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/20180711/9c50fdea/attachment-0001.html>

From aquagnu at gmail.com  Wed Jul 11 13:58:20 2018
From: aquagnu at gmail.com (PY)
Date: Wed, 11 Jul 2018 16:58:20 +0300
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <e684e2b1-0eb2-bae3-bbd8-9f57987e2698@iohk.io>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <e684e2b1-0eb2-bae3-bbd8-9f57987e2698@iohk.io>
Message-ID: <ac2ab05a-e44d-a9f7-64ca-0d5596c6d17a@gmail.com>

Vanessa, I added your blog to my bookmarks :)

Thanks


11.07.2018 16:46, Vanessa McHale wrote:
>
> I have several short examples that I quite like:
>
> #1: changes a probability density function into a cumulative density 
> function
>
> |
>
> cdf :: (Num a) => [a] -> [a] cdf = drop 2 . (scanl (+) 0) . ((:) 0)
>
> |
> #2: enumerate all strings on an alphabet (this uses laziness!)
> |
>
> allStrings :: [a] -> [[a]] allStrings = sequence <=< (inits . repeat)
>
> |
>
>
>   ||
>
> #3: enumerate the Fibonacci numbers (this one uses laziness too)
> |
>
> fibonacci :: (Integral a) => [a] fibonacci = 1 : 1 : zipWith (+) 
> fibonacci (tail fibonacci)
>
> |
> #4: Return all subsets of a list
> |
>
> allSubsets :: [a] -> [[a]] allSubsets = filterM (pure [True, False])
>
> |
>
> I also have two blog posts I wrote that contain lots of short 
> examples. The first contains lots of short-but-interesting programs 
> and the second contains examples of how expressive Haskell is (by 
> doing the same thing multiple times):
>
> http://blog.vmchale.com/article/haskell-aphorisms
> http://blog.vmchale.com/article/sum
>
> On 07/11/2018 07:10 AM, Simon Peyton Jones via Haskell-Cafe wrote:
>>
>> Friends
>>
>> In a few weeks I’m giving a talk to a bunch of genomics folk at the 
>> Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They do 
>> lots of programming, but they aren’t computer scientists.
>>
>> I can tell them plenty about Haskell, but I’m ill-equipped to answer 
>> the main question in their minds: /why should I even care about 
>> Haskell/?  I’m too much of a biased witness.
>>
>> So I thought I’d ask you for help.  War stories perhaps – how using 
>> Haskell worked (or didn’t) for you.  But rather than talk 
>> generalities, I’d love to illustrate with copious examples of 
>> beautiful code.
>>
>>   * Can you identify a few lines of Haskell that best characterise
>>     what you think makes Haskell distinctively worth caring about?  
>>     Something that gave you an “aha” moment, or that feeling of joy
>>     when you truly make sense of something for the first time.
>>
>> The challenge is, of course, that this audience will know no Haskell, 
>> so muttering about Cartesian Closed Categories isn’t going to do it 
>> for them.  I need examples that I can present in 5 minutes, without 
>> needing a long setup.
>>
>> To take a very basic example, consider Quicksort using list 
>> comprehensions, compared with its equivalent in C.  It’s so short, so 
>> obviously right, whereas doing the right thing with in-place update 
>> in C notoriously prone to fencepost errors etc.  But it also makes 
>> much less good use of memory, and is likely to run slower.  I think I 
>> can do that in 5 minutes.
>>
>> Another thing that I think comes over easily is the ability to 
>> abstract: generalising sum and product to fold by abstracting out a 
>> functional argument; generalising at the type level by polymorphism, 
>> including polymorphism over higher-kinded type constructors.   Maybe 
>> 8 minutes.
>>
>> But you will have more and better ideas, and (crucially) ideas that 
>> are more credibly grounded in the day to day reality of writing 
>> programs that get work done.
>>
>> Pointers to your favourite blog posts would be another avenue.  (I 
>> love the Haskell Weekly News.)
>>
>> Finally, I know that some of you use Haskell specifically for 
>> genomics work, and maybe some of your insights would be particularly 
>> relevant for the Sanger audience.
>>
>> Thank you!  Perhaps your responses on this thread (if any) may be 
>> helpful to more than just me.
>>
>> Simon
>>
>>
>>
>> _______________________________________________
>> 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/20180711/1b6d5921/attachment.html>

From b at chreekat.net  Wed Jul 11 14:03:04 2018
From: b at chreekat.net (Bryan Richter)
Date: Wed, 11 Jul 2018 10:03:04 -0400
Subject: [Haskell-cafe] Investing in languages (Was: What is your favourite
 Haskell "aha" moment?)
In-Reply-To: <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
Message-ID: <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/5d1da9ff/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/5d1da9ff/attachment.sig>

From monnier at iro.umontreal.ca  Wed Jul 11 14:14:16 2018
From: monnier at iro.umontreal.ca (Stefan Monnier)
Date: Wed, 11 Jul 2018 10:14:16 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>

> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger
> Institute<https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren't computer scientists.
> I can tell them plenty about Haskell, but I'm ill-equipped to answer the
> main question in their minds: why should I even care about Haskell?  I'm too
> much of a biased witness.

I don't much like the monad solution for side-effects, but if those guys
might have some knowledge of the horror of concurrent programming with
locks, the STM system would be a good candidate.


        Stefan


From olf at aatal-apotheke.de  Wed Jul 11 14:17:05 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Wed, 11 Jul 2018 16:17:05 +0200 (CEST)
Subject: [Haskell-cafe] higher kind in parametric type
Message-ID: <1406945848.383451.1531318625154@webmail.strato.de>

Dear cafe,

I am writing a library for parsing higher-kinded data, based on the czipwith package [1]. I ran into the following problem.

I have a type class
class Config p f | f -> p where
    f :: (* -> *) -> *
is the higher-kinded data and
    p :: * -> *
is the associated parser type.

I want to add a class member that does not mention f in its type, e.g. 

heading :: p String

Naturally, this would lead to ambiguity checks to fail, as the usage of heading does not tell which Config instance to use. My usual workaround would be to wrap `heading` in a phantom type, e.g.
    data Heading f p = Heading (p String)
and give `heading` the type Heading f p. However, ghc-8.0.2 complains about f not being a type:

    • Expecting one more argument to ‘f’
      Expected a type, but ‘f’ has kind ‘(* -> *) -> *’
    • In the first argument of ‘Heading’, namely ‘f’
      In the type signature:
        heading :: Heading f p
      In the class declaration for ‘Config’

Is there a restriction of the kinds that can be used in parametric types?

Cheers,
Olaf

[1] http://hackage.haskell.org/package/czipwith

From vanessa.mchale at iohk.io  Wed Jul 11 14:21:53 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Wed, 11 Jul 2018 09:21:53 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
Message-ID: <51117e46-4e38-c05c-b3f5-dc528d071bbc@iohk.io>

I find it quite elegant! The fact that you can define the IO monad in
Haskell was quite a revelation. And it's especially nice when paired
with a demonstration of C FFI (where you might *need* to sequence side
effects such as freeing a value after it has been read).

newtypeIO
<http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO>a
<http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802>=IO
<http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO>(State#
<http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23>RealWorld
<http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>->(#State#
<http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23>RealWorld
<http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>,a
<http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802>#))


On 07/11/2018 09:14 AM, Stefan Monnier wrote:
>> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger
>> Institute<https://www.sanger.ac.uk/> about Haskell.   They do lots of
>> programming, but they aren't computer scientists.
>> I can tell them plenty about Haskell, but I'm ill-equipped to answer the
>> main question in their minds: why should I even care about Haskell?  I'm too
>> much of a biased witness.
> I don't much like the monad solution for side-effects, but if those guys
> might have some knowledge of the horror of concurrent programming with
> locks, the STM system would be a good candidate.
>
>
>         Stefan
>
> _______________________________________________
> 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.

-- 



*Vanessa McHale*
Functional Compiler Engineer | Chicago, IL

Website: www.iohk.io <http://iohk.io>
Twitter: @vamchale
PGP Key ID: 4209B7B5

Input Output <http://iohk.io>

Twitter <https://twitter.com/InputOutputHK> Github
<https://github.com/input-output-hk> LinkedIn
<https://www.linkedin.com/company/input-output-global>


This e-mail and any file transmitted with it are confidential and
intended solely for the use of the recipient(s) to whom it is addressed.
Dissemination, distribution, and/or copying of the transmission by
anyone other than the intended recipient(s) is prohibited. If you have
received this transmission in error please notify IOHK immediately and
delete it from your system. E-mail transmissions cannot be guaranteed to
be secure or error free. We do not accept liability for any loss,
damage, or error arising from this transmission
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/06e378ba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/06e378ba/attachment.sig>

From ionut.g.stan at gmail.com  Wed Jul 11 14:28:35 2018
From: ionut.g.stan at gmail.com (=?UTF-8?Q?Ionu=c8=9b_G._Stan?=)
Date: Wed, 11 Jul 2018 17:28:35 +0300
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <8077a45f-6b41-3efb-c9c1-7d00b9bc05c4@gmail.com>

This is not necessarily related to Haskell, as I've had this A-HA moment 
while watching the 1984 SIPC lectures from MIT.

Anyway, at some point, Mr Sussman (or was it Mr Abelson?) used `+` as an 
argument to another function. I was bedazzled!

First of all, it was the syntactic novelty — `+` was not some rigid part 
of the syntax, it was just a name — secondly, it was not any name, it 
was the name of a *function*  that was sent to another function. It was 
probably my first encounter with higher-order functions.

If I remember correctly, the code was along the lines of:

foldl (+) 0 [1,2,3]


On 11/07/2018 15:10, Simon Peyton Jones via Haskell-Cafe wrote:
> Friends
> 
> In a few weeks I’m giving a talk to a bunch of genomics folk at the 
> Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They do 
> lots of programming, but they aren’t computer scientists.
> 
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the 
> main question in their minds: /why should I even care about Haskell/?  
> I’m too much of a biased witness.
> 
> So I thought I’d ask you for help.  War stories perhaps – how using 
> Haskell worked (or didn’t) for you.  But rather than talk generalities, 
> I’d love to illustrate with copious examples of beautiful code.
> 
>   * Can you identify a few lines of Haskell that best characterise what
>     you think makes Haskell distinctively worth caring about?  
>     Something that gave you an “aha” moment, or that feeling of joy when
>     you truly make sense of something for the first time.
> 
> The challenge is, of course, that this audience will know no Haskell, so 
> muttering about Cartesian Closed Categories isn’t going to do it for 
> them.  I need examples that I can present in 5 minutes, without needing 
> a long setup.
> 
> To take a very basic example, consider Quicksort using list 
> comprehensions, compared with its equivalent in C.  It’s so short, so 
> obviously right, whereas doing the right thing with in-place update in C 
> notoriously prone to fencepost errors etc.  But it also makes much less 
> good use of memory, and is likely to run slower.  I think I can do that 
> in 5 minutes.
> 
> Another thing that I think comes over easily is the ability to abstract: 
> generalising sum and product to fold by abstracting out a functional 
> argument; generalising at the type level by polymorphism, including 
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
> 
> But you will have more and better ideas, and (crucially) ideas that are 
> more credibly grounded in the day to day reality of writing programs 
> that get work done.
> 
> Pointers to your favourite blog posts would be another avenue.  (I love 
> the Haskell Weekly News.)
> 
> Finally, I know that some of you use Haskell specifically for genomics 
> work, and maybe some of your insights would be particularly relevant for 
> the Sanger audience.
> 
> Thank you!  Perhaps your responses on this thread (if any) may be 
> helpful to more than just me.
> 
> Simon
> 
> 
> 
> _______________________________________________
> 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.
> 


-- 
Ionuț G. Stan  |  http://igstan.ro  |  http://bucharestfp.ro

From frank at fstaals.net  Wed Jul 11 14:31:48 2018
From: frank at fstaals.net (Frank Staals)
Date: Wed, 11 Jul 2018 16:31:48 +0200
Subject: [Haskell-cafe] higher kind in parametric type
In-Reply-To: <1406945848.383451.1531318625154@webmail.strato.de> (Olaf
 Klinke's message of "Wed, 11 Jul 2018 16:17:05 +0200 (CEST)")
References: <1406945848.383451.1531318625154@webmail.strato.de>
Message-ID: <85601l2697.fsf@UU.FStaals.net>

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

> Dear cafe,
>
> I am writing a library for parsing higher-kinded data, based on the czipwith package [1]. I ran into the following problem.
>
> I have a type class
> class Config p f | f -> p where
>     f :: (* -> *) -> *
> is the higher-kinded data and
>     p :: * -> *
> is the associated parser type.
>
> I want to add a class member that does not mention f in its type, e.g. 
>
> heading :: p String
>
> Naturally, this would lead to ambiguity checks to fail, as the usage of heading does not tell which Config instance to use. My usual workaround would be to wrap `heading` in a phantom type, e.g.
>     data Heading f p = Heading (p String)
> and give `heading` the type Heading f p. However, ghc-8.0.2 complains about f not being a type:
>
>     • Expecting one more argument to ‘f’
>       Expected a type, but ‘f’ has kind ‘(* -> *) -> *’
>     • In the first argument of ‘Heading’, namely ‘f’
>       In the type signature:
>         heading :: Heading f p
>       In the class declaration for ‘Config’
>
> Is there a restriction of the kinds that can be used in parametric types?
>
> Cheers,
> Olaf
>
> [1] http://hackage.haskell.org/package/czipwith

I think you can just a kind signature to 'f' in your Heading
datatype. I.e. the following seems to compile/typecheck here:


{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}

newtype Heading (f :: k) (p :: * -> *) = Heading (p String)


class Config (p :: * -> *) (f :: (* -> *) -> *) | f -> p where
  foo :: Heading f p -> String




-- 

- Frank

From eraker at gmail.com  Wed Jul 11 14:36:23 2018
From: eraker at gmail.com (erik)
Date: Wed, 11 Jul 2018 07:36:23 -0700
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <8077a45f-6b41-3efb-c9c1-7d00b9bc05c4@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8077a45f-6b41-3efb-c9c1-7d00b9bc05c4@gmail.com>
Message-ID: <CALe4-Lft8kjdxC1VcaC_k=qGpSSAKnDXqzB4P3wyD2MdtoG-Yg@mail.gmail.com>

For me there were two important "aha" moments. Right at the beginning I was
drawn in by using ADTs and pattern-matching on them. It's so simple and
plain and now it's the first thing I miss in any other language I have to
work with. I feel like this would make a short, compelling example for
programmers coming from any other background.

The second was reading Wadler's "Monads for Functional Progamming" (and
reading it a second and third time, if we're being honest). The ways in
which he takes three seemingly disconnected examples and reduces them to
this broader mathematical abstraction: I found it quite beautiful and
surprising once I fully appreciated it.


On Wed, Jul 11, 2018 at 7:29 AM Ionuț G. Stan <ionut.g.stan at gmail.com>
wrote:

> This is not necessarily related to Haskell, as I've had this A-HA moment
> while watching the 1984 SIPC lectures from MIT.
>
> Anyway, at some point, Mr Sussman (or was it Mr Abelson?) used `+` as an
> argument to another function. I was bedazzled!
>
> First of all, it was the syntactic novelty — `+` was not some rigid part
> of the syntax, it was just a name — secondly, it was not any name, it
> was the name of a *function*  that was sent to another function. It was
> probably my first encounter with higher-order functions.
>
> If I remember correctly, the code was along the lines of:
>
> foldl (+) 0 [1,2,3]
>
>
> On 11/07/2018 15:10, Simon Peyton Jones via Haskell-Cafe wrote:
> > Friends
> >
> > In a few weeks I’m giving a talk to a bunch of genomics folk at the
> > Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They do
> > lots of programming, but they aren’t computer scientists.
> >
> > I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> > main question in their minds: /why should I even care about Haskell/?
> > I’m too much of a biased witness.
> >
> > So I thought I’d ask you for help.  War stories perhaps – how using
> > Haskell worked (or didn’t) for you.  But rather than talk generalities,
> > I’d love to illustrate with copious examples of beautiful code.
> >
> >   * Can you identify a few lines of Haskell that best characterise what
> >     you think makes Haskell distinctively worth caring about?
> >     Something that gave you an “aha” moment, or that feeling of joy when
> >     you truly make sense of something for the first time.
> >
> > The challenge is, of course, that this audience will know no Haskell, so
> > muttering about Cartesian Closed Categories isn’t going to do it for
> > them.  I need examples that I can present in 5 minutes, without needing
> > a long setup.
> >
> > To take a very basic example, consider Quicksort using list
> > comprehensions, compared with its equivalent in C.  It’s so short, so
> > obviously right, whereas doing the right thing with in-place update in C
> > notoriously prone to fencepost errors etc.  But it also makes much less
> > good use of memory, and is likely to run slower.  I think I can do that
> > in 5 minutes.
> >
> > Another thing that I think comes over easily is the ability to abstract:
> > generalising sum and product to fold by abstracting out a functional
> > argument; generalising at the type level by polymorphism, including
> > polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
> >
> > But you will have more and better ideas, and (crucially) ideas that are
> > more credibly grounded in the day to day reality of writing programs
> > that get work done.
> >
> > Pointers to your favourite blog posts would be another avenue.  (I love
> > the Haskell Weekly News.)
> >
> > Finally, I know that some of you use Haskell specifically for genomics
> > work, and maybe some of your insights would be particularly relevant for
> > the Sanger audience.
> >
> > Thank you!  Perhaps your responses on this thread (if any) may be
> > helpful to more than just me.
> >
> > Simon
> >
> >
> >
> > _______________________________________________
> > 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.
> >
>
>
> --
> Ionuț G. Stan  |  http://igstan.ro  |  http://bucharestfp.ro
> _______________________________________________
> 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.



-- 
Erik Aker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/4413fc47/attachment.html>

From damian.nadales at gmail.com  Wed Jul 11 14:36:52 2018
From: damian.nadales at gmail.com (Damian Nadales)
Date: Wed, 11 Jul 2018 16:36:52 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
Message-ID: <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>

> This also made me realize of two things:
> 0. Haskell will never be mainstream, because there are not a lot of
> programmers out there who are willing to do the investment required for
> learning the necessary concepts to understand and write code like the one
> shown above.
>
>
> Replace "Haskell" with "Java" in the previous sentence, and you would have
> an equally truthful statement. :) I spent years getting comfortable with OO
> languages, and then I spent years getting familiar with Haskell. For
> someone who only knows Haskell (and I know such a person), I couldn't
> imagine teaching them Java well enough to write that code!
>
> I speak only from my own narrow perspective. I'd say programming is hard,
but functional programming is harder. Maybe that's why Java replaced
Haskell in some universities curricula
https://chrisdone.com/posts/dijkstra-haskell-java. For some reason most
programmers I know are not scared of learning OO, but they fear functional
programming.  I think the reason might be that OO concepts like inheritance
and passing messages between objects are a bit more concrete and easier to
grasp (when you present toy examples at least). Then you have design
patterns, which have intuitive names and give some very general guidelines
that one can try after reading them (and add his/her own personal twist). I
doubt people can read the Monad laws and make any sense out of them at the
first try. Maybe FP and OO are perceived as equally hard, but that was not
my impression so far.

Semicolons... Brackets *and* whitespace delineation (which is required, and
> which is customary?) ... import "static" ... "public", "class", "private"
> ... eager evaluation ... pass-by-reference/whatever ... procedural
> statements  ... these things are all mind-boggling if you don't learn them
> early.
>
> In short, I don't think the investment required in Haskell is different
> than any other programming language. As with natural languages, there are
> no absolute difficulties, only relative ones.
>
> Well, I guess that's subjective (as our two opinions illustrate ;)). It'd
be nice to have some empirical evidence of this, but I couldn't find any
paper on the subject ...


> (This might actually be a useful point to bring up when speaking to
> non-Haskellers, so perhaps this message isn't as off-topic as I initially
> assumed.)
> _______________________________________________
> 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/20180711/4fa98e4c/attachment-0001.html>

From jake.waksbaum at gmail.com  Wed Jul 11 14:51:02 2018
From: jake.waksbaum at gmail.com (Jake)
Date: Wed, 11 Jul 2018 10:51:02 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CALe4-Lft8kjdxC1VcaC_k=qGpSSAKnDXqzB4P3wyD2MdtoG-Yg@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8077a45f-6b41-3efb-c9c1-7d00b9bc05c4@gmail.com>
 <CALe4-Lft8kjdxC1VcaC_k=qGpSSAKnDXqzB4P3wyD2MdtoG-Yg@mail.gmail.com>
Message-ID: <CAAE4Qivb6CuOx0V8OCFSYYdr9skV+VvGec-xNFKYrh4coe=OxQ@mail.gmail.com>

I think using laziness for dynamic programming is a pretty amazing thing:
http://jelv.is/blog/Lazy-Dynamic-Programming/

On Wed, Jul 11, 2018 at 10:37 AM erik <eraker at gmail.com> wrote:

> For me there were two important "aha" moments. Right at the beginning I
> was drawn in by using ADTs and pattern-matching on them. It's so simple and
> plain and now it's the first thing I miss in any other language I have to
> work with. I feel like this would make a short, compelling example for
> programmers coming from any other background.
>
> The second was reading Wadler's "Monads for Functional Progamming" (and
> reading it a second and third time, if we're being honest). The ways in
> which he takes three seemingly disconnected examples and reduces them to
> this broader mathematical abstraction: I found it quite beautiful and
> surprising once I fully appreciated it.
>
>
> On Wed, Jul 11, 2018 at 7:29 AM Ionuț G. Stan <ionut.g.stan at gmail.com>
> wrote:
>
>> This is not necessarily related to Haskell, as I've had this A-HA moment
>> while watching the 1984 SIPC lectures from MIT.
>>
>> Anyway, at some point, Mr Sussman (or was it Mr Abelson?) used `+` as an
>> argument to another function. I was bedazzled!
>>
>> First of all, it was the syntactic novelty — `+` was not some rigid part
>> of the syntax, it was just a name — secondly, it was not any name, it
>> was the name of a *function*  that was sent to another function. It was
>> probably my first encounter with higher-order functions.
>>
>> If I remember correctly, the code was along the lines of:
>>
>> foldl (+) 0 [1,2,3]
>>
>>
>> On 11/07/2018 15:10, Simon Peyton Jones via Haskell-Cafe wrote:
>> > Friends
>> >
>> > In a few weeks I’m giving a talk to a bunch of genomics folk at the
>> > Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They do
>> > lots of programming, but they aren’t computer scientists.
>> >
>> > I can tell them plenty about Haskell, but I’m ill-equipped to answer
>> the
>> > main question in their minds: /why should I even care about Haskell/?
>> > I’m too much of a biased witness.
>> >
>> > So I thought I’d ask you for help.  War stories perhaps – how using
>> > Haskell worked (or didn’t) for you.  But rather than talk generalities,
>> > I’d love to illustrate with copious examples of beautiful code.
>> >
>> >   * Can you identify a few lines of Haskell that best characterise what
>> >     you think makes Haskell distinctively worth caring about?
>> >     Something that gave you an “aha” moment, or that feeling of joy when
>> >     you truly make sense of something for the first time.
>> >
>> > The challenge is, of course, that this audience will know no Haskell,
>> so
>> > muttering about Cartesian Closed Categories isn’t going to do it for
>> > them.  I need examples that I can present in 5 minutes, without needing
>> > a long setup.
>> >
>> > To take a very basic example, consider Quicksort using list
>> > comprehensions, compared with its equivalent in C.  It’s so short, so
>> > obviously right, whereas doing the right thing with in-place update in
>> C
>> > notoriously prone to fencepost errors etc.  But it also makes much less
>> > good use of memory, and is likely to run slower.  I think I can do that
>> > in 5 minutes.
>> >
>> > Another thing that I think comes over easily is the ability to
>> abstract:
>> > generalising sum and product to fold by abstracting out a functional
>> > argument; generalising at the type level by polymorphism, including
>> > polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>> >
>> > But you will have more and better ideas, and (crucially) ideas that are
>> > more credibly grounded in the day to day reality of writing programs
>> > that get work done.
>> >
>> > Pointers to your favourite blog posts would be another avenue.  (I love
>> > the Haskell Weekly News.)
>> >
>> > Finally, I know that some of you use Haskell specifically for genomics
>> > work, and maybe some of your insights would be particularly relevant
>> for
>> > the Sanger audience.
>> >
>> > Thank you!  Perhaps your responses on this thread (if any) may be
>> > helpful to more than just me.
>> >
>> > Simon
>> >
>> >
>> >
>> > _______________________________________________
>> > 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.
>> >
>>
>>
>> --
>> Ionuț G. Stan  |  http://igstan.ro  |  http://bucharestfp.ro
>> _______________________________________________
>> 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.
>
>
>
> --
> Erik Aker
> _______________________________________________
> 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/20180711/6668766b/attachment.html>

From monnier at iro.umontreal.ca  Wed Jul 11 15:02:00 2018
From: monnier at iro.umontreal.ca (Stefan Monnier)
Date: Wed, 11 Jul 2018 11:02:00 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8077a45f-6b41-3efb-c9c1-7d00b9bc05c4@gmail.com>
 <CALe4-Lft8kjdxC1VcaC_k=qGpSSAKnDXqzB4P3wyD2MdtoG-Yg@mail.gmail.com>
Message-ID: <jwvbmbd7r9d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>

> For me there were two important "aha" moments. Right at the beginning I was
> drawn in by using ADTs and pattern-matching on them. It's so simple and
> plain and now it's the first thing I miss in any other language I have to
> work with. I feel like this would make a short, compelling example for
> programmers coming from any other background.

Indeed, the one thing I really miss when hacking on Elisp is the great
help I get from my Haskell/ML typecheckers when I modify one of my
datatypes, showing me exhaustively (or close enough) all the places
where changes are needed.


        Stefan


From monnier at iro.umontreal.ca  Wed Jul 11 15:09:42 2018
From: monnier at iro.umontreal.ca (Stefan Monnier)
Date: Wed, 11 Jul 2018 11:09:42 -0400
Subject: [Haskell-cafe] Investing in languages
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
Message-ID: <jwv601l7qxt.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>

> but functional programming is harder.

There's no doubt that languages like Haskell go through extra efforts to
make it *harder* to write incorrect code, and along the way they also
make it harder to write code at all.

So maybe it will take your guy a week to get the code written in
Haskell, whereas a couple days were sufficient in Java.  But that's
without counting the subsequent month during which the Java code will
have to be debugged before it actually works ;-)

IIRC it was Bob Harper who said a good programming language should be
hard to write (but easy to read, of course)?


        Stefan


From neil_mayhew at users.sourceforge.net  Wed Jul 11 16:11:30 2018
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Wed, 11 Jul 2018 10:11:30 -0600
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <e5c986f5-8a56-a220-6f36-53abe6f3f352@users.sourceforge.net>

I came to Haskell from C++, and I was used to the idea of parametric 
types and functions from C++ templates.

However, what I really liked about Haskell's way of doing these was 
that, due to type inference, not only is there a lot less ceremony 
involved, but code is generic (parametric) *by default*, and thus much 
more reusable, although you still have the option of tightening it up by 
adding a type annotation (eg for performance reasons). For a while, I 
was writing all my C++ code as templates, but this ended up being a pain.

Also, traditionally C++ has not allowed you to place any constraints on 
template arguments (type parameters) whereas Haskell's type classes are 
a very elegant way of doing it. (C++ now has concepts, but I haven't 
taken the time yet to see how they compare with type classes.)

I was also used to function overloading, which is somewhat similar to 
type inference, in that the compiler will pick an implementation based 
on the types of a function's arguments. This is similar to Haskell 
picking an implementation from among type class instances. However, what 
blew me away is that Haskell can overload based on *return type* as well 
as argument types. I haven't seen any other production-ready language 
that can do this. A great example of how this is useful is the regex 
library, where you can select from among widely varying styles of regex 
matching result simply by type inference, ie without needing any type 
annotation.

There were a *lot* of other things I found amazing, but others have 
covered many of these already. Also, languages are borrowing from each 
other at a rapid rate these days (eg Rust traits are equivalent to type 
classes) so it's hard to find a "killer feature" in Haskell any more 
(except laziness, perhaps). I think it's more the well-balanced 
combination of all the features that makes Haskell so pleasant to work 
in, and it's hard to demonstrate all of these in a single example.

My own favourite "gem" is this code for computing all primes, based on 
code in a paper[1] by Doug McIlroy:

primes = sieve [2..] where sieve (p : ns) = p : sieve [n | n <- ns, n 
`mod` p /= 0]

I think care must be exercised, when using examples like this one, to 
avoid giving the impression that Haskell is a "toy" language. However, 
what I find interesting about this example is that all other sieve 
implementations I've seen work on a fixed size of sieve up front, and if 
you later change your mind about how many primes you want, eg because 
you're expanding a hash table and want a bigger prime for the size, you 
typically have to start the sieve from scratch again.

[1]: http://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/fb9b02cb/attachment.html>

From simonpj at microsoft.com  Wed Jul 11 16:24:51 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 11 Jul 2018 16:24:51 +0000
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <e5c986f5-8a56-a220-6f36-53abe6f3f352@users.sourceforge.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <e5c986f5-8a56-a220-6f36-53abe6f3f352@users.sourceforge.net>
Message-ID: <AM0PR83MB030832C8CAA921B2B41DC879AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Also, languages are borrowing from each other at a rapid rate these days (eg Rust traits are equivalent to type classes) so it's hard to find a "killer feature" in Haskell any more

That’s true, and to be celebrated!

One thing that stands our for me is the ability to abstract over type constructors:
            f :: forall (m :: * -> *) (a :: *). Monad m => a -> m a

That ability is what has given rise to a stunningly huge collection of abstractions: not just Monad, but Functor, Applicative, Traversable, Foldable, etc etc etc.   Really a lot.  It opens up a new way to think about the world.  But only made possible by that one feature.   (Plus type classes of course.)

Do any statically typed languages other than Haskell and Scala do this?

Simon

From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Neil Mayhew
Sent: 11 July 2018 17:12
To: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?

I came to Haskell from C++, and I was used to the idea of parametric types and functions from C++ templates.

However, what I really liked about Haskell's way of doing these was that, due to type inference, not only is there a lot less ceremony involved, but code is generic (parametric) *by default*, and thus much more reusable, although you still have the option of tightening it up by adding a type annotation (eg for performance reasons). For a while, I was writing all my C++ code as templates, but this ended up being a pain.

Also, traditionally C++ has not allowed you to place any constraints on template arguments (type parameters) whereas Haskell's type classes are a very elegant way of doing it. (C++ now has concepts, but I haven't taken the time yet to see how they compare with type classes.)

I was also used to function overloading, which is somewhat similar to type inference, in that the compiler will pick an implementation based on the types of a function's arguments. This is similar to Haskell picking an implementation from among type class instances. However, what blew me away is that Haskell can overload based on *return type* as well as argument types. I haven't seen any other production-ready language that can do this. A great example of how this is useful is the regex library, where you can select from among widely varying styles of regex matching result simply by type inference, ie without needing any type annotation.

There were a *lot* of other things I found amazing, but others have covered many of these already. Also, languages are borrowing from each other at a rapid rate these days (eg Rust traits are equivalent to type classes) so it's hard to find a "killer feature" in Haskell any more (except laziness, perhaps). I think it's more the well-balanced combination of all the features that makes Haskell so pleasant to work in, and it's hard to demonstrate all of these in a single example.

My own favourite "gem" is this code for computing all primes, based on code in a paper[1] by Doug McIlroy:

primes = sieve [2..] where sieve (p : ns) = p : sieve [n | n <- ns, n `mod` p /= 0]

I think care must be exercised, when using examples like this one, to avoid giving the impression that Haskell is a "toy" language. However, what I find interesting about this example is that all other sieve implementations I've seen work on a fixed size of sieve up front, and if you later change your mind about how many primes you want, eg because you're expanding a hash table and want a bigger prime for the size, you typically have to start the sieve from scratch again.

[1]: http://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.dartmouth.edu%2F~doug%2Fsieve%2Fsieve.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7Cce59cb95fe304d442b8d08d5e7490739%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636669223196857658&sdata=1UGE8hoL8B9yMjXqJbe5HV%2FsAXlpoB653kePOrgpCNY%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/3ab5fd84/attachment.html>

From vanessa.mchale at iohk.io  Wed Jul 11 16:40:29 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Wed, 11 Jul 2018 11:40:29 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB030832C8CAA921B2B41DC879AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <e5c986f5-8a56-a220-6f36-53abe6f3f352@users.sourceforge.net>
 <AM0PR83MB030832C8CAA921B2B41DC879AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <e6ec7417-647e-8fbc-c5c1-0ce6cfdb0ef6@iohk.io>

Idris allows such abstractions in much the same way Haskell does. ATS
allows monads via template (see e.g.
https://github.com/githwxi/ATS-Postiats/blob/e83a467485857d568e20512b486ee52b4b4da97a/libats/ML/DATS/SHARE/monad.hats)
but they're kind of broken in practice in that you can have only
instance per executable/library (!)


On 07/11/2018 11:24 AM, Simon Peyton Jones via Haskell-Cafe wrote:
>
> Also, languages are borrowing from each other at a rapid rate these
> days (eg Rust traits are equivalent to type classes) so it's hard to
> find a "killer feature" in Haskell any more
>
>  
>
> That’s true, and to be celebrated!
>
>  
>
> One thing that stands our for me is the ability to abstract over type
> *constructors*:
>
>             f :: forall (m :: * -> *) (a :: *). Monad m => a -> m a
>
>  
>
> That ability is what has given rise to a stunningly huge collection of
> abstractions: not just Monad, but Functor, Applicative, Traversable,
> Foldable, etc etc etc.   Really a lot.  It opens up a new way to think
> about the world.  But only made possible by that one feature.   (Plus
> type classes of course.)
>
>  
>
> Do any statically typed languages other than Haskell and Scala do this?
>
>  
>
> Simon
>
>  
>
> *From:*Haskell-Cafe <haskell-cafe-bounces at haskell.org> *On Behalf Of
> *Neil Mayhew
> *Sent:* 11 July 2018 17:12
> *To:* Haskell Cafe <haskell-cafe at haskell.org>
> *Subject:* Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?
>
>  
>
> I came to Haskell from C++, and I was used to the idea of parametric
> types and functions from C++ templates.
>
> However, what I really liked about Haskell's way of doing these was
> that, due to type inference, not only is there a lot less ceremony
> involved, but code is generic (parametric) *by default*, and thus much
> more reusable, although you still have the option of tightening it up
> by adding a type annotation (eg for performance reasons). For a while,
> I was writing all my C++ code as templates, but this ended up being a
> pain.
>
> Also, traditionally C++ has not allowed you to place any constraints
> on template arguments (type parameters) whereas Haskell's type classes
> are a very elegant way of doing it. (C++ now has concepts, but I
> haven't taken the time yet to see how they compare with type classes.)
>
> I was also used to function overloading, which is somewhat similar to
> type inference, in that the compiler will pick an implementation based
> on the types of a function's arguments. This is similar to Haskell
> picking an implementation from among type class instances. However,
> what blew me away is that Haskell can overload based on *return type*
> as well as argument types. I haven't seen any other production-ready
> language that can do this. A great example of how this is useful is
> the regex library, where you can select from among widely varying
> styles of regex matching result simply by type inference, ie without
> needing any type annotation.
>
> There were a *lot* of other things I found amazing, but others have
> covered many of these already. Also, languages are borrowing from each
> other at a rapid rate these days (eg Rust traits are equivalent to
> type classes) so it's hard to find a "killer feature" in Haskell any
> more (except laziness, perhaps). I think it's more the well-balanced
> combination of all the features that makes Haskell so pleasant to work
> in, and it's hard to demonstrate all of these in a single example.
>
> My own favourite "gem" is this code for computing all primes, based on
> code in a paper[1] by Doug McIlroy:
>
> primes = sieve [2..] where sieve (p : ns) = p : sieve [n | n <- ns, n
> `mod` p /= 0]
>
> I think care must be exercised, when using examples like this one, to
> avoid giving the impression that Haskell is a "toy" language. However,
> what I find interesting about this example is that all other sieve
> implementations I've seen work on a fixed size of sieve up front, and
> if you later change your mind about how many primes you want, eg
> because you're expanding a hash table and want a bigger prime for the
> size, you typically have to start the sieve from scratch again.
>
> [1]: http://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf
> <https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.dartmouth.edu%2F%7Edoug%2Fsieve%2Fsieve.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7Cce59cb95fe304d442b8d08d5e7490739%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636669223196857658&sdata=1UGE8hoL8B9yMjXqJbe5HV%2FsAXlpoB653kePOrgpCNY%3D&reserved=0>
>
>
>
> _______________________________________________
> 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/20180711/fc0009d3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/fc0009d3/attachment.sig>

From david.feuer at gmail.com  Wed Jul 11 17:09:55 2018
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 11 Jul 2018 13:09:55 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB030832C8CAA921B2B41DC879AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <e5c986f5-8a56-a220-6f36-53abe6f3f352@users.sourceforge.net>
 <AM0PR83MB030832C8CAA921B2B41DC879AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAMgWh9v-OowvTWmvckDwhrOUKhvb0KV_NKcZZ6qCeSDUZUci0w@mail.gmail.com>

Haskell is the only language I know of with typeclass coherence.

On Wed, Jul 11, 2018, 12:25 PM Simon Peyton Jones via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Also, languages are borrowing from each other at a rapid rate these days
> (eg Rust traits are equivalent to type classes) so it's hard to find a
> "killer feature" in Haskell any more
>
>
>
> That’s true, and to be celebrated!
>
>
>
> One thing that stands our for me is the ability to abstract over type
> *constructors*:
>
>             f :: forall (m :: * -> *) (a :: *). Monad m => a -> m a
>
>
>
> That ability is what has given rise to a stunningly huge collection of
> abstractions: not just Monad, but Functor, Applicative, Traversable,
> Foldable, etc etc etc.   Really a lot.  It opens up a new way to think
> about the world.  But only made possible by that one feature.   (Plus type
> classes of course.)
>
>
>
> Do any statically typed languages other than Haskell and Scala do this?
>
>
>
> Simon
>
>
>
> *From:* Haskell-Cafe <haskell-cafe-bounces at haskell.org> *On Behalf Of *Neil
> Mayhew
> *Sent:* 11 July 2018 17:12
> *To:* Haskell Cafe <haskell-cafe at haskell.org>
> *Subject:* Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?
>
>
>
> I came to Haskell from C++, and I was used to the idea of parametric types
> and functions from C++ templates.
>
> However, what I really liked about Haskell's way of doing these was that,
> due to type inference, not only is there a lot less ceremony involved, but
> code is generic (parametric) *by default*, and thus much more reusable,
> although you still have the option of tightening it up by adding a type
> annotation (eg for performance reasons). For a while, I was writing all my
> C++ code as templates, but this ended up being a pain.
>
> Also, traditionally C++ has not allowed you to place any constraints on
> template arguments (type parameters) whereas Haskell's type classes are a
> very elegant way of doing it. (C++ now has concepts, but I haven't taken
> the time yet to see how they compare with type classes.)
>
> I was also used to function overloading, which is somewhat similar to type
> inference, in that the compiler will pick an implementation based on the
> types of a function's arguments. This is similar to Haskell picking an
> implementation from among type class instances. However, what blew me away
> is that Haskell can overload based on *return type* as well as argument
> types. I haven't seen any other production-ready language that can do this.
> A great example of how this is useful is the regex library, where you can
> select from among widely varying styles of regex matching result simply by
> type inference, ie without needing any type annotation.
>
> There were a *lot* of other things I found amazing, but others have
> covered many of these already. Also, languages are borrowing from each
> other at a rapid rate these days (eg Rust traits are equivalent to type
> classes) so it's hard to find a "killer feature" in Haskell any more
> (except laziness, perhaps). I think it's more the well-balanced combination
> of all the features that makes Haskell so pleasant to work in, and it's
> hard to demonstrate all of these in a single example.
>
> My own favourite "gem" is this code for computing all primes, based on
> code in a paper[1] by Doug McIlroy:
>
> primes = sieve [2..] where sieve (p : ns) = p : sieve [n | n <- ns, n
> `mod` p /= 0]
>
> I think care must be exercised, when using examples like this one, to
> avoid giving the impression that Haskell is a "toy" language. However, what
> I find interesting about this example is that all other sieve
> implementations I've seen work on a fixed size of sieve up front, and if
> you later change your mind about how many primes you want, eg because
> you're expanding a hash table and want a bigger prime for the size, you
> typically have to start the sieve from scratch again.
>
> [1]: http://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf
> <https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.dartmouth.edu%2F~doug%2Fsieve%2Fsieve.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7Cce59cb95fe304d442b8d08d5e7490739%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636669223196857658&sdata=1UGE8hoL8B9yMjXqJbe5HV%2FsAXlpoB653kePOrgpCNY%3D&reserved=0>
> _______________________________________________
> 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/20180711/fbe5b33b/attachment.html>

From Henrik.Nilsson at nottingham.ac.uk  Wed Jul 11 17:25:02 2018
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Wed, 11 Jul 2018 18:25:02 +0100
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <e684e2b1-0eb2-bae3-bbd8-9f57987e2698@iohk.io>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <e684e2b1-0eb2-bae3-bbd8-9f57987e2698@iohk.io>
Message-ID: <5B463D6E.6040507@exmail.nottingham.ac.uk>

Hi,

On 07/11/2018 02:46 PM, Vanessa McHale wrote:
> #2: enumerate all strings on an alphabet (this uses laziness!)
>
>
> allStrings :: [a] -> [[a]] allStrings = sequence <=< (inits . repeat)
>

Neat!

I find the following alternative appealing too, as it in essence
just states a recursive equation that says what it means for
a list to be a list of all strings over the given alphabet:

allStrings alphabet = xss
     where xss = [] : [ x : xs | xs <- xss, x <- alphabet ]

(Admittedly, one has to be careful with the ordering of the generators,
or the order in which the strings are enumerated becomes less useful.)

This capability of declaratively stating an equation that characterises
the sought answer is another perspective on why techniques like
dynamic programming is such a great fit for lazy languages, as
pointed out by Jake.

One of my favourite examples is finding a minimal length triangulation
of a polygon where an elegant solution is obtained by just
transliterating the defining equations from a classic textbook on data
structures and algorithms (Aho, Hopcroft, Ullman 1983).

Attribute grammar evaluation is another great application of laziness
in a similar vein.

Best,

/Henrik




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.





From cdsmith at gmail.com  Wed Jul 11 17:39:30 2018
From: cdsmith at gmail.com (Chris Smith)
Date: Wed, 11 Jul 2018 13:39:30 -0400
Subject: [Haskell-cafe] Investing in languages
In-Reply-To: <jwv601l7qxt.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <jwv601l7qxt.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
Message-ID: <CAPq5PvJtDLXeZcjofx1stXz=h3HAmav1ZFx0J=DGFyAx-mcizA@mail.gmail.com>

I think it's important to keep in mind that the correct trade-off for one
situation is not the correct trade-off for another.  This is a great
example!  On one side of the spectrum, you've got situations where Idris or
Agda are good fits, where it's critically important to know that code is
correct, even at the expense of significant complexity or time.  But there
is another side of that spectrum.  It's probably best characterized by
education: there are no users, bugs that aren't found don't matter at all,
and even when you know for sure that something is wrong, it would be great
if you can let it fail and *watch* it go wrong; stopping someone who's
learning to tell them they got something wrong before they understand WHY
is bad teaching.

I've been working for years now on using (a variant of) Haskell in early
education, as young as 10 to 11 years old.  Looking at this experience, I
agree whole-heartedly that regardless of what's best in a professional
setting, there's still something about Haskell that's far more difficult to
learn than Python and Java.  It's not about the incidental complexity of
the language, which can usually be avoided.  It's about the way everything
just looks so easy once it's written, but new programmers struggle mightily
to figure out how to get started in writing it.  People don't understand
how to build things compositionally.

As an aside: I know it's popular among the functional programming world to
hypothesize that this is because people have used imperative languages
first.  I can tell you, though, that the hypothesis is wrong.  I spend a
good bit of my time teaching students with no previous programming
experience in any language.  They also struggle with it, but they
understand imperative programming intuitively.  Mathematics teachers also
know this, and it's why they so often fall back to teaching step-by-step
processes instead of talking about subexpressions having meaning.  Think
about how you learned the "order of operations", which obviously should be
understood as a question of parsing and identifying subexpressions, but is
always taught as "you multiply before you add" because that's what gets
correct answers on exams.

Incidentally, realizing this makes me more determined to teach Haskell and
compositional thinking at a younger age.  It might not be easy, but you
don't get far in mathematics without grasping the idea of building up
abstract objects through composition.  This shift from thinking about "how
to get it done" to thinking about "what it means" is a huge step toward
understanding the world around us, and should be pretty far up on the
priority list.  So I'm not badmouthing Haskell here.  I'm just saying we
should realize that there's a very real sense in which it is legitimately
HARDER to understand.  No use being in denial about that.

On Wed, Jul 11, 2018 at 11:10 AM Stefan Monnier <monnier at iro.umontreal.ca>
wrote:

> > but functional programming is harder.
>
> There's no doubt that languages like Haskell go through extra efforts to
> make it *harder* to write incorrect code, and along the way they also
> make it harder to write code at all.
>
> So maybe it will take your guy a week to get the code written in
> Haskell, whereas a couple days were sufficient in Java.  But that's
> without counting the subsequent month during which the Java code will
> have to be debugged before it actually works ;-)
>
> IIRC it was Bob Harper who said a good programming language should be
> hard to write (but easy to read, of course)?
>
>
>         Stefan
>
> _______________________________________________
> 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/20180711/40ee6842/attachment-0001.html>

From olf at aatal-apotheke.de  Wed Jul 11 18:34:57 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Wed, 11 Jul 2018 20:34:57 +0200
Subject: [Haskell-cafe]  What is your favourite Haskell "aha" moment?
Message-ID: <AC827C09-EA1B-4A5F-AD94-85B6CAC2AA38@aatal-apotheke.de>

Dear Simon,

since you'll be talking to genomics people, you might want to look at a Bachelor thesis about sequence alignment [1]. The author is a PhD student in Cambridge now. 
In a nutshell, the ListT monad transformer [2] is a good abstraction for full-text index structures [*] that are in heavy use among the genomics people. ListT represents the basic state transformation when a symbol is added to the query string. It also facilitates alignment of sequences with uncertain values [+]. Swapping out the monad lets you change the model of uncertainty, but you write your algorithm only once. I can provide code if required.

The edit distance algorithm [3] might also go down well at Sanger. It is an example where lazyness and subtle re-arrangement turns a quadratic algorithm into an optimal one. 

Olaf

[1] https://pp.ipd.kit.edu/uploads/publikationen/kuhnle13bachelorarbeit.pdf
[2] http://hackage.haskell.org/package/list-t
[3] http://users.monash.edu/~lloyd/tildeStrings/Alignment/92.IPL.html 
[*] Burrows-Wheeler transform, FM-index, suffix arrays, suffix trees, etc. 
[+] Current index structures hold only one sequence, while known genomic polymorphisms are stored separately.

From olf at aatal-apotheke.de  Wed Jul 11 19:15:54 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Wed, 11 Jul 2018 21:15:54 +0200
Subject: [Haskell-cafe] higher kind in parametric type
In-Reply-To: <85601l2697.fsf@UU.FStaals.net>
References: <1406945848.383451.1531318625154@webmail.strato.de>
 <85601l2697.fsf@UU.FStaals.net>
Message-ID: <98A37F0E-96DB-48DD-9D99-0C4067A440D3@aatal-apotheke.de>


> Am 11.07.2018 um 16:31 schrieb Frank Staals <frank at fstaals.net>:
> 
> Olaf Klinke <olf at aatal-apotheke.de> writes:
> 
>> Dear cafe,
>> 
>> I am writing a library for parsing higher-kinded data, based on the czipwith package [1]. I ran into the following problem.
>> 
>> I have a type class
>> class Config p f | f -> p where
>>    f :: (* -> *) -> *
>> is the higher-kinded data and
>>    p :: * -> *
>> is the associated parser type.
>> 
>> I want to add a class member that does not mention f in its type, e.g. 
>> 
>> heading :: p String
>> 
>> Naturally, this would lead to ambiguity checks to fail, as the usage of heading does not tell which Config instance to use. My usual workaround would be to wrap `heading` in a phantom type, e.g.
>>    data Heading f p = Heading (p String)
>> and give `heading` the type Heading f p. However, ghc-8.0.2 complains about f not being a type:
>> 
>>    • Expecting one more argument to ‘f’
>>      Expected a type, but ‘f’ has kind ‘(* -> *) -> *’
>>    • In the first argument of ‘Heading’, namely ‘f’
>>      In the type signature:
>>        heading :: Heading f p
>>      In the class declaration for ‘Config’
>> 
>> Is there a restriction of the kinds that can be used in parametric types?
>> 
>> Cheers,
>> Olaf
>> 
>> [1] http://hackage.haskell.org/package/czipwith
> 
> I think you can just a kind signature to 'f' in your Heading
> datatype. I.e. the following seems to compile/typecheck here:
> 
> 
> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE FunctionalDependencies #-}
> {-# LANGUAGE KindSignatures #-}
> {-# LANGUAGE PolyKinds #-}
> 
> newtype Heading (f :: k) (p :: * -> *) = Heading (p String)
> 
> 
> class Config (p :: * -> *) (f :: (* -> *) -> *) | f -> p where
>  foo :: Heading f p -> String
> 
> 
You solved it, Frank, thanks a lot! 

Actually, it seems that this line makes all the difference:
{-# LANGUAGE PolyKinds #-}

In ghc-7.4.2 my code compiles with the pragma, and yields the above error message without. Usually the compiler is kind enough to suggest adding the language extension when encountering an error. This time it didn't. Maybe this is a case for the ghc developers? 

Olaf


From doaitse at swierstra.net  Wed Jul 11 19:17:54 2018
From: doaitse at swierstra.net (Doaitse Swierstra)
Date: Wed, 11 Jul 2018 21:17:54 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <B4E3C0B9-5FC8-4BAB-9EC8-BCDB58E8A0B5@swierstra.net>

[Shameless promotion]

I once wrote a parser combinator library. Something everyone does once in his life ;-}

Then I realised that I could run parsers in an interleaved way, and wrote the package uu-interleaved”. In remarkably few lines of code this can turn a parser combinator library in a a library that can run parsers in an interleavedway . If you look at the code in:

http://hackage.haskell.org/package/uu-interleaved-0.2.0.1/docs/src/Control.Applicative.Interleaved.html

this boils down to writing a few instances for a new data type. Although the code is intricate it is very short, and the types guided me get the code correct. Without te types I would have spent ages in getting things to work.

The I realised that by adding just a few extra lines of code this could be turned in a package for writing code for dealing with command line arguments in a very broad sense: repeating arguments, dealing with missing obligatory arguments, optional arguments and parsing the arguments according to what they stand for and reporting errors in the command line in a systematic way 

Surprisingly the  the code of this package is probably less that what an ordinary program spends on processing it's command line arguments, while providing much larger security.

 [End of shameless promotion]

If your audience consists of experienced programmers they must have been spending quite some time on code that is no longer necessary when using such a package.

 Doaitse







> Op 11 jul. 2018, om 14:10  heeft Simon Peyton Jones via Haskell-Cafe <haskell-cafe at haskell.org> het volgende geschreven:
> 
> Friends
> 
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of programming, but they aren’t computer scientists.
> 
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the main question in their minds: why should I even care about Haskell?  I’m too much of a biased witness.
> 
> 
> So I thought I’d ask you for help.  War stories perhaps – how using Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d love to illustrate with copious examples of beautiful code. 
> 
> Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about?   Something that gave you an “aha” moment, or that feeling of joy when you truly make sense of something for the first time.
> The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn’t going to do it for them.  I need examples that I can present in 5 minutes, without needing a long setup.
> 
> To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C.  It’s so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc.  But it also makes much less good use of memory, and is likely to run slower.  I think I can do that in 5 minutes.
> 
> Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
> 
> But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done.
> 
> Pointers to your favourite blog posts would be another avenue.  (I love the Haskell Weekly News.)
> 
> Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience.
> 
> Thank you!  Perhaps your responses on this thread (if any) may be helpful to more than just me.
> 
> Simon
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/2f8dfc83/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ParseYourOptions.pdf
Type: application/pdf
Size: 278476 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/2f8dfc83/attachment-0001.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/2f8dfc83/attachment-0003.html>

From scott.fleischman at plowtech.net  Wed Jul 11 19:31:17 2018
From: scott.fleischman at plowtech.net (Scott Fleischman)
Date: Wed, 11 Jul 2018 12:31:17 -0700
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAHu-nNK4dC5XEKBU_baQweyRBGGh+GVhCqz7D4u_cJA7M_QjiA@mail.gmail.com>

We make extensive use of Servant for our web services at Plow Technologies.
It is my favorite example of the success of using types (even relatively
fancy types) to help with a common problem (creating web sites with web
services) and reduce boilerplate.

I like the examples in the tutorial
<https://haskell-servant.readthedocs.io/en/stable/tutorial/index.html>.

Scott Fleischman


On Wed, Jul 11, 2018 at 5:10 AM, Simon Peyton Jones via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> main question in their minds: *why should I even care about Haskell*?
> I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
> love to illustrate with copious examples of beautiful code.
>
>    - Can you identify a few lines of Haskell that best characterise what
>    you think makes Haskell distinctively worth caring about?   Something that
>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>    of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell, so
> muttering about Cartesian Closed Categories isn’t going to do it for them.
> I need examples that I can present in 5 minutes, without needing a long
> setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in C
> notoriously prone to fencepost errors etc.  But it also makes much less
> good use of memory, and is likely to run slower.  I think I can do that in
> 5 minutes.
>
> Another thing that I think comes over easily is the ability to abstract:
> generalising sum and product to fold by abstracting out a functional
> argument; generalising at the type level by polymorphism, including
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>
> But you will have more and better ideas, and (crucially) ideas that are
> more credibly grounded in the day to day reality of writing programs that
> get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I love
> the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant for
> the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be helpful
> to more than just me.
>
> Simon
>
> _______________________________________________
> 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/20180711/4f33a1b1/attachment.html>

From cdsmith at gmail.com  Wed Jul 11 19:39:42 2018
From: cdsmith at gmail.com (Chris Smith)
Date: Wed, 11 Jul 2018 15:39:42 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CAHu-nNK4dC5XEKBU_baQweyRBGGh+GVhCqz7D4u_cJA7M_QjiA@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHu-nNK4dC5XEKBU_baQweyRBGGh+GVhCqz7D4u_cJA7M_QjiA@mail.gmail.com>
Message-ID: <CAPq5PvK3H_pkGFJFm9Y8q5i+7Qf=w-zjhvcG+joPiwJ-n3t0+Q@mail.gmail.com>

I feel like the one theme that's been missing in all of this is the
interaction between equational reasoning and rewrite rules.  Examples of
fusing operations on Text or ByteString were pretty impressive to me.  The
ideas may be incorporated into other languages, but I believe Haskell
is pretty unique, at least versus mainstream languages, in doing the fusion
in the optimizer where there's still opportunity for the results to be
inlined and further optimized.

I don't have a complete example off the top of my head.

On Wed, Jul 11, 2018 at 3:31 PM Scott Fleischman <
scott.fleischman at plowtech.net> wrote:

> We make extensive use of Servant for our web services at Plow
> Technologies. It is my favorite example of the success of using types (even
> relatively fancy types) to help with a common problem (creating web sites
> with web services) and reduce boilerplate.
>
> I like the examples in the tutorial
> <https://haskell-servant.readthedocs.io/en/stable/tutorial/index.html>.
>
> Scott Fleischman
>
>
> On Wed, Jul 11, 2018 at 5:10 AM, Simon Peyton Jones via Haskell-Cafe <
> haskell-cafe at haskell.org> wrote:
>
>> Friends
>>
>> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
>> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
>> programming, but they aren’t computer scientists.
>>
>> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
>> main question in their minds: *why should I even care about Haskell*?
>> I’m too much of a biased witness.
>>
>> So I thought I’d ask you for help.  War stories perhaps – how using
>> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
>> love to illustrate with copious examples of beautiful code.
>>
>>    - Can you identify a few lines of Haskell that best characterise what
>>    you think makes Haskell distinctively worth caring about?   Something that
>>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>>    of something for the first time.
>>
>> The challenge is, of course, that this audience will know no Haskell, so
>> muttering about Cartesian Closed Categories isn’t going to do it for them.
>> I need examples that I can present in 5 minutes, without needing a long
>> setup.
>>
>> To take a very basic example, consider Quicksort using list
>> comprehensions, compared with its equivalent in C.  It’s so short, so
>> obviously right, whereas doing the right thing with in-place update in C
>> notoriously prone to fencepost errors etc.  But it also makes much less
>> good use of memory, and is likely to run slower.  I think I can do that in
>> 5 minutes.
>>
>> Another thing that I think comes over easily is the ability to abstract:
>> generalising sum and product to fold by abstracting out a functional
>> argument; generalising at the type level by polymorphism, including
>> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>>
>> But you will have more and better ideas, and (crucially) ideas that are
>> more credibly grounded in the day to day reality of writing programs that
>> get work done.
>>
>> Pointers to your favourite blog posts would be another avenue.  (I love
>> the Haskell Weekly News.)
>>
>> Finally, I know that some of you use Haskell specifically for genomics
>> work, and maybe some of your insights would be particularly relevant for
>> the Sanger audience.
>>
>> Thank you!  Perhaps your responses on this thread (if any) may be helpful
>> to more than just me.
>>
>> Simon
>>
>> _______________________________________________
>> 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/20180711/ed5e53ce/attachment.html>

From vanessa.mchale at iohk.io  Wed Jul 11 19:42:22 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Wed, 11 Jul 2018 14:42:22 -0500
Subject: [Haskell-cafe] higher kind in parametric type
In-Reply-To: <98A37F0E-96DB-48DD-9D99-0C4067A440D3@aatal-apotheke.de>
References: <1406945848.383451.1531318625154@webmail.strato.de>
 <85601l2697.fsf@UU.FStaals.net>
 <98A37F0E-96DB-48DD-9D99-0C4067A440D3@aatal-apotheke.de>
Message-ID: <3291254e-326a-cd1a-8b92-11271df8a1aa@iohk.io>

It seems to work with the latest GHC (8.4.3). GHC 7.4.2 is six years old :)


On 07/11/2018 02:15 PM, Olaf Klinke wrote:
> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE FunctionalDependencies #-}
> {-# LANGUAGE KindSignatures #-}
> {-# LANGUAGE PolyKinds #-}
>
> newtype Heading (f :: k) (p :: * -> *) = Heading (p String)
>
>
> class Config (p :: * -> *) (f :: (* -> *) -> *) | f -> p where
>  foo :: Heading f p -> String
>

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

From jeffbrown.the at gmail.com  Wed Jul 11 19:50:44 2018
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Wed, 11 Jul 2018 14:50:44 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CAPq5PvK3H_pkGFJFm9Y8q5i+7Qf=w-zjhvcG+joPiwJ-n3t0+Q@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHu-nNK4dC5XEKBU_baQweyRBGGh+GVhCqz7D4u_cJA7M_QjiA@mail.gmail.com>
 <CAPq5PvK3H_pkGFJFm9Y8q5i+7Qf=w-zjhvcG+joPiwJ-n3t0+Q@mail.gmail.com>
Message-ID: <CAEc4Ma3vP3Dz62Ma9Q91QK74mzTeSE=8bbyfuw80nWpsQMt7aw@mail.gmail.com>

"Blow your mind" on the Haskell Wiki[1] is a collection of short bits of
awesome code.

[1] https://wiki.haskell.org/Blow_your_mind

On Wed, Jul 11, 2018 at 2:40 PM Chris Smith <cdsmith at gmail.com> wrote:

> I feel like the one theme that's been missing in all of this is the
> interaction between equational reasoning and rewrite rules.  Examples of
> fusing operations on Text or ByteString were pretty impressive to me.  The
> ideas may be incorporated into other languages, but I believe Haskell
> is pretty unique, at least versus mainstream languages, in doing the fusion
> in the optimizer where there's still opportunity for the results to be
> inlined and further optimized.
>
> I don't have a complete example off the top of my head.
>
> On Wed, Jul 11, 2018 at 3:31 PM Scott Fleischman <
> scott.fleischman at plowtech.net> wrote:
>
>> We make extensive use of Servant for our web services at Plow
>> Technologies. It is my favorite example of the success of using types (even
>> relatively fancy types) to help with a common problem (creating web sites
>> with web services) and reduce boilerplate.
>>
>> I like the examples in the tutorial
>> <https://haskell-servant.readthedocs.io/en/stable/tutorial/index.html>.
>>
>> Scott Fleischman
>>
>>
>> On Wed, Jul 11, 2018 at 5:10 AM, Simon Peyton Jones via Haskell-Cafe <
>> haskell-cafe at haskell.org> wrote:
>>
>>> Friends
>>>
>>> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
>>> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
>>> programming, but they aren’t computer scientists.
>>>
>>> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
>>> main question in their minds: *why should I even care about Haskell*?
>>> I’m too much of a biased witness.
>>>
>>> So I thought I’d ask you for help.  War stories perhaps – how using
>>> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
>>> love to illustrate with copious examples of beautiful code.
>>>
>>>    - Can you identify a few lines of Haskell that best characterise
>>>    what you think makes Haskell distinctively worth caring about?   Something
>>>    that gave you an “aha” moment, or that feeling of joy when you truly make
>>>    sense of something for the first time.
>>>
>>> The challenge is, of course, that this audience will know no Haskell, so
>>> muttering about Cartesian Closed Categories isn’t going to do it for them.
>>> I need examples that I can present in 5 minutes, without needing a long
>>> setup.
>>>
>>> To take a very basic example, consider Quicksort using list
>>> comprehensions, compared with its equivalent in C.  It’s so short, so
>>> obviously right, whereas doing the right thing with in-place update in C
>>> notoriously prone to fencepost errors etc.  But it also makes much less
>>> good use of memory, and is likely to run slower.  I think I can do that in
>>> 5 minutes.
>>>
>>> Another thing that I think comes over easily is the ability to abstract:
>>> generalising sum and product to fold by abstracting out a functional
>>> argument; generalising at the type level by polymorphism, including
>>> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>>>
>>> But you will have more and better ideas, and (crucially) ideas that are
>>> more credibly grounded in the day to day reality of writing programs that
>>> get work done.
>>>
>>> Pointers to your favourite blog posts would be another avenue.  (I love
>>> the Haskell Weekly News.)
>>>
>>> Finally, I know that some of you use Haskell specifically for genomics
>>> work, and maybe some of your insights would be particularly relevant for
>>> the Sanger audience.
>>>
>>> Thank you!  Perhaps your responses on this thread (if any) may be
>>> helpful to more than just me.
>>>
>>> Simon
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Jeff Brown | Jeffrey Benjamin Brown
Website <https://msu.edu/~brown202/>   |   Facebook
<https://www.facebook.com/mejeff.younotjeff>   |   LinkedIn
<https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss
messages here)   |   Github <https://github.com/jeffreybenjaminbrown>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/93c18e75/attachment.html>

From lysxia at gmail.com  Wed Jul 11 19:53:11 2018
From: lysxia at gmail.com (Li-yao Xia)
Date: Wed, 11 Jul 2018 15:53:11 -0400
Subject: [Haskell-cafe] higher kind in parametric type
In-Reply-To: <98A37F0E-96DB-48DD-9D99-0C4067A440D3@aatal-apotheke.de>
References: <1406945848.383451.1531318625154@webmail.strato.de>
 <85601l2697.fsf@UU.FStaals.net>
 <98A37F0E-96DB-48DD-9D99-0C4067A440D3@aatal-apotheke.de>
Message-ID: <1e9bf549-025c-dc9b-8ac8-57f01a335c4f@gmail.com>



On 07/11/2018 03:15 PM, Olaf Klinke wrote:
> 
>> Am 11.07.2018 um 16:31 schrieb Frank Staals <frank at fstaals.net>:
>>
>> I think you can just a kind signature to 'f' in your Heading
>> datatype. I.e. the following seems to compile/typecheck here:
>>
>>
>> {-# LANGUAGE MultiParamTypeClasses #-}
>> {-# LANGUAGE FunctionalDependencies #-}
>> {-# LANGUAGE KindSignatures #-}
>> {-# LANGUAGE PolyKinds #-}
>>
>> newtype Heading (f :: k) (p :: * -> *) = Heading (p String)
>>
>>
>> class Config (p :: * -> *) (f :: (* -> *) -> *) | f -> p where
>>   foo :: Heading f p -> String
>>
>>
> You solved it, Frank, thanks a lot!
> 
> Actually, it seems that this line makes all the difference:
> {-# LANGUAGE PolyKinds #-}
> 
> In ghc-7.4.2 my code compiles with the pragma, and yields the above error message without. Usually the compiler is kind enough to suggest adding the language extension when encountering an error. This time it didn't. Maybe this is a case for the ghc developers?
> 

Hello,

There is also a solution without the PolyKinds extension:

newtype Heading (f :: (* -> *) -> *) (p :: * -> *) = ...

I think the error message could be improved here but should probably not 
recommend the PolyKinds extension because it has a few surprising 
behaviors (IIRC it can break existing code, though I don't have an 
example off-hand). A safer alternative is to encourage kind annotations 
on higher-kinded types, that also mirrors the existing practice of 
giving signatures to toplevel functions.

Li-yao

From tanuki at gmail.com  Wed Jul 11 21:46:34 2018
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Wed, 11 Jul 2018 14:46:34 -0700
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CAEc4Ma3vP3Dz62Ma9Q91QK74mzTeSE=8bbyfuw80nWpsQMt7aw@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHu-nNK4dC5XEKBU_baQweyRBGGh+GVhCqz7D4u_cJA7M_QjiA@mail.gmail.com>
 <CAPq5PvK3H_pkGFJFm9Y8q5i+7Qf=w-zjhvcG+joPiwJ-n3t0+Q@mail.gmail.com>
 <CAEc4Ma3vP3Dz62Ma9Q91QK74mzTeSE=8bbyfuw80nWpsQMt7aw@mail.gmail.com>
Message-ID: <CAJoPsuCLT3AmTVSqDo0X_2xt_UjWD3MBwuppJO8wB=-SG4urCg@mail.gmail.com>

Gabriel Gonzalez's "Haskell for Everyone" blog is a wellspring of great
candidates. This one came up in another thread yesterday, as an example of
what you can get from treating IO actions as data:
http://www.haskellforall.com/2018/02/the-wizard-monoid.html

On Wed, Jul 11, 2018, 12:51 PM Jeffrey Brown <jeffbrown.the at gmail.com>
wrote:

> "Blow your mind" on the Haskell Wiki[1] is a collection of short bits of
> awesome code.
>
> [1] https://wiki.haskell.org/Blow_your_mind
>
> On Wed, Jul 11, 2018 at 2:40 PM Chris Smith <cdsmith at gmail.com> wrote:
>
>> I feel like the one theme that's been missing in all of this is the
>> interaction between equational reasoning and rewrite rules.  Examples of
>> fusing operations on Text or ByteString were pretty impressive to me.  The
>> ideas may be incorporated into other languages, but I believe Haskell
>> is pretty unique, at least versus mainstream languages, in doing the fusion
>> in the optimizer where there's still opportunity for the results to be
>> inlined and further optimized.
>>
>> I don't have a complete example off the top of my head.
>>
>> On Wed, Jul 11, 2018 at 3:31 PM Scott Fleischman <
>> scott.fleischman at plowtech.net> wrote:
>>
>>> We make extensive use of Servant for our web services at Plow
>>> Technologies. It is my favorite example of the success of using types (even
>>> relatively fancy types) to help with a common problem (creating web sites
>>> with web services) and reduce boilerplate.
>>>
>>> I like the examples in the tutorial
>>> <https://haskell-servant.readthedocs.io/en/stable/tutorial/index.html>.
>>>
>>> Scott Fleischman
>>>
>>>
>>> On Wed, Jul 11, 2018 at 5:10 AM, Simon Peyton Jones via Haskell-Cafe <
>>> haskell-cafe at haskell.org> wrote:
>>>
>>>> Friends
>>>>
>>>> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
>>>> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
>>>> programming, but they aren’t computer scientists.
>>>>
>>>> I can tell them plenty about Haskell, but I’m ill-equipped to answer
>>>> the main question in their minds: *why should I even care about
>>>> Haskell*?  I’m too much of a biased witness.
>>>>
>>>> So I thought I’d ask you for help.  War stories perhaps – how using
>>>> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
>>>> love to illustrate with copious examples of beautiful code.
>>>>
>>>>    - Can you identify a few lines of Haskell that best characterise
>>>>    what you think makes Haskell distinctively worth caring about?   Something
>>>>    that gave you an “aha” moment, or that feeling of joy when you truly make
>>>>    sense of something for the first time.
>>>>
>>>> The challenge is, of course, that this audience will know no Haskell,
>>>> so muttering about Cartesian Closed Categories isn’t going to do it for
>>>> them.  I need examples that I can present in 5 minutes, without needing a
>>>> long setup.
>>>>
>>>> To take a very basic example, consider Quicksort using list
>>>> comprehensions, compared with its equivalent in C.  It’s so short, so
>>>> obviously right, whereas doing the right thing with in-place update in C
>>>> notoriously prone to fencepost errors etc.  But it also makes much less
>>>> good use of memory, and is likely to run slower.  I think I can do that in
>>>> 5 minutes.
>>>>
>>>> Another thing that I think comes over easily is the ability to
>>>> abstract: generalising sum and product to fold by abstracting out a
>>>> functional argument; generalising at the type level by polymorphism,
>>>> including polymorphism over higher-kinded type constructors.   Maybe 8
>>>> minutes.
>>>>
>>>> But you will have more and better ideas, and (crucially) ideas that are
>>>> more credibly grounded in the day to day reality of writing programs that
>>>> get work done.
>>>>
>>>> Pointers to your favourite blog posts would be another avenue.  (I love
>>>> the Haskell Weekly News.)
>>>>
>>>> Finally, I know that some of you use Haskell specifically for genomics
>>>> work, and maybe some of your insights would be particularly relevant for
>>>> the Sanger audience.
>>>>
>>>> Thank you!  Perhaps your responses on this thread (if any) may be
>>>> helpful to more than just me.
>>>>
>>>> Simon
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> Jeff Brown | Jeffrey Benjamin Brown
> Website <https://msu.edu/~brown202/>   |   Facebook
> <https://www.facebook.com/mejeff.younotjeff>   |   LinkedIn
> <https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often
> miss messages here)   |   Github <https://github.com/jeffreybenjaminbrown>
>
> _______________________________________________
> 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/20180711/c84a3951/attachment.html>

From johnw at newartisans.com  Wed Jul 11 22:00:11 2018
From: johnw at newartisans.com (John Wiegley)
Date: Wed, 11 Jul 2018 15:00:11 -0700
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 (Stefan Monnier's message of "Wed, 11 Jul 2018 10:14:16 -0400")
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
Message-ID: <m2bmbdigb8.fsf@newartisans.com>

>>>>> "SM" == Stefan Monnier <monnier at iro.umontreal.ca> writes:

SM> I don't much like the monad solution for side-effects, but if those guys
SM> might have some knowledge of the horror of concurrent programming with
SM> locks, the STM system would be a good candidate.

I would vote for STM too, especially when using retry within a logical block
to indicate "try again when things might make more sense". When dealing with
multiple variables, and queues that you're popping values from, that is a
truly hard thing to say with traditional concurrent programming.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

From conal at conal.net  Wed Jul 11 22:19:22 2018
From: conal at conal.net (Conal Elliott)
Date: Wed, 11 Jul 2018 15:19:22 -0700
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <51117e46-4e38-c05c-b3f5-dc528d071bbc@iohk.io>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 <51117e46-4e38-c05c-b3f5-dc528d071bbc@iohk.io>
Message-ID: <CAD6SzR+zmzdfApWsVjjqwrB6ngR=nDXWheJo7TxUd3tRV2axAA@mail.gmail.com>

> The fact that you can define the IO monad in Haskell was quite a
revelation.

But it's *not* a fact. It's a lie. And one of the most devious sort, since
the source code appears to agree. The purported definition couldn't
possibly explain concurrency.

On Wed, Jul 11, 2018 at 7:21 AM, Vanessa McHale <vanessa.mchale at iohk.io>
wrote:

> I find it quite elegant! The fact that you can define the IO monad in
> Haskell was quite a revelation. And it's especially nice when paired with a
> demonstration of C FFI (where you might *need* to sequence side effects
> such as freeing a value after it has been read).
>
> newtype IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> = IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> (State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld> -> (# State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>, a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> #))
>
>
> On 07/11/2018 09:14 AM, Stefan Monnier wrote:
>
> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger
> Institute<https://www.sanger.ac.uk/> <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren't computer scientists.
> I can tell them plenty about Haskell, but I'm ill-equipped to answer the
> main question in their minds: why should I even care about Haskell?  I'm too
> much of a biased witness.
>
> I don't much like the monad solution for side-effects, but if those guys
> might have some knowledge of the horror of concurrent programming with
> locks, the STM system would be a good candidate.
>
>
>         Stefan
>
> _______________________________________________
> 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.
>
>
> --
>
>
>
> *Vanessa McHale*
> Functional Compiler Engineer | Chicago, IL
>
> Website: www.iohk.io <http://iohk.io>
> Twitter: @vamchale
> PGP Key ID: 4209B7B5
>
> [image: Input Output] <http://iohk.io>
>
> [image: Twitter] <https://twitter.com/InputOutputHK> [image: Github]
> <https://github.com/input-output-hk> [image: LinkedIn]
> <https://www.linkedin.com/company/input-output-global>
>
>
> This e-mail and any file transmitted with it are confidential and intended
> solely for the use of the recipient(s) to whom it is addressed.
> Dissemination, distribution, and/or copying of the transmission by anyone
> other than the intended recipient(s) is prohibited. If you have received
> this transmission in error please notify IOHK immediately and delete it
> from your system. E-mail transmissions cannot be guaranteed to be secure or
> error free. We do not accept liability for any loss, damage, or error
> arising from this transmission
>
> _______________________________________________
> 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/20180711/05e72b01/attachment.html>

From david.feuer at gmail.com  Wed Jul 11 22:41:07 2018
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 11 Jul 2018 18:41:07 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CAD6SzR+zmzdfApWsVjjqwrB6ngR=nDXWheJo7TxUd3tRV2axAA@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 <51117e46-4e38-c05c-b3f5-dc528d071bbc@iohk.io>
 <CAD6SzR+zmzdfApWsVjjqwrB6ngR=nDXWheJo7TxUd3tRV2axAA@mail.gmail.com>
Message-ID: <CAMgWh9t7UEdNXk-4wjF_Y-y20kf+vgSLrB4ros3+qbeDXjVmZQ@mail.gmail.com>

The purported definition also mixes very badly with strictness analysis.
For IO, m >>= f should be *lazy* in f (e.g., print 3 >> undefined should
print 3 before throwing an exception) but the purported definition would
suggest it's *strict* (print 3 >> undefined is equivalent to undefined).

On Wed, Jul 11, 2018, 6:20 PM Conal Elliott <conal at conal.net> wrote:

> > The fact that you can define the IO monad in Haskell was quite a
> revelation.
>
> But it's *not* a fact. It's a lie. And one of the most devious sort, since
> the source code appears to agree. The purported definition couldn't
> possibly explain concurrency.
>
> On Wed, Jul 11, 2018 at 7:21 AM, Vanessa McHale <vanessa.mchale at iohk.io>
> wrote:
>
>> I find it quite elegant! The fact that you can define the IO monad in
>> Haskell was quite a revelation. And it's especially nice when paired with a
>> demonstration of C FFI (where you might *need* to sequence side effects
>> such as freeing a value after it has been read).
>>
>> newtype IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> = IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> (State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld> -> (# State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>, a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> #))
>>
>>
>> On 07/11/2018 09:14 AM, Stefan Monnier wrote:
>>
>> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger
>> Institute<https://www.sanger.ac.uk/> <https://www.sanger.ac.uk/> about Haskell.   They do lots of
>> programming, but they aren't computer scientists.
>> I can tell them plenty about Haskell, but I'm ill-equipped to answer the
>> main question in their minds: why should I even care about Haskell?  I'm too
>> much of a biased witness.
>>
>> I don't much like the monad solution for side-effects, but if those guys
>> might have some knowledge of the horror of concurrent programming with
>> locks, the STM system would be a good candidate.
>>
>>
>>         Stefan
>>
>> _______________________________________________
>> 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.
>>
>>
>> --
>>
>>
>>
>> *Vanessa McHale*
>> Functional Compiler Engineer | Chicago, IL
>>
>> Website: www.iohk.io <http://iohk.io>
>> Twitter: @vamchale
>> PGP Key ID: 4209B7B5
>>
>> [image: Input Output] <http://iohk.io>
>>
>> [image: Twitter] <https://twitter.com/InputOutputHK> [image: Github]
>> <https://github.com/input-output-hk> [image: LinkedIn]
>> <https://www.linkedin.com/company/input-output-global>
>>
>>
>> This e-mail and any file transmitted with it are confidential and
>> intended solely for the use of the recipient(s) to whom it is addressed.
>> Dissemination, distribution, and/or copying of the transmission by anyone
>> other than the intended recipient(s) is prohibited. If you have received
>> this transmission in error please notify IOHK immediately and delete it
>> from your system. E-mail transmissions cannot be guaranteed to be secure or
>> error free. We do not accept liability for any loss, damage, or error
>> arising from this transmission
>>
>> _______________________________________________
>> 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/20180711/f2f7dd99/attachment-0001.html>

From tonymorris at gmail.com  Thu Jul 12 00:00:44 2018
From: tonymorris at gmail.com (Tony Morris)
Date: Thu, 12 Jul 2018 10:00:44 +1000
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
Message-ID: <f66a11dc-90c8-e3f1-8a69-0ac01cda372e@gmail.com>

https://github.com/functionaljava/functionaljava/blob/6ac5f9547dbb1f0ca3777be6b366f256e9943194/core/src/main/java/fj/data/List.java#L452

This function was written over 15 years ago. I disagree with this
reasoning that though a lot of programmers are unwilling to make the
investment to learn (true), that this has consequences for the use of
Haskell (not true). Those same programmers have barely learned Java and
yet Java is pervasive through our industry. I learned this (nobody knows
Java) when I was working on implementing the JVM and I asked myself, "if
I am to implement this Java thing, does anyone out there actually know
it?" I quickly learned that the answer is no. In fact, I wrote a test
back then (~2003), subtitled, "but do you even know the basics of Java?"
and the best score to this day on that test is 4/10 (twice). I wrote
that test to debunk the common protest, "but where will I hire Java
programmers?!" The correct answer is nowhere, they do not exist.

Sorry for the diversion.


On 07/12/2018 12:03 AM, Bryan Richter wrote:
> cartProdN:: [[a]] -> [[a]] cartProdN= sequence
>
> This also made me realize of two things:
> 0. Haskell will never be mainstream, because there are not a lot of
> programmers out there who are willing to do the investment required
> for learning the necessary concepts to understand and write code like
> the one shown above.

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

From jays at panix.com  Thu Jul 12 01:14:10 2018
From: jays at panix.com (Jay Sulzberger)
Date: Wed, 11 Jul 2018 21:14:10 -0400 (EDT)
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <Pine.NEB.4.64.1807112107120.2700@panix2.panix.com>


On Wed, 11 Jul 2018, Simon Peyton Jones <simonpj at microsoft.com>
via Haskell-Cafe wrote:

> Friends
>
> In a few weeks I'm giving a talk to a bunch of genomics folk at
> the Sanger Institute<https://www.sanger.ac.uk/> about Haskell.
> They do lots of programming, but they aren't computer
> scientists.
>
> I can tell them plenty about Haskell, but I'm ill-equipped to
> answer the main question in their minds: why should I even care
> about Haskell?  I'm too much of a biased witness.

The compiler enforces comments.  The type system is the mechanism
of this enforceement.

oo--JS.


>
> So I thought I'd ask you for help.  War stories perhaps - how using Haskell worked (or didn't) for you.  But rather than talk generalities, I'd love to illustrate with copious examples of beautiful code.
>
>  *   Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about?   Something that gave you an "aha" moment, or that feeling of joy when you truly make sense of something for the first time.
> The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn't going to do it for them.  I need examples that I can present in 5 minutes, without needing a long setup.
> To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C.  It's so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc.  But it also makes much less good use of memory, and is likely to run slower.  I think I can do that in 5 minutes.
> Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
> But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done.
> Pointers to your favourite blog posts would be another avenue.  (I love the Haskell Weekly News.)
> Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience.
> Thank you!  Perhaps your responses on this thread (if any) may be helpful to more than just me.
> Simon
>

From vanessa.mchale at iohk.io  Thu Jul 12 01:59:12 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Wed, 11 Jul 2018 20:59:12 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CAD6SzR+zmzdfApWsVjjqwrB6ngR=nDXWheJo7TxUd3tRV2axAA@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 <51117e46-4e38-c05c-b3f5-dc528d071bbc@iohk.io>
 <CAD6SzR+zmzdfApWsVjjqwrB6ngR=nDXWheJo7TxUd3tRV2axAA@mail.gmail.com>
Message-ID: <29151136-125f-1ba9-8538-4194390f8c14@iohk.io>

I'm not sure I follow. Do you mean that IO is not a monad because
equivalence of values cannot be defined? Or is it something deeper?

On 07/11/2018 05:19 PM, Conal Elliott wrote:
> > The fact that you can define the IO monad in Haskell was quite a
> revelation.
>
> But it's *not* a fact. It's a lie. And one of the most devious sort,
> since the source code appears to agree. The purported definition
> couldn't possibly explain concurrency.
>
> On Wed, Jul 11, 2018 at 7:21 AM, Vanessa McHale
> <vanessa.mchale at iohk.io <mailto:vanessa.mchale at iohk.io>> wrote:
>
>     I find it quite elegant! The fact that you can define the IO monad
>     in Haskell was quite a revelation. And it's especially nice when
>     paired with a demonstration of C FFI (where you might *need* to
>     sequence side effects such as freeing a value after it has been read).
>
>     newtypeIO
>     <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO>a
>     <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802>=IO
>     <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO>(State#
>     <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23>RealWorld
>     <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>->(#State#
>     <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23>RealWorld
>     <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>,a
>     <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802>#))
>
>
>     On 07/11/2018 09:14 AM, Stefan Monnier wrote:
>>>     In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger
>>>     Institute<https://www.sanger.ac.uk/> <https://www.sanger.ac.uk/> about Haskell.   They do lots of
>>>     programming, but they aren't computer scientists.
>>>     I can tell them plenty about Haskell, but I'm ill-equipped to answer the
>>>     main question in their minds: why should I even care about Haskell?  I'm too
>>>     much of a biased witness.
>>     I don't much like the monad solution for side-effects, but if those guys
>>     might have some knowledge of the horror of concurrent programming with
>>     locks, the STM system would be a good candidate.
>>
>>
>>             Stefan
>>
>>     _______________________________________________
>>     Haskell-Cafe mailing list
>>     To (un)subscribe, modify options or view archives go to:
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>>     Only members subscribed via the mailman list are allowed to post.
>
>     -- 
>
>
>
>     *Vanessa McHale*
>     Functional Compiler Engineer | Chicago, IL
>
>     Website: www.iohk.io <http://iohk.io>
>     Twitter: @vamchale
>     PGP Key ID: 4209B7B5
>
>     Input Output <http://iohk.io>
>
>     Twitter <https://twitter.com/InputOutputHK> Github
>     <https://github.com/input-output-hk> LinkedIn
>     <https://www.linkedin.com/company/input-output-global>
>
>
>     This e-mail and any file transmitted with it are confidential and
>     intended solely for the use of the recipient(s) to whom it is
>     addressed. Dissemination, distribution, and/or copying of the
>     transmission by anyone other than the intended recipient(s) is
>     prohibited. If you have received this transmission in error please
>     notify IOHK immediately and delete it from your system. E-mail
>     transmissions cannot be guaranteed to be secure or error free. We
>     do not accept liability for any loss, damage, or error arising
>     from this transmission
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>     Only members subscribed via the mailman list are allowed to post.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/05e203c2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/05e203c2/attachment.sig>

From allbery.b at gmail.com  Thu Jul 12 02:03:19 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 11 Jul 2018 22:03:19 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <29151136-125f-1ba9-8538-4194390f8c14@iohk.io>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 <51117e46-4e38-c05c-b3f5-dc528d071bbc@iohk.io>
 <CAD6SzR+zmzdfApWsVjjqwrB6ngR=nDXWheJo7TxUd3tRV2axAA@mail.gmail.com>
 <29151136-125f-1ba9-8538-4194390f8c14@iohk.io>
Message-ID: <CAKFCL4VGapVX-1oxzXpy9-oM4GPokptHmwd4ip-W3EJao7sA+A@mail.gmail.com>

In the presence of concurrency, IO requires runtime support and can't be
simply defined in Haskell proper.

On Wed, Jul 11, 2018 at 9:59 PM Vanessa McHale <vanessa.mchale at iohk.io>
wrote:

> I'm not sure I follow. Do you mean that IO is not a monad because
> equivalence of values cannot be defined? Or is it something deeper?
> On 07/11/2018 05:19 PM, Conal Elliott wrote:
>
> > The fact that you can define the IO monad in Haskell was quite a
> revelation.
>
> But it's *not* a fact. It's a lie. And one of the most devious sort, since
> the source code appears to agree. The purported definition couldn't
> possibly explain concurrency.
>
> On Wed, Jul 11, 2018 at 7:21 AM, Vanessa McHale <vanessa.mchale at iohk.io>
> wrote:
>
>> I find it quite elegant! The fact that you can define the IO monad in
>> Haskell was quite a revelation. And it's especially nice when paired with a
>> demonstration of C FFI (where you might *need* to sequence side effects
>> such as freeing a value after it has been read).
>>
>> newtype IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> = IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> (State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld> -> (# State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>, a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> #))
>>
>>
>> On 07/11/2018 09:14 AM, Stefan Monnier wrote:
>>
>> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger
>> Institute<https://www.sanger.ac.uk/> <https://www.sanger.ac.uk/> about Haskell.   They do lots of
>> programming, but they aren't computer scientists.
>> I can tell them plenty about Haskell, but I'm ill-equipped to answer the
>> main question in their minds: why should I even care about Haskell?  I'm too
>> much of a biased witness.
>>
>> I don't much like the monad solution for side-effects, but if those guys
>> might have some knowledge of the horror of concurrent programming with
>> locks, the STM system would be a good candidate.
>>
>>
>>         Stefan
>>
>> _______________________________________________
>> 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.
>>
>>
>> --
>>
>>
>>
>> *Vanessa McHale*
>> Functional Compiler Engineer | Chicago, IL
>>
>> Website: www.iohk.io <http://iohk.io>
>> Twitter: @vamchale
>> PGP Key ID: 4209B7B5
>>
>> [image: Input Output] <http://iohk.io>
>>
>> [image: Twitter] <https://twitter.com/InputOutputHK> [image: Github]
>> <https://github.com/input-output-hk> [image: LinkedIn]
>> <https://www.linkedin.com/company/input-output-global>
>>
>>
>> This e-mail and any file transmitted with it are confidential and
>> intended solely for the use of the recipient(s) to whom it is addressed.
>> Dissemination, distribution, and/or copying of the transmission by anyone
>> other than the intended recipient(s) is prohibited. If you have received
>> this transmission in error please notify IOHK immediately and delete it
>> from your system. E-mail transmissions cannot be guaranteed to be secure or
>> error free. We do not accept liability for any loss, damage, or error
>> arising from this transmission
>>
>> _______________________________________________
>> 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.



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/ad28fb38/attachment.html>

From conal at conal.net  Thu Jul 12 04:28:46 2018
From: conal at conal.net (Conal Elliott)
Date: Wed, 11 Jul 2018 21:28:46 -0700
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CAKFCL4VGapVX-1oxzXpy9-oM4GPokptHmwd4ip-W3EJao7sA+A@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 <51117e46-4e38-c05c-b3f5-dc528d071bbc@iohk.io>
 <CAD6SzR+zmzdfApWsVjjqwrB6ngR=nDXWheJo7TxUd3tRV2axAA@mail.gmail.com>
 <29151136-125f-1ba9-8538-4194390f8c14@iohk.io>
 <CAKFCL4VGapVX-1oxzXpy9-oM4GPokptHmwd4ip-W3EJao7sA+A@mail.gmail.com>
Message-ID: <CAD6SzRKje+Ci6yfhCfxzX=GNFB_83W2nZWoOK6Zk6w3YcOM3vg@mail.gmail.com>

Concurrency *can* be defined in Haskell proper (the denotative subset), but
not compatibly with that "source code" and probably not at all with the
current particulars of IO. With the source code in question, even the "real
world" cannot evolve concurrently with program execution, let alone
different threads with an IO computation.

On Wed, Jul 11, 2018 at 7:03 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> In the presence of concurrency, IO requires runtime support and can't be
> simply defined in Haskell proper.
>
> On Wed, Jul 11, 2018 at 9:59 PM Vanessa McHale <vanessa.mchale at iohk.io>
> wrote:
>
>> I'm not sure I follow. Do you mean that IO is not a monad because
>> equivalence of values cannot be defined? Or is it something deeper?
>> On 07/11/2018 05:19 PM, Conal Elliott wrote:
>>
>> > The fact that you can define the IO monad in Haskell was quite a
>> revelation.
>>
>> But it's *not* a fact. It's a lie. And one of the most devious sort,
>> since the source code appears to agree. The purported definition couldn't
>> possibly explain concurrency.
>>
>> On Wed, Jul 11, 2018 at 7:21 AM, Vanessa McHale <vanessa.mchale at iohk.io>
>> wrote:
>>
>>> I find it quite elegant! The fact that you can define the IO monad in
>>> Haskell was quite a revelation. And it's especially nice when paired with a
>>> demonstration of C FFI (where you might *need* to sequence side effects
>>> such as freeing a value after it has been read).
>>>
>>> newtype IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> = IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> (State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld> -> (# State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>, a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> #))
>>>
>>>
>>> On 07/11/2018 09:14 AM, Stefan Monnier wrote:
>>>
>>> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger
>>> Institute<https://www.sanger.ac.uk/> <https://www.sanger.ac.uk/> about Haskell.   They do lots of
>>> programming, but they aren't computer scientists.
>>> I can tell them plenty about Haskell, but I'm ill-equipped to answer the
>>> main question in their minds: why should I even care about Haskell?  I'm too
>>> much of a biased witness.
>>>
>>> I don't much like the monad solution for side-effects, but if those guys
>>> might have some knowledge of the horror of concurrent programming with
>>> locks, the STM system would be a good candidate.
>>>
>>>
>>>         Stefan
>>>
>>> _______________________________________________
>>> 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.
>>>
>>>
>>> --
>>>
>>>
>>>
>>> *Vanessa McHale*
>>> Functional Compiler Engineer | Chicago, IL
>>>
>>> Website: www.iohk.io <http://iohk.io>
>>> Twitter: @vamchale
>>> PGP Key ID: 4209B7B5
>>>
>>> [image: Input Output] <http://iohk.io>
>>>
>>> [image: Twitter] <https://twitter.com/InputOutputHK> [image: Github]
>>> <https://github.com/input-output-hk> [image: LinkedIn]
>>> <https://www.linkedin.com/company/input-output-global>
>>>
>>>
>>> This e-mail and any file transmitted with it are confidential and
>>> intended solely for the use of the recipient(s) to whom it is addressed.
>>> Dissemination, distribution, and/or copying of the transmission by anyone
>>> other than the intended recipient(s) is prohibited. If you have received
>>> this transmission in error please notify IOHK immediately and delete it
>>> from your system. E-mail transmissions cannot be guaranteed to be secure or
>>> error free. We do not accept liability for any loss, damage, or error
>>> arising from this transmission
>>>
>>> _______________________________________________
>>> 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.
>
>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180711/5697fd6f/attachment.html>

From conal at conal.net  Thu Jul 12 04:39:48 2018
From: conal at conal.net (Conal Elliott)
Date: Wed, 11 Jul 2018 21:39:48 -0700
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <29151136-125f-1ba9-8538-4194390f8c14@iohk.io>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <jwv36wp986d.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
 <51117e46-4e38-c05c-b3f5-dc528d071bbc@iohk.io>
 <CAD6SzR+zmzdfApWsVjjqwrB6ngR=nDXWheJo7TxUd3tRV2axAA@mail.gmail.com>
 <29151136-125f-1ba9-8538-4194390f8c14@iohk.io>
Message-ID: <CAD6SzRJfkWrcJ0AV90zA4Xtwe9DCag5cM5x5aDG35CLnzYAePg@mail.gmail.com>

In this conversation I didn't mean that IO is not a monad (a separate
topic), but rather that the "definition" of IO is incompatible with the
truth of IO. (It's perhaps akin to "the Ken Thompson hack"; see
http://wiki.c2.com/?TheKenThompsonHack.)

As for IO being a monad, I think the claim is not only not true but is
ill-defined and hence "not even false". For a well-defined claim/question,
one would need an agreed-upon notion of equality, since the Monad laws are
equalities.

(Of course there are *other* input-output-like types, perhaps subsets of
Haskell IO, for which we can define equality usefully, even based on a
denotation. But those types are not IO. Some related remarks at
http://conal.net/blog/posts/notions-of-purity-in-haskell#comment-442.)

-- Conal


On Wed, Jul 11, 2018 at 6:59 PM, Vanessa McHale <vanessa.mchale at iohk.io>
wrote:

> I'm not sure I follow. Do you mean that IO is not a monad because
> equivalence of values cannot be defined? Or is it something deeper?
> On 07/11/2018 05:19 PM, Conal Elliott wrote:
>
> > The fact that you can define the IO monad in Haskell was quite a
> revelation.
>
> But it's *not* a fact. It's a lie. And one of the most devious sort, since
> the source code appears to agree. The purported definition couldn't
> possibly explain concurrency.
>
> On Wed, Jul 11, 2018 at 7:21 AM, Vanessa McHale <vanessa.mchale at iohk.io>
> wrote:
>
>> I find it quite elegant! The fact that you can define the IO monad in
>> Haskell was quite a revelation. And it's especially nice when paired with a
>> demonstration of C FFI (where you might *need* to sequence side effects
>> such as freeing a value after it has been read).
>>
>> newtype IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> = IO <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#IO> (State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld> -> (# State# <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#State%23> RealWorld <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Prim.html#RealWorld>, a <http://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/src/GHC.Types.html#local-6989586621679009802> #))
>>
>>
>> On 07/11/2018 09:14 AM, Stefan Monnier wrote:
>>
>> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger
>> Institute<https://www.sanger.ac.uk/> <https://www.sanger.ac.uk/> about Haskell.   They do lots of
>> programming, but they aren't computer scientists.
>> I can tell them plenty about Haskell, but I'm ill-equipped to answer the
>> main question in their minds: why should I even care about Haskell?  I'm too
>> much of a biased witness.
>>
>> I don't much like the monad solution for side-effects, but if those guys
>> might have some knowledge of the horror of concurrent programming with
>> locks, the STM system would be a good candidate.
>>
>>
>>         Stefan
>>
>> _______________________________________________
>> 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.
>>
>>
>> --
>>
>>
>>
>> *Vanessa McHale*
>> Functional Compiler Engineer | Chicago, IL
>>
>> Website: www.iohk.io <http://iohk.io>
>> Twitter: @vamchale
>> PGP Key ID: 4209B7B5
>>
>> [image: Input Output] <http://iohk.io>
>>
>> [image: Twitter] <https://twitter.com/InputOutputHK> [image: Github]
>> <https://github.com/input-output-hk> [image: LinkedIn]
>> <https://www.linkedin.com/company/input-output-global>
>>
>>
>> This e-mail and any file transmitted with it are confidential and
>> intended solely for the use of the recipient(s) to whom it is addressed.
>> Dissemination, distribution, and/or copying of the transmission by anyone
>> other than the intended recipient(s) is prohibited. If you have received
>> this transmission in error please notify IOHK immediately and delete it
>> from your system. E-mail transmissions cannot be guaranteed to be secure or
>> error free. We do not accept liability for any loss, damage, or error
>> arising from this transmission
>>
>> _______________________________________________
>> 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/20180711/14a2a848/attachment-0001.html>

From jo at durchholz.org  Thu Jul 12 06:01:19 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Thu, 12 Jul 2018 08:01:19 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <e23a9de4-917e-64d9-5034-331b4afb2191@durchholz.org>

Am 11.07.2018 um 14:10 schrieb Simon Peyton Jones via Haskell-Cafe:
> Another thing that I think comes over easily is the ability to abstract: 
> generalising sum and product to fold by abstracting out a functional 
> argument;

You can expound more on that: People don't have to write loops anymore 
(with their fencepost issues etc.). It's like a "for" loop, but written 
using in-language facilities instead of having to live with what the 
language designer does.

This means you can roll your own loop constructs.

Consider iterating over the elements of a data structure such as List, 
Tree, etc. Most languages offer an Iterable interface, which tends to be 
somewhat messy to implement.
With a higher-order function, you can just write down the loop, *once*, 
and the loop body will be provided by a function parameter, and voilà! 
you have your loop construct.

HTH
Jo

From jo at durchholz.org  Thu Jul 12 06:09:38 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Thu, 12 Jul 2018 08:09:38 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
Message-ID: <6f11f266-db7f-1dcc-55d2-9938a7789175@durchholz.org>

Am 11.07.2018 um 15:36 schrieb Damian Nadales:
> 0. Haskell will never be mainstream, because there are not a lot of 
> programmers out there who are willing to do the investment required for 
> learning the necessary concepts to understand and write code like the 
> one shown above.

For an uninitiated, learning Java takes about the same amount of time as 
learning Haskell. Learning monads is like learning Spring or one of the 
gazillion other library frameworks out there in the Java world, so even 
that isn't much of a difference.

If you're a programmer already, then changes are that Haskell is indeed 
harder to learn than most other languages you might want to learn, 
because the overlap of standard concepts and techniques is smaller.

IOW it's harder to teach Haskell to programmers than to nonprogrammers.
Which also means that our conclusions from our experience as programmers 
do not predict much about Haskell's future.

> 1. Haskell has rendered me unemployable for almost all jobs that do not 
> involve Haskell codebases.

This can be avoided if you find a job that has a 50-50 split of Haskell 
and non-Haskell work, but that's not always possible and I agree this 
can become a huge problem.

Regards,
Jo

From jo at durchholz.org  Thu Jul 12 06:23:57 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Thu, 12 Jul 2018 08:23:57 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
Message-ID: <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>

Am 11.07.2018 um 16:36 schrieb Damian Nadales:
> 
> I speak only from my own narrow perspective. I'd say programming is 
> hard, but functional programming is harder.

Actually it's pretty much the opposite, I hear from teachers.

> Maybe that's why Java replaced Haskell in some universities
> curricula
The considerations are marketable skills.
A considerable fraction of students is looking at the curriculum and at 
job offers, and if they find that the lists don't match, they will go to 
another university.
Also, industry keeps lobbying for teaching skills that they can use. 
Industry can give money to universities so this gives them influence on 
the curriculum (and only if they get time to talk the topic over with 
the dean). This aspect can vary considerably between countries, 
depending on how much money the universities tend to acquire from industry.

> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason most 
> programmers I know are not scared of learning OO, but they fear 
> functional programming.

Programmers were *very* scared of OO in the nineties. It took roughly a 
decade or two (depending on where you put the starting point) to get 
comfortable with OO.

 >
   I think the reason might be that OO concepts
> like inheritance and passing messages between objects are a bit more 
> concrete and easier to grasp (when you present toy examples at least).

OO is about how to deal with having to pack everything into its own 
class (and how to arrange stuff into classes).
Functional is about how to deal with the inability to update. Here, the 
functional camp actually has the easier job, because you can just tell 
people to just write code that creates new data objects and get over 
with it. Performance concerns can be handwaved away by saying that the 
compiler is hyper-aggressive, and "you can look at the intermediate code 
if you suspect the compiler is the issue". (Functional is a bit similar 
to SQL here, but the SQL optimizers are much less competent than GHC at 
detecting optimization opportunities.)

> Then you have design patterns, which have intuitive names and give some 
> very general guidelines that one can try after reading them (and add 
> his/her own personal twist). I doubt people can read the Monad laws and 
> make any sense out of them at the first try.

That's true, but much of the misconceptions around monads from the first 
days have been cleared up.
But yes the monad laws are too hard to read. OTOH you won't be able to 
read the Tree code in the JDK without the explanations either.

From tonymorris at gmail.com  Thu Jul 12 06:35:55 2018
From: tonymorris at gmail.com (Tony Morris)
Date: Thu, 12 Jul 2018 16:35:55 +1000
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
Message-ID: <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>

 I used to teach undergrad OOP nonsense. I have been teaching FP for 15
years. [^1]

The latter is *way* easier. Existing programmers are more difficult than
children, but still way easier to teach FP than all the other stuff.

[^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/


On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>>
>> I speak only from my own narrow perspective. I'd say programming is
>> hard, but functional programming is harder.
>
> Actually it's pretty much the opposite, I hear from teachers.
>
>> Maybe that's why Java replaced Haskell in some universities
>> curricula
> The considerations are marketable skills.
> A considerable fraction of students is looking at the curriculum and
> at job offers, and if they find that the lists don't match, they will
> go to another university.
> Also, industry keeps lobbying for teaching skills that they can use.
> Industry can give money to universities so this gives them influence
> on the curriculum (and only if they get time to talk the topic over
> with the dean). This aspect can vary considerably between countries,
> depending on how much money the universities tend to acquire from
> industry.
>
>> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>> most programmers I know are not scared of learning OO, but they fear
>> functional programming.
>
> Programmers were *very* scared of OO in the nineties. It took roughly
> a decade or two (depending on where you put the starting point) to get
> comfortable with OO.
>
> >
>   I think the reason might be that OO concepts
>> like inheritance and passing messages between objects are a bit more
>> concrete and easier to grasp (when you present toy examples at least).
>
> OO is about how to deal with having to pack everything into its own
> class (and how to arrange stuff into classes).
> Functional is about how to deal with the inability to update. Here,
> the functional camp actually has the easier job, because you can just
> tell people to just write code that creates new data objects and get
> over with it. Performance concerns can be handwaved away by saying
> that the compiler is hyper-aggressive, and "you can look at the
> intermediate code if you suspect the compiler is the issue".
> (Functional is a bit similar to SQL here, but the SQL optimizers are
> much less competent than GHC at detecting optimization opportunities.)
>
>> Then you have design patterns, which have intuitive names and give
>> some very general guidelines that one can try after reading them (and
>> add his/her own personal twist). I doubt people can read the Monad
>> laws and make any sense out of them at the first try.
>
> That's true, but much of the misconceptions around monads from the
> first days have been cleared up.
> But yes the monad laws are too hard to read. OTOH you won't be able to
> read the Tree code in the JDK without the explanations either.
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180712/a3d8d26b/attachment.sig>

From brettg at posteo.net  Thu Jul 12 06:40:30 2018
From: brettg at posteo.net (Brett Gilio)
Date: Thu, 12 Jul 2018 01:40:30 -0500
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
Message-ID: <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>

Tony,

I am curious on your attitude towards multi-paradigm and ML-like 
languages. I agree that functional programming is easily the better of 
the bundle in many forms of application logic and elegance (which is why 
I have come to love Scheme and Haskell), but do you see any room for 
those languages like F# or Rust which have large capacities for FP but 
are either functional-first (but not pure) or a hybrid?

Brett Gilio

On 07/12/2018 01:35 AM, Tony Morris wrote:
>   I used to teach undergrad OOP nonsense. I have been teaching FP for 15
> years. [^1]
> 
> The latter is *way* easier. Existing programmers are more difficult than
> children, but still way easier to teach FP than all the other stuff.
> 
> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
> 
> 
> On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>>>
>>> I speak only from my own narrow perspective. I'd say programming is
>>> hard, but functional programming is harder.
>>
>> Actually it's pretty much the opposite, I hear from teachers.
>>
>>> Maybe that's why Java replaced Haskell in some universities
>>> curricula
>> The considerations are marketable skills.
>> A considerable fraction of students is looking at the curriculum and
>> at job offers, and if they find that the lists don't match, they will
>> go to another university.
>> Also, industry keeps lobbying for teaching skills that they can use.
>> Industry can give money to universities so this gives them influence
>> on the curriculum (and only if they get time to talk the topic over
>> with the dean). This aspect can vary considerably between countries,
>> depending on how much money the universities tend to acquire from
>> industry.
>>
>>> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>>> most programmers I know are not scared of learning OO, but they fear
>>> functional programming.
>>
>> Programmers were *very* scared of OO in the nineties. It took roughly
>> a decade or two (depending on where you put the starting point) to get
>> comfortable with OO.
>>
>>>
>>    I think the reason might be that OO concepts
>>> like inheritance and passing messages between objects are a bit more
>>> concrete and easier to grasp (when you present toy examples at least).
>>
>> OO is about how to deal with having to pack everything into its own
>> class (and how to arrange stuff into classes).
>> Functional is about how to deal with the inability to update. Here,
>> the functional camp actually has the easier job, because you can just
>> tell people to just write code that creates new data objects and get
>> over with it. Performance concerns can be handwaved away by saying
>> that the compiler is hyper-aggressive, and "you can look at the
>> intermediate code if you suspect the compiler is the issue".
>> (Functional is a bit similar to SQL here, but the SQL optimizers are
>> much less competent than GHC at detecting optimization opportunities.)
>>
>>> Then you have design patterns, which have intuitive names and give
>>> some very general guidelines that one can try after reading them (and
>>> add his/her own personal twist). I doubt people can read the Monad
>>> laws and make any sense out of them at the first try.
>>
>> That's true, but much of the misconceptions around monads from the
>> first days have been cleared up.
>> But yes the monad laws are too hard to read. OTOH you won't be able to
>> read the Tree code in the JDK without the explanations either.
>> _______________________________________________
>> 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 tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Jul 12 06:42:35 2018
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 12 Jul 2018 07:42:35 +0100
Subject: [Haskell-cafe] Monad laws (Was: Investing in languages (Was: What
 is your favourite Haskell "aha" moment?))
In-Reply-To: <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
Message-ID: <20180712064235.ytbzqdbr5pjofqwn@weber>

> the monad laws are too hard to read.

FWIW the monad laws are not hard to *read* if written in this form

    return >=> f = f
    f >=> return = f
    (f >=> g) >=> h = f >=> (g >=> h)

(Whether they're easy to *understand* in that form is another matter.)

From jo at durchholz.org  Thu Jul 12 06:52:40 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Thu, 12 Jul 2018 08:52:40 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB030832C8CAA921B2B41DC879AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <e5c986f5-8a56-a220-6f36-53abe6f3f352@users.sourceforge.net>
 <AM0PR83MB030832C8CAA921B2B41DC879AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <7746f067-f2ce-4209-f5af-ca7ed52465c3@durchholz.org>

Am 11.07.2018 um 18:24 schrieb Simon Peyton Jones via Haskell-Cafe:
> One thing that stands our for me is the ability to abstract over type 
> *constructors*:
> 
>              f :: forall (m :: * -> *) (a :: *). Monad m => a -> m a
> 
> That ability is what has given rise to a stunningly huge collection of 
> abstractions: not just Monad, but Functor, Applicative, Traversable, 
> Foldable, etc etc etc.   Really a lot.  It opens up a new way to think 
> about the world.  But only made possible by that one feature.   (Plus 
> type classes of course.)
> 
> Do any statically typed languages other than Haskell and Scala do this?

Not this, but this description reminded me of my own A-Ha moment when I 
looked at Eiffel's data structure library.
Eiffel does multiple inheritance pretty well, so they went ahead and 
structured the library using a classifier approach: bounded vs. 
unbounded data structures, updatable vs. non-updatable ones, indexable 
vs. merely iterable. Any concrete class is a subtype of any of these, 
and of course the classifying types had subtypes that defined more 
detail, e.g. set vs. multiset (bag) vs. map.

This created an extraordinarily uniform API where equal things had equal 
names and consistent semantics, something that rare even for 
well-designed libraries.
(The library does have its weaknesses, which are due to the designer's 
aggressively update-in-place mindset, so in a discussion it's probably 
best to avoid mentioning Eiffel if you wish to highlight FP.)

From lexi.lambda at gmail.com  Thu Jul 12 07:06:21 2018
From: lexi.lambda at gmail.com (Alexis King)
Date: Thu, 12 Jul 2018 02:06:21 -0500
Subject: [Haskell-cafe] Monad laws (Was: Investing in languages (Was:
	What is your favourite Haskell "aha" moment?))
In-Reply-To: <20180712064235.ytbzqdbr5pjofqwn@weber>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <20180712064235.ytbzqdbr5pjofqwn@weber>
Message-ID: <D35CA55A-1409-4D7F-957D-A3E62649E84F@gmail.com>

> On Jul 12, 2018, at 01:42, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> 
>> the monad laws are too hard to read.
> 
> FWIW the monad laws are not hard to *read* if written in this form
> 
>    return >=> f = f
>    f >=> return = f
>    (f >=> g) >=> h = f >=> (g >=> h)
> 
> (Whether they're easy to *understand* in that form is another matter.)

Here is another formulation of the monad laws that is less frequently discussed than either of the ones using bind or Kleisli composition:

    (1) join . return = id
    (2) join . fmap return = id
    (3) join . join = join . map join

These laws map less obviously to the common ones, but I think they are easier to understand (not least because `join` is closer to the “essence” of what a monad is than >>=). (1) and (2) describe the intuitive notion that adding a layer and squashing it should be the identity function, whether you add the new layer on the outside or on the inside. Likewise, (3) states that if you have three layers and squash them all together, it doesn’t matter whether you squash the inner two or outer two together first.

(Credit goes to HTNW on Stack Overflow for explaining this to me. https://stackoverflow.com/a/45829556/465378)


From gk at ninebynine.org  Thu Jul 12 09:56:50 2018
From: gk at ninebynine.org (Graham Klyne)
Date: Thu, 12 Jul 2018 10:56:50 +0100
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <5B4725E2.2000308@ninebynine.org>

Although I don't program regularly in Haskell these days (my poison is Python, 
mainly for Web framework support), I do occasionally find myself coding tricky 
manipulations in Haskell first as I find it easier to concentrate on the 
essentials of an algorithm.  Once I have the Haskell code written and tested, I 
generally find it fairly easy to map the algorithm into Python (using higher 
order functions as appropriate).

Here are some examples:

https://github.com/gklyne/annalist/blob/master/spike/rearrange-list/move_up.lhs
https://github.com/gklyne/annalist/blob/master/spike/tree-scan/tree_scan.lhs

And the corresponding code in the actual application:

https://github.com/gklyne/annalist/blob/4d21250a3457c72d4f6525e5a4fac40d4c0ca1c8/src/annalist_root/annalist/views/entityedit.py#L2489

https://github.com/gklyne/annalist/blob/master/src/annalist_root/annalist/models/entity.py#L245

#g
--


On 11/07/2018 13:10, Simon Peyton Jones via Haskell-Cafe wrote:
> Friends
> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger Institute<https://www.sanger.ac.uk/> about Haskell.   They do lots of programming, but they aren't computer scientists.
> I can tell them plenty about Haskell, but I'm ill-equipped to answer the main question in their minds: why should I even care about Haskell?  I'm too much of a biased witness.
>
> So I thought I'd ask you for help.  War stories perhaps - how using Haskell worked (or didn't) for you.  But rather than talk generalities, I'd love to illustrate with copious examples of beautiful code.
>
>    *   Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about?   Something that gave you an "aha" moment, or that feeling of joy when you truly make sense of something for the first time.
> The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn't going to do it for them.  I need examples that I can present in 5 minutes, without needing a long setup.
> To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C.  It's so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc.  But it also makes much less good use of memory, and is likely to run slower.  I think I can do that in 5 minutes.
> Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
> But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done.
> Pointers to your favourite blog posts would be another avenue.  (I love the Haskell Weekly News.)
> Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience.
> Thank you!  Perhaps your responses on this thread (if any) may be helpful to more than just me.
> Simon
>
>
>
> _______________________________________________
> 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 brettg at posteo.net  Thu Jul 12 09:58:13 2018
From: brettg at posteo.net (Brett Gilio)
Date: Thu, 12 Jul 2018 04:58:13 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <5B4725E2.2000308@ninebynine.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
Message-ID: <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>

Python is poison, indeed. ;)

Brett Gilio
brettg at posteo.net | bmg at member.fsf.org
Free Software -- Free Society!

On 07/12/2018 04:56 AM, Graham Klyne wrote:
> Although I don't program regularly in Haskell these days (my poison is 
> Python, mainly for Web framework support), I do occasionally find myself 
> coding tricky manipulations in Haskell first as I find it easier to 
> concentrate on the essentials of an algorithm.  Once I have the Haskell 
> code written and tested, I generally find it fairly easy to map the 
> algorithm into Python (using higher order functions as appropriate).
> 
> Here are some examples:
> 
> https://github.com/gklyne/annalist/blob/master/spike/rearrange-list/move_up.lhs 
> 
> https://github.com/gklyne/annalist/blob/master/spike/tree-scan/tree_scan.lhs 
> 
> 
> And the corresponding code in the actual application:
> 
> https://github.com/gklyne/annalist/blob/4d21250a3457c72d4f6525e5a4fac40d4c0ca1c8/src/annalist_root/annalist/views/entityedit.py#L2489 
> 
> 
> https://github.com/gklyne/annalist/blob/master/src/annalist_root/annalist/models/entity.py#L245 
> 
> 
> #g
> -- 
> 
> 
> On 11/07/2018 13:10, Simon Peyton Jones via Haskell-Cafe wrote:
>> Friends
>> In a few weeks I'm giving a talk to a bunch of genomics folk at the 
>> Sanger Institute<https://www.sanger.ac.uk/> about Haskell.   They do 
>> lots of programming, but they aren't computer scientists.
>> I can tell them plenty about Haskell, but I'm ill-equipped to answer 
>> the main question in their minds: why should I even care about 
>> Haskell?  I'm too much of a biased witness.
>>
>> So I thought I'd ask you for help.  War stories perhaps - how using 
>> Haskell worked (or didn't) for you.  But rather than talk 
>> generalities, I'd love to illustrate with copious examples of 
>> beautiful code.
>>
>>    *   Can you identify a few lines of Haskell that best characterise 
>> what you think makes Haskell distinctively worth caring about?   
>> Something that gave you an "aha" moment, or that feeling of joy when 
>> you truly make sense of something for the first time.
>> The challenge is, of course, that this audience will know no Haskell, 
>> so muttering about Cartesian Closed Categories isn't going to do it 
>> for them.  I need examples that I can present in 5 minutes, without 
>> needing a long setup.
>> To take a very basic example, consider Quicksort using list 
>> comprehensions, compared with its equivalent in C.  It's so short, so 
>> obviously right, whereas doing the right thing with in-place update in 
>> C notoriously prone to fencepost errors etc.  But it also makes much 
>> less good use of memory, and is likely to run slower.  I think I can 
>> do that in 5 minutes.
>> Another thing that I think comes over easily is the ability to 
>> abstract: generalising sum and product to fold by abstracting out a 
>> functional argument; generalising at the type level by polymorphism, 
>> including polymorphism over higher-kinded type constructors.   Maybe 8 
>> minutes.
>> But you will have more and better ideas, and (crucially) ideas that 
>> are more credibly grounded in the day to day reality of writing 
>> programs that get work done.
>> Pointers to your favourite blog posts would be another avenue.  (I 
>> love the Haskell Weekly News.)
>> Finally, I know that some of you use Haskell specifically for genomics 
>> work, and maybe some of your insights would be particularly relevant 
>> for the Sanger audience.
>> Thank you!  Perhaps your responses on this thread (if any) may be 
>> helpful to more than just me.
>> Simon
>>
>>
>>
>> _______________________________________________
>> 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 gk at ninebynine.org  Thu Jul 12 10:04:41 2018
From: gk at ninebynine.org (Graham Klyne)
Date: Thu, 12 Jul 2018 11:04:41 +0100
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <5B4727B9.4050003@ninebynine.org>

Another example of Haskell-influenced programming in another language (this time 
Jacascript, before promises and event driven frameworks were a thing) - I 
implemented a class somewhat based on Hasell's Monad class to organize callback 
sequencing in an jQuery-based UI.  The (aged) code is here:

https://github.com/gklyne/shuffl/blob/master/src/AsyncComputation.js

and an example of use:

https://github.com/gklyne/shuffl/blob/master/src/shuffl-loadworkspace.js#L186

#g
--


On 11/07/2018 13:10, Simon Peyton Jones via Haskell-Cafe wrote:
> Friends
> In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger Institute<https://www.sanger.ac.uk/> about Haskell.   They do lots of programming, but they aren't computer scientists.
> I can tell them plenty about Haskell, but I'm ill-equipped to answer the main question in their minds: why should I even care about Haskell?  I'm too much of a biased witness.
>
> So I thought I'd ask you for help.  War stories perhaps - how using Haskell worked (or didn't) for you.  But rather than talk generalities, I'd love to illustrate with copious examples of beautiful code.
>
>    *   Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about?   Something that gave you an "aha" moment, or that feeling of joy when you truly make sense of something for the first time.
> The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn't going to do it for them.  I need examples that I can present in 5 minutes, without needing a long setup.
> To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C.  It's so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc.  But it also makes much less good use of memory, and is likely to run slower.  I think I can do that in 5 minutes.
> Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
> But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done.
> Pointers to your favourite blog posts would be another avenue.  (I love the Haskell Weekly News.)
> Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience.
> Thank you!  Perhaps your responses on this thread (if any) may be helpful to more than just me.
> Simon
>
>
>
> _______________________________________________
> 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 vanessa.mchale at iohk.io  Thu Jul 12 10:28:53 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Thu, 12 Jul 2018 05:28:53 -0500
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
Message-ID: <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>

I wouldn't say Rust has a large capacity for FP. I am not familiar with
F#. The thing that makes FP infeasible in Rust is not the lack of purity
but rather the fact that affine types make it difficult to treat
functions as first-class values.


On 07/12/2018 01:40 AM, Brett Gilio wrote:
> Tony,
>
> I am curious on your attitude towards multi-paradigm and ML-like
> languages. I agree that functional programming is easily the better of
> the bundle in many forms of application logic and elegance (which is
> why I have come to love Scheme and Haskell), but do you see any room
> for those languages like F# or Rust which have large capacities for FP
> but are either functional-first (but not pure) or a hybrid?
>
> Brett Gilio
>
> On 07/12/2018 01:35 AM, Tony Morris wrote:
>>   I used to teach undergrad OOP nonsense. I have been teaching FP for 15
>> years. [^1]
>>
>> The latter is *way* easier. Existing programmers are more difficult than
>> children, but still way easier to teach FP than all the other stuff.
>>
>> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
>>
>>
>> On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>>> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>>>>
>>>> I speak only from my own narrow perspective. I'd say programming is
>>>> hard, but functional programming is harder.
>>>
>>> Actually it's pretty much the opposite, I hear from teachers.
>>>
>>>> Maybe that's why Java replaced Haskell in some universities
>>>> curricula
>>> The considerations are marketable skills.
>>> A considerable fraction of students is looking at the curriculum and
>>> at job offers, and if they find that the lists don't match, they will
>>> go to another university.
>>> Also, industry keeps lobbying for teaching skills that they can use.
>>> Industry can give money to universities so this gives them influence
>>> on the curriculum (and only if they get time to talk the topic over
>>> with the dean). This aspect can vary considerably between countries,
>>> depending on how much money the universities tend to acquire from
>>> industry.
>>>
>>>> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>>>> most programmers I know are not scared of learning OO, but they fear
>>>> functional programming.
>>>
>>> Programmers were *very* scared of OO in the nineties. It took roughly
>>> a decade or two (depending on where you put the starting point) to get
>>> comfortable with OO.
>>>
>>>>
>>>    I think the reason might be that OO concepts
>>>> like inheritance and passing messages between objects are a bit more
>>>> concrete and easier to grasp (when you present toy examples at least).
>>>
>>> OO is about how to deal with having to pack everything into its own
>>> class (and how to arrange stuff into classes).
>>> Functional is about how to deal with the inability to update. Here,
>>> the functional camp actually has the easier job, because you can just
>>> tell people to just write code that creates new data objects and get
>>> over with it. Performance concerns can be handwaved away by saying
>>> that the compiler is hyper-aggressive, and "you can look at the
>>> intermediate code if you suspect the compiler is the issue".
>>> (Functional is a bit similar to SQL here, but the SQL optimizers are
>>> much less competent than GHC at detecting optimization opportunities.)
>>>
>>>> Then you have design patterns, which have intuitive names and give
>>>> some very general guidelines that one can try after reading them (and
>>>> add his/her own personal twist). I doubt people can read the Monad
>>>> laws and make any sense out of them at the first try.
>>>
>>> That's true, but much of the misconceptions around monads from the
>>> first days have been cleared up.
>>> But yes the monad laws are too hard to read. OTOH you won't be able to
>>> read the Tree code in the JDK without the explanations either.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

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

From aquagnu at gmail.com  Thu Jul 12 11:46:22 2018
From: aquagnu at gmail.com (PY)
Date: Thu, 12 Jul 2018 14:46:22 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
Message-ID: <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>

I am afraid that it can lead to flame again, but F# has super-capacity: 
you can check measuring units, type providers, computation expressions, 
active patterns, static/dynamic types constraints, constraints on 
existing method, etc... It's clean, borrows some ideas from Haskell, 
some are original and Haskell borrows them (but with worse 
implementation). IMHO for children teaching to FP F# is the best. Even 
more, currently C# also has a lot of FP features 
(https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification 
-- is not it super easy and beauty?). Rust is more low level: you should 
think about memory "management", OOP has some problems... And serious 
argument for children teaching: salary trends (joke sure) :-) But you 
can compare salary in F# and Haskell, for example - people often choice 
language after check current salaries in the market. Also F# is more 
focused on realistic tasks and business value. It lacks performance, UWP 
yet (but in progress)... To feel how F# is sexy compare Web application 
written in Websharper and in any Haskell framework. Haskell is beauty 
but I'm afraid its fate unfortunately will be the same as one of Common 
Lisp, NetBSD, etc - it's ground for ideas and experiments and has 
disputable design. Also it's more-more difficult to teach children to 
Haskell than to F#...

IMHO is general to teach FP is more easy than to teach OOP if FP is not 
Haskell (some language which targets more eager/efficient/dynamic/real 
goals instead of abstract types playing).

12.07.2018 13:28, Vanessa McHale wrote:
> I wouldn't say Rust has a large capacity for FP. I am not familiar with
> F#. The thing that makes FP infeasible in Rust is not the lack of purity
> but rather the fact that affine types make it difficult to treat
> functions as first-class values.
>
>
> On 07/12/2018 01:40 AM, Brett Gilio wrote:
>> Tony,
>>
>> I am curious on your attitude towards multi-paradigm and ML-like
>> languages. I agree that functional programming is easily the better of
>> the bundle in many forms of application logic and elegance (which is
>> why I have come to love Scheme and Haskell), but do you see any room
>> for those languages like F# or Rust which have large capacities for FP
>> but are either functional-first (but not pure) or a hybrid?
>>
>> Brett Gilio
>>
>> On 07/12/2018 01:35 AM, Tony Morris wrote:
>>>    I used to teach undergrad OOP nonsense. I have been teaching FP for 15
>>> years. [^1]
>>>
>>> The latter is *way* easier. Existing programmers are more difficult than
>>> children, but still way easier to teach FP than all the other stuff.
>>>
>>> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
>>>
>>>
>>> On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>>>> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>>>>> I speak only from my own narrow perspective. I'd say programming is
>>>>> hard, but functional programming is harder.
>>>> Actually it's pretty much the opposite, I hear from teachers.
>>>>
>>>>> Maybe that's why Java replaced Haskell in some universities
>>>>> curricula
>>>> The considerations are marketable skills.
>>>> A considerable fraction of students is looking at the curriculum and
>>>> at job offers, and if they find that the lists don't match, they will
>>>> go to another university.
>>>> Also, industry keeps lobbying for teaching skills that they can use.
>>>> Industry can give money to universities so this gives them influence
>>>> on the curriculum (and only if they get time to talk the topic over
>>>> with the dean). This aspect can vary considerably between countries,
>>>> depending on how much money the universities tend to acquire from
>>>> industry.
>>>>
>>>>> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>>>>> most programmers I know are not scared of learning OO, but they fear
>>>>> functional programming.
>>>> Programmers were *very* scared of OO in the nineties. It took roughly
>>>> a decade or two (depending on where you put the starting point) to get
>>>> comfortable with OO.
>>>>
>>>>     I think the reason might be that OO concepts
>>>>> like inheritance and passing messages between objects are a bit more
>>>>> concrete and easier to grasp (when you present toy examples at least).
>>>> OO is about how to deal with having to pack everything into its own
>>>> class (and how to arrange stuff into classes).
>>>> Functional is about how to deal with the inability to update. Here,
>>>> the functional camp actually has the easier job, because you can just
>>>> tell people to just write code that creates new data objects and get
>>>> over with it. Performance concerns can be handwaved away by saying
>>>> that the compiler is hyper-aggressive, and "you can look at the
>>>> intermediate code if you suspect the compiler is the issue".
>>>> (Functional is a bit similar to SQL here, but the SQL optimizers are
>>>> much less competent than GHC at detecting optimization opportunities.)
>>>>
>>>>> Then you have design patterns, which have intuitive names and give
>>>>> some very general guidelines that one can try after reading them (and
>>>>> add his/her own personal twist). I doubt people can read the Monad
>>>>> laws and make any sense out of them at the first try.
>>>> That's true, but much of the misconceptions around monads from the
>>>> first days have been cleared up.
>>>> But yes the monad laws are too hard to read. OTOH you won't be able to
>>>> read the Tree code in the JDK without the explanations either.
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
> _______________________________________________
> 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/20180712/3eaf72f4/attachment.html>

From publicityifl at gmail.com  Thu Jul 12 12:25:53 2018
From: publicityifl at gmail.com (Jurriaan Hage)
Date: Thu, 12 Jul 2018 05:25:53 -0700
Subject: [Haskell-cafe] LAST CALL for draft papers for presentation at IFL
 2018 (deadline this week)
Message-ID: <CAKVFE6XENQ9wb_FHX55a7zVLiKX6Gq_Peiy0m88GZTVJzWHrJw@mail.gmail.com>

Hello,

Please, find below the last call for draft papers for presentation for IFL
2018.
Please forward these to anyone you think may be interested.
Apologies for any duplicates you may receive.

best regards,
Jurriaan Hage
Publicity Chair of IFL

---

                        Call for Draft papers for presentations

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

                                    IFL 2018

    30th Symposium on Implementation and Application of Functional
Languages


                   University of Massachusetts Lowell, MA, USA
                             September 5th-7th, 2018

                            http://iflconference.org

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

### Scope

The goal of the IFL symposia is to bring together researchers actively
engaged
in the implementation and application of functional and function-based
programming languages. IFL 2018 will be a venue for researchers to present
and
discuss new ideas and concepts, work in progress, and publication-ripe
results
related to the implementation and application of functional languages and
function-based programming.

Topics of interest to IFL include, but are not limited to:

- language concepts
- type systems, type checking, type inferencing
- compilation techniques
- staged compilation
- run-time function specialization
- run-time code generation
- partial evaluation
- (abstract) interpretation
- metaprogramming
- generic programming
- automatic program generation
- array processing
- concurrent/parallel programming
- concurrent/parallel program execution
- embedded systems
- web applications
- (embedded) domain specific languages
- security
- novel memory management techniques
- run-time profiling performance measurements
- debugging and tracing
- virtual/abstract machine architectures
- validation, verification of functional programs
- tools and programming techniques
- (industrial) applications


### Keynote Speakers

* Adam Chlipala, Massachusetts Institute of Technology CSAIL
* Arjun Guha, University of Massachusetts Amherst


### Submissions and peer-review

Differently from previous editions of IFL, IFL 2018 solicits two kinds of
submissions:

* Regular papers (12 pages including references)
* Draft papers for presentations ('weak' limit between 8 and 15 pages)

Regular papers will undergo a rigorous review by the program committee, and
will
be evaluated according to their correctness, novelty, originality,
relevance,
significance, and clarity. A set of regular papers will be conditionally
accepted for publication. Authors of conditionally accepted papers will be
provided with committee reviews along with a set of mandatory revisions.
Regular papers not accepted for publication will be considered as draft
papers,
at the request of the author.

Draft papers will be screened to make sure that they are within the scope of
IFL, and will be accepted for presentation or rejected accordingly.

Prior to the symposium:
  Authors of conditionally accepted papers and accepted presentations will
  submit a pre-proceedings version of their work that will appear in the
draft
  proceedings distributed at the symposium. The draft proceedings does not
  constitute a formal publication.

  We require that at least one of the authors present the work at IFL 2018.

After the symposium:

  Authors of conditionally accepted papers will submit a revised versions of
  their paper for the formal post-proceedings.
  The program committee will assess whether the mandatory revisions have
been
  adequately addressed by the authors and thereby determines the final
  accept/reject status of the paper.
  Our interest is to ultimately accept all conditionally accepted papers.
If you
  are an author of a conditionally accepted paper, please make sure that you
  address all the concerns of the reviewers.


  Authors of accepted presentations will be given the opportunity to
incorporate
  the feedback from discussions at the symposium and will be invited to
submit a
  revised full article for the formal post-proceedings.
  The program committee will evaluate these submissions according to their
  correctness, novelty, originality, relevance, significance, and clarity,
and
  will thereby determine whether the paper is accepted or rejected.


### Publication

The formal proceedings will appear in the International Conference
Proceedings
Series of the ACM Digital Library.

At no time may work submitted to IFL be simultaneously submitted to other
venues; submissions must adhere to ACM SIGPLAN's republication policy:


         http://www.sigplan.org/Resources/Policies/Republication


### Important dates

Submission of regular papers:                       May        25, 2018
[PASSED!]
Submission of draft papers:                         July       17, 2018
[UPCOMING!]
Regular and draft papers notification:              July       20, 2018
Deadline for early registration:                    August      8, 2018
Submission of pre-proceedings version:              August     29, 2018
IFL Symposium:                                      September 5-7, 2018
Submission of papers for post-proceedings:          November    7, 2018
Notification of acceptance:                         December   22, 2018
Camera-ready version:                               February   10, 2019


### Submission details

All contributions must be written in English. Papers must use the ACM two
columns conference format, which can be found at:

              http://www.acm.org/publications/proceedings-template

Authors submit through EasyChair:

                 https://easychair.org/conferences/?conf=ifl2018


### Peter Landin Prize

The Peter Landin Prize is awarded to the best paper presented at the
symposium every year. The honored article is selected by the program
committee
based on the submissions received for the formal review process. The prize
carries a cash award equivalent to 150 Euros.


### Organization and Program committee

Chairs: Jay McCarthy & Matteo Cimini, University of Massachusetts Lowell,
USA

Program Committee:

* Arthur Chargueraud, Inria, FR
* Ben Delaware, Purdue University, USA
* Christos Dimoulas, Northwestern University, USA
* David Darais, University of Vermont, USA
* Dominic Orchard, University of Kent, UK
* Ekaterina Komendantskaya, Heriot-Watt University, UK
* Garrett Morris, University of Kansas, USA
* Heather Miller, EPFL & Northeastern University, CH & USA
* Jeremy Yallop, University of Cambridge, UK
* Keiko Nakata, SAP Innovation Center Potsdam, DE
* Laura Castro, University of A Coruna, ESP
* Magnus Myreen, Chalmers University of Technology, SWE
* Natalia Chechina, Bournemouth University, UK
* Peter Achten, Radboud Universiteit Nijmegen, NL
* Peter-Michael Osera, Grinnell College, USA
* Richard Eisenberg, Bryn Mawr College, USA
* Trevor McDonell, University of New South Wales, AUS
* Yukiyoshi Kameyama, University of Tsukuba, JAP

### Venue

The 30th IFL is organized by the University of Massachusetts Lowell.
The City of Lowell is located at the heart of the Merrimack Valley just 30
miles
northwest of Boston. Lowell can be easily reached by train or taxi.
See the website for more information on the venue.


### Acknowledgments

This call-for-papers is an adaptation and evolution of content from previous
instances of IFL. We are grateful to prior organizers for their work, which
is
reused here.

A part of IFL 2018 format and CFP language that describes conditionally
accepted
papers has been adapted from call-for-papers of OOPSLA conferences.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180712/c385311e/attachment-0001.html>

From doaitse at swierstra.net  Thu Jul 12 12:41:42 2018
From: doaitse at swierstra.net (Doaitse Swierstra)
Date: Thu, 12 Jul 2018 14:41:42 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <66D93DED-1F3D-4B12-B84E-DAEB8C388E55@swierstra.net>

Another thing worth mentioning is the following:

An enormous amount of programmer time is spent on managing memory and scheduling computations. 

1) Automatic garbage collection has freed us from de necessity to think about WHEN THE LIFE OF A VALUE ENDS
2) Lazy evaluation frees of having to think about WHEN THE LIFE OF A VALUE STARTS.

So a lazy purely functional language like Haskell  frees the programmer from having to think about scheduling computations.

Just as you can make garbage collection explicit in your code by using assignments (making explicit that you do not need the value stored in the variable anymore) you can make evaluation in your program explicit by making arguments strict and using `seq` etc. Both these make life more complicated in the first place, although they may lead to faster code taking less memory, but they are optimisations that only should be applied when unavoidable.

Doaitse





> Op 11 jul. 2018, om 14:10  heeft Simon Peyton Jones via Haskell-Cafe <haskell-cafe at haskell.org> het volgende geschreven:
> 
> Friends
> 
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of programming, but they aren’t computer scientists.
> 
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the main question in their minds: why should I even care about Haskell?  I’m too much of a biased witness.
> 
> 
> So I thought I’d ask you for help.  War stories perhaps – how using Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d love to illustrate with copious examples of beautiful code. 
> 
> Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about?   Something that gave you an “aha” moment, or that feeling of joy when you truly make sense of something for the first time.
> The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn’t going to do it for them.  I need examples that I can present in 5 minutes, without needing a long setup.
> 
> To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C.  It’s so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc.  But it also makes much less good use of memory, and is likely to run slower.  I think I can do that in 5 minutes.
> 
> Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
> 
> But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done.
> 
> Pointers to your favourite blog posts would be another avenue.  (I love the Haskell Weekly News.)
> 
> Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience.
> 
> Thank you!  Perhaps your responses on this thread (if any) may be helpful to more than just me.
> 
> Simon
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> Only members subscribed via the mailman list are allowed to post.

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

From alexey.raga at gmail.com  Thu Jul 12 12:46:34 2018
From: alexey.raga at gmail.com (Alexey Raga)
Date: Thu, 12 Jul 2018 22:46:34 +1000
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CACf4mn9nMFx45YzvYua8FzSjeGjX6M90whqoWrp+QTUqn1K+UQ@mail.gmail.com>

Not sure if it counts as "aha moments", but when I started with Haskell I
had two major reasons (not in any importance order):

1. The ability to define the specification (types) and then "just" follow
them in implementation. Sometimes even without having a clear understanding
of the things I was using, I felt (and still feel) guided towards the right
solution.

2. The ability to refactor fearlessly is a _massive_ productivity boost.
Hard to underestimate.

Regards,
Alexey.

On Wed, Jul 11, 2018 at 10:10 PM Simon Peyton Jones via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> main question in their minds: *why should I even care about Haskell*?
> I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
> love to illustrate with copious examples of beautiful code.
>
>    - Can you identify a few lines of Haskell that best characterise what
>    you think makes Haskell distinctively worth caring about?   Something that
>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>    of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell, so
> muttering about Cartesian Closed Categories isn’t going to do it for them.
> I need examples that I can present in 5 minutes, without needing a long
> setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in C
> notoriously prone to fencepost errors etc.  But it also makes much less
> good use of memory, and is likely to run slower.  I think I can do that in
> 5 minutes.
>
> Another thing that I think comes over easily is the ability to abstract:
> generalising sum and product to fold by abstracting out a functional
> argument; generalising at the type level by polymorphism, including
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>
> But you will have more and better ideas, and (crucially) ideas that are
> more credibly grounded in the day to day reality of writing programs that
> get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I love
> the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant for
> the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be helpful
> to more than just me.
>
> Simon
> _______________________________________________
> 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/20180712/47f358f8/attachment.html>

From brettg at posteo.net  Thu Jul 12 13:01:04 2018
From: brettg at posteo.net (Brett Gilio)
Date: Thu, 12 Jul 2018 08:01:04 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CACf4mn9nMFx45YzvYua8FzSjeGjX6M90whqoWrp+QTUqn1K+UQ@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACf4mn9nMFx45YzvYua8FzSjeGjX6M90whqoWrp+QTUqn1K+UQ@mail.gmail.com>
Message-ID: <cd8763f5-8f06-6007-46f6-5c0d59b58191@posteo.net>

Alexey, could you expand on what you mean in your first point? I am 
quite intrigued. I do not use Haskell often, but that could be something 
of interest to me in-and-out of Haskell.

Brett Gilio
brettg at posteo.net | bmg at member.fsf.org
Free Software -- Free Society!

On 07/12/2018 07:46 AM, Alexey Raga wrote:
> Not sure if it counts as "aha moments", but when I started with Haskell 
> I had two major reasons (not in any importance order):
> 
> 1. The ability to define the specification (types) and then "just" 
> follow them in implementation. Sometimes even without having a clear 
> understanding of the things I was using, I felt (and still feel) guided 
> towards the right solution.
> 
> 2. The ability to refactor fearlessly is a _massive_ productivity boost. 
> Hard to underestimate.
> 
> Regards,
> Alexey.
> 
> On Wed, Jul 11, 2018 at 10:10 PM Simon Peyton Jones via Haskell-Cafe 
> <haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org>> wrote:
> 
>     Friends____
> 
>     In a few weeks I’m giving a talk to a bunch of genomics folk at the
>     Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They
>     do lots of programming, but they aren’t computer scientists.____
> 
>     I can tell them plenty about Haskell, but I’m ill-equipped to answer
>     the main question in their minds: /why should I even care about
>     Haskell/?  I’m too much of a biased witness.
> 
>     ____
> 
>     So I thought I’d ask you for help.  War stories perhaps – how using
>     Haskell worked (or didn’t) for you.  But rather than talk
>     generalities, I’d love to illustrate with copious examples of
>     beautiful code. ____
> 
>       * Can you identify a few lines of Haskell that best characterise
>         what you think makes Haskell distinctively worth caring about?  
>         Something that gave you an “aha” moment, or that feeling of joy
>         when you truly make sense of something for the first time.____
> 
>     The challenge is, of course, that this audience will know no
>     Haskell, so muttering about Cartesian Closed Categories isn’t going
>     to do it for them.  I need examples that I can present in 5 minutes,
>     without needing a long setup.____
> 
>     To take a very basic example, consider Quicksort using list
>     comprehensions, compared with its equivalent in C.  It’s so short,
>     so obviously right, whereas doing the right thing with in-place
>     update in C notoriously prone to fencepost errors etc.  But it also
>     makes much less good use of memory, and is likely to run slower.  I
>     think I can do that in 5 minutes.____
> 
>     Another thing that I think comes over easily is the ability to
>     abstract: generalising sum and product to fold by abstracting out a
>     functional argument; generalising at the type level by polymorphism,
>     including polymorphism over higher-kinded type constructors.   Maybe
>     8 minutes.____
> 
>     But you will have more and better ideas, and (crucially) ideas that
>     are more credibly grounded in the day to day reality of writing
>     programs that get work done.____
> 
>     Pointers to your favourite blog posts would be another avenue.  (I
>     love the Haskell Weekly News.)____
> 
>     Finally, I know that some of you use Haskell specifically for
>     genomics work, and maybe some of your insights would be particularly
>     relevant for the Sanger audience.____
> 
>     Thank you!  Perhaps your responses on this thread (if any) may be
>     helpful to more than just me.____
> 
>     Simon____
> 
>     _______________________________________________
>     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 alexey.raga at gmail.com  Thu Jul 12 13:17:57 2018
From: alexey.raga at gmail.com (Alexey Raga)
Date: Thu, 12 Jul 2018 23:17:57 +1000
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CACf4mn8XaFEcsh+wkwsd1aZZrT0281Uj+yQKGyxsOo-6HpSvxQ@mail.gmail.com>

Some code examples that I usually show/explain to someone who is interested
in Haskell but have no previous exposure:

ADTs. Even for something as simple as

data ShoppingCartCommand
  = CreateCart UserId
  | AddToCart CartId ProductId Quantity
  | ClearCart CartId
  deriving (Eq, Show)

This would be many-many lines of non-trivial C# or Java code (you would
need to think about abstract classes or interfaces, correctly override
toString, equality and getHashCode, write tests for all this, etc).

If the audience is familiar with C#, then explaining the ability to
abstract over type constructors may work well. In C# there is no way to
generalise over, say, IEnumerable<T> and IObservable<T>. If you want to
accept both then you'd have to write the same LINQ statements twice (or
convert one into another, which is not always possible).

Regards,
Alexey.


On Wed, Jul 11, 2018 at 10:10 PM Simon Peyton Jones via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> main question in their minds: *why should I even care about Haskell*?
> I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
> love to illustrate with copious examples of beautiful code.
>
>    - Can you identify a few lines of Haskell that best characterise what
>    you think makes Haskell distinctively worth caring about?   Something that
>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>    of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell, so
> muttering about Cartesian Closed Categories isn’t going to do it for them.
> I need examples that I can present in 5 minutes, without needing a long
> setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in C
> notoriously prone to fencepost errors etc.  But it also makes much less
> good use of memory, and is likely to run slower.  I think I can do that in
> 5 minutes.
>
> Another thing that I think comes over easily is the ability to abstract:
> generalising sum and product to fold by abstracting out a functional
> argument; generalising at the type level by polymorphism, including
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>
> But you will have more and better ideas, and (crucially) ideas that are
> more credibly grounded in the day to day reality of writing programs that
> get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I love
> the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant for
> the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be helpful
> to more than just me.
>
> Simon
> _______________________________________________
> 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/20180712/25753bba/attachment.html>

From doaitse at swierstra.net  Thu Jul 12 13:30:33 2018
From: doaitse at swierstra.net (Doaitse Swierstra)
Date: Thu, 12 Jul 2018 15:30:33 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <cd8763f5-8f06-6007-46f6-5c0d59b58191@posteo.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACf4mn9nMFx45YzvYua8FzSjeGjX6M90whqoWrp+QTUqn1K+UQ@mail.gmail.com>
 <cd8763f5-8f06-6007-46f6-5c0d59b58191@posteo.net>
Message-ID: <E24E14E4-33DD-4A80-B97D-0B270078360A@swierstra.net>


> Op 12 jul. 2018, om 15:01  heeft Brett Gilio <brettg at posteo.net> het volgende geschreven:
> 
> Alexey, could you expand on what you mean in your first point? I am quite intrigued. I do not use Haskell often, but that could be something of interest to me in-and-out of Haskell.

In the old days, when I wrote Pascal programs, and I wanted to swap values I wrote code like:

function swap (var x, y: integer); begin x := x+y; y := x - y; x := x - y end;

Only to find out that if I wanted a swap for a different type this does not work. Hence a lot of coding, and hardly re-use and very error prone. How many functions can’t you write that have this type.

So the question is how many functions can you write with the type (a, a) -> (a, a). If you randomly generate functions of this type there is a chance of 25% you get the right one. 

But things become even better:

swap (a, b) = (b, a)

Once you ask for the type you get (a, b) -> (b, a), hence the type completely specifies what swap computes, and the function is even more general than the version of the type above.

 Doaitse



> 
> Brett Gilio
> brettg at posteo.net | bmg at member.fsf.org
> Free Software -- Free Society!
> 
> On 07/12/2018 07:46 AM, Alexey Raga wrote:
>> Not sure if it counts as "aha moments", but when I started with Haskell I had two major reasons (not in any importance order):
>> 1. The ability to define the specification (types) and then "just" follow them in implementation. Sometimes even without having a clear understanding of the things I was using, I felt (and still feel) guided towards the right solution.
>> 2. The ability to refactor fearlessly is a _massive_ productivity boost. Hard to underestimate.
>> Regards,
>> Alexey.
>> On Wed, Jul 11, 2018 at 10:10 PM Simon Peyton Jones via Haskell-Cafe <haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org>> wrote:
>>    Friends____
>>    In a few weeks I’m giving a talk to a bunch of genomics folk at the
>>    Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They
>>    do lots of programming, but they aren’t computer scientists.____
>>    I can tell them plenty about Haskell, but I’m ill-equipped to answer
>>    the main question in their minds: /why should I even care about
>>    Haskell/?  I’m too much of a biased witness.
>>    ____
>>    So I thought I’d ask you for help.  War stories perhaps – how using
>>    Haskell worked (or didn’t) for you.  But rather than talk
>>    generalities, I’d love to illustrate with copious examples of
>>    beautiful code. ____
>>      * Can you identify a few lines of Haskell that best characterise
>>        what you think makes Haskell distinctively worth caring about?          Something that gave you an “aha” moment, or that feeling of joy
>>        when you truly make sense of something for the first time.____
>>    The challenge is, of course, that this audience will know no
>>    Haskell, so muttering about Cartesian Closed Categories isn’t going
>>    to do it for them.  I need examples that I can present in 5 minutes,
>>    without needing a long setup.____
>>    To take a very basic example, consider Quicksort using list
>>    comprehensions, compared with its equivalent in C.  It’s so short,
>>    so obviously right, whereas doing the right thing with in-place
>>    update in C notoriously prone to fencepost errors etc.  But it also
>>    makes much less good use of memory, and is likely to run slower.  I
>>    think I can do that in 5 minutes.____
>>    Another thing that I think comes over easily is the ability to
>>    abstract: generalising sum and product to fold by abstracting out a
>>    functional argument; generalising at the type level by polymorphism,
>>    including polymorphism over higher-kinded type constructors.   Maybe
>>    8 minutes.____
>>    But you will have more and better ideas, and (crucially) ideas that
>>    are more credibly grounded in the day to day reality of writing
>>    programs that get work done.____
>>    Pointers to your favourite blog posts would be another avenue.  (I
>>    love the Haskell Weekly News.)____
>>    Finally, I know that some of you use Haskell specifically for
>>    genomics work, and maybe some of your insights would be particularly
>>    relevant for the Sanger audience.____
>>    Thank you!  Perhaps your responses on this thread (if any) may be
>>    helpful to more than just me.____
>>    Simon____
>>    _______________________________________________
>>    Haskell-Cafe mailing list
>>    To (un)subscribe, modify options or view archives go to:
>>    http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>    Only members subscribed via the mailman list are allowed to post.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


From alexey.raga at gmail.com  Thu Jul 12 14:04:20 2018
From: alexey.raga at gmail.com (Alexey Raga)
Date: Fri, 13 Jul 2018 00:04:20 +1000
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <cd8763f5-8f06-6007-46f6-5c0d59b58191@posteo.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACf4mn9nMFx45YzvYua8FzSjeGjX6M90whqoWrp+QTUqn1K+UQ@mail.gmail.com>
 <cd8763f5-8f06-6007-46f6-5c0d59b58191@posteo.net>
Message-ID: <CACf4mn9PSVG011SdhyTWk5Wf8iZ2Yb2beMqDXYTvRL1hKLFcww@mail.gmail.com>

> Alexey, could you expand on what you mean in your first point?

I guess that I meant two things here.

First is that when I wrote a signature for my function, the compiler will
make its best to help me implement it. It will yell at me, it will not let
me use things that I am not supposed to use (according to constraints),
etc.
More precise I am with my types (e.g. use non-empty list instead of just
list, use specific ADT instead of Bools, use Age/Weight/Size instead of
Int, etc.) - more help I get.

Another thing is that sometimes I'd just play "Type Tetris" to make things
compile and work. Try something, the compiler says "No, can't have this",
perhaps make a suggestion, try another thing, "aha, next step", etc.
Learned so much from these "games" :)

Regards,
Alexey.

On Thu, Jul 12, 2018 at 11:04 PM Brett Gilio <brettg at posteo.net> wrote:

> Alexey, could you expand on what you mean in your first point? I am
> quite intrigued. I do not use Haskell often, but that could be something
> of interest to me in-and-out of Haskell.
>
> Brett Gilio
> brettg at posteo.net | bmg at member.fsf.org
> Free Software -- Free Society!
>
> On 07/12/2018 07:46 AM, Alexey Raga wrote:
> > Not sure if it counts as "aha moments", but when I started with Haskell
> > I had two major reasons (not in any importance order):
> >
> > 1. The ability to define the specification (types) and then "just"
> > follow them in implementation. Sometimes even without having a clear
> > understanding of the things I was using, I felt (and still feel) guided
> > towards the right solution.
> >
> > 2. The ability to refactor fearlessly is a _massive_ productivity boost.
> > Hard to underestimate.
> >
> > Regards,
> > Alexey.
> >
> > On Wed, Jul 11, 2018 at 10:10 PM Simon Peyton Jones via Haskell-Cafe
> > <haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org>> wrote:
> >
> >     Friends____
> >
> >     In a few weeks I’m giving a talk to a bunch of genomics folk at the
> >     Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They
> >     do lots of programming, but they aren’t computer scientists.____
> >
> >     I can tell them plenty about Haskell, but I’m ill-equipped to answer
> >     the main question in their minds: /why should I even care about
> >     Haskell/?  I’m too much of a biased witness.
> >
> >     ____
> >
> >     So I thought I’d ask you for help.  War stories perhaps – how using
> >     Haskell worked (or didn’t) for you.  But rather than talk
> >     generalities, I’d love to illustrate with copious examples of
> >     beautiful code. ____
> >
> >       * Can you identify a few lines of Haskell that best characterise
> >         what you think makes Haskell distinctively worth caring about?
> >         Something that gave you an “aha” moment, or that feeling of joy
> >         when you truly make sense of something for the first time.____
> >
> >     The challenge is, of course, that this audience will know no
> >     Haskell, so muttering about Cartesian Closed Categories isn’t going
> >     to do it for them.  I need examples that I can present in 5 minutes,
> >     without needing a long setup.____
> >
> >     To take a very basic example, consider Quicksort using list
> >     comprehensions, compared with its equivalent in C.  It’s so short,
> >     so obviously right, whereas doing the right thing with in-place
> >     update in C notoriously prone to fencepost errors etc.  But it also
> >     makes much less good use of memory, and is likely to run slower.  I
> >     think I can do that in 5 minutes.____
> >
> >     Another thing that I think comes over easily is the ability to
> >     abstract: generalising sum and product to fold by abstracting out a
> >     functional argument; generalising at the type level by polymorphism,
> >     including polymorphism over higher-kinded type constructors.   Maybe
> >     8 minutes.____
> >
> >     But you will have more and better ideas, and (crucially) ideas that
> >     are more credibly grounded in the day to day reality of writing
> >     programs that get work done.____
> >
> >     Pointers to your favourite blog posts would be another avenue.  (I
> >     love the Haskell Weekly News.)____
> >
> >     Finally, I know that some of you use Haskell specifically for
> >     genomics work, and maybe some of your insights would be particularly
> >     relevant for the Sanger audience.____
> >
> >     Thank you!  Perhaps your responses on this thread (if any) may be
> >     helpful to more than just me.____
> >
> >     Simon____
> >
> >     _______________________________________________
> >     Haskell-Cafe mailing list
> >     To (un)subscribe, modify options or view archives go to:
> >     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >     Only members subscribed via the mailman list are allowed to post.
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> >
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180713/42dcdd73/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Thu Jul 12 14:45:11 2018
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Thu, 12 Jul 2018 16:45:11 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <cd8763f5-8f06-6007-46f6-5c0d59b58191@posteo.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACf4mn9nMFx45YzvYua8FzSjeGjX6M90whqoWrp+QTUqn1K+UQ@mail.gmail.com>
 <cd8763f5-8f06-6007-46f6-5c0d59b58191@posteo.net>
Message-ID: <430b1996-f729-4214-20a1-3ad5d07d33f4@unicaen.fr>

Le 12/07/2018 à 15:01, Brett Gilio reacts :

> Alexey, could you expand on what you mean in your first point? I am 
> quite intrigued. I do not use Haskell often, but that could be 
> something of interest to me in-and-out of Haskell.
>
> Brett Gilio

Alexey Raga wrote:
> ...major reasons
>
> 1. The ability to *define the specification (types) and then "just" 
> follow them in implementation.* Sometimes even without having a clear 
> understanding of the things I was using, I felt (and still feel) 
> guided towards the right solution.
I am not Alexey Raga, who precises:
> when I wrote a signature for my function, the compiler will make its 
> best to help me implement it. It will yell at me, it will not let me 
> use things that I am not supposed to use (according to constraints), etc.
===
... but I think that there is more to tell, since in *all languages* the 
compiler makes its best to profit from typing in order to optimize the 
implementation...
With polymorphic typing and automatic type inference, the compiler can 
do a little more, it seems that people forgot already the "toy" (not 
so...) of Lennart Augustsson, named Djinn, which takes a type and 
proposes an object of this type, using the intuitionistic logic theorem 
prover (the current Djinn library dates back to 2014, but Lennart 
manufactured  it already in 2006, or before,  if I am not mistaken. He 
quotes Roy Dyckhoff, and Don Stewart). Here is a test:

    *Djinn> f ? (a,b) -> (b,a) -- my input
    f :: (a, b) -> (b, a)
    f (a, b) = (b, a)*

Doaitse Swierstra comments:
> swap (a, b) = (b, a)
>
> Once you ask for the type you get (a, b) -> (b, a), hence the type completely specifies what swap computes, and/*the function is even more general than the version of the type above*/.
I don't see that last point... Anyway, the typing power of Haskell 
should be known.
Thx.

Jerzy Karczmarczuk








---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180712/ca1b2231/attachment.html>

From jo at durchholz.org  Thu Jul 12 16:53:00 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Thu, 12 Jul 2018 18:53:00 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
Message-ID: <adc72531-7170-fc03-77cb-34ea6d5d7d19@durchholz.org>

Am 12.07.2018 um 12:28 schrieb Vanessa McHale:
> I am not familiar with F#.

F# is OCaml, ported and adapted to .net.
Or at least it started that way; I don't know how far they have diverged.

Regards,
Jo

From cdsmith at gmail.com  Thu Jul 12 17:00:09 2018
From: cdsmith at gmail.com (Chris Smith)
Date: Thu, 12 Jul 2018 13:00:09 -0400
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <CAPq5PvK7s1qnhJhoG3wo_JVO_xrXXLrHHVugM1i=xJ+aR76d9A@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <CAPq5PvK7s1qnhJhoG3wo_JVO_xrXXLrHHVugM1i=xJ+aR76d9A@mail.gmail.com>
Message-ID: <CAPq5PvLKOM-Xo2sdY7m3538QztbNDhpbmdheDbHvsjciSM0dUg@mail.gmail.com>

Oops, readding the mailing list.

On Thu, Jul 12, 2018 at 12:59 PM Chris Smith <cdsmith at gmail.com> wrote:

> I'll answer this, since I have been teaching Haskell to children for six
> years or so. :)
>
> I think it's important to distinguish between Haskell AS USED in most of
> the community, and Haskell as it COULD be used.  I agree that you don't
> want to teach the first of those to children.  But Haskell is still a great
> teaching choice, mainly because GHC is so configurable that you can create
> the environment you want, and just build it with a Haskell compiler.  With
> GHC plugins, this is becoming even more true, but it already arises from a
> combination of (a) very lightweight and intuitive core syntax in the first
> place, (b) great support for custom preludes, and (c) the RebindableSyntax
> extension, and the fact that so much syntax is defined in terms of
> desugaring.
>
> If you're seriously talking about teaching children, then your concerns
> about web frameworks and such are a bit silly.  (Unless by "children" you
> meant mid to late teens and after, in which case this becomes relevant.)
> "Advanced" type features are also not particularly relevant (though there's
> some fuzziness about what counts as "advanced"; for instance, I've recently
> decided it's better to teach GADT syntax as the only option for defining
> algebraic data types, even though I never expect most students to take
> advantage of the extra power of GADTs.)
>
> The main concern I have with F#, though, is that the semantics are far too
> complex.  It has all the power of a functional language, but none of the
> semantic simplicity. If students already struggle with compositional
> programming (and they do), they struggle even more when the simplest way to
> understand what's going on -- namely, substitution -- is taken away from
> them.  If you're going to teach a computational model based on sequencing
> actions on a global state (the state being the screen, network, etc.), then
> you might as well include mutable variables in that global state, and you
> might as well teach Python, which will at least be more intuitive, if not
> simpler.
>
> On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu at gmail.com> wrote:
>
>> I am afraid that it can lead to flame again, but F# has super-capacity:
>> you can check measuring units, type providers, computation expressions,
>> active patterns, static/dynamic types constraints, constraints on existing
>> method, etc... It's clean, borrows some ideas from Haskell, some are
>> original and Haskell borrows them (but with worse implementation). IMHO for
>> children teaching to FP F# is the best. Even more, currently C# also has a
>> lot of FP features (
>> https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification
>> -- is not it super easy and beauty?). Rust is more low level: you should
>> think about memory "management", OOP has some problems... And serious
>> argument for children teaching: salary trends (joke sure) :-) But you can
>> compare salary in F# and Haskell, for example - people often choice
>> language after check current salaries in the market. Also F# is more
>> focused on realistic tasks and business value. It lacks performance, UWP
>> yet (but in progress)... To feel how F# is sexy compare Web application
>> written in Websharper and in any Haskell framework. Haskell is beauty but
>> I'm afraid its fate unfortunately will be the same as one of Common Lisp,
>> NetBSD, etc - it's ground for ideas and experiments and has disputable
>> design. Also it's more-more difficult to teach children to Haskell than to
>> F#...
>> IMHO is general to teach FP is more easy than to teach OOP if FP is not
>> Haskell (some language which targets more eager/efficient/dynamic/real
>> goals instead of abstract types playing).
>>
>> 12.07.2018 13:28, Vanessa McHale wrote:
>>
>> I wouldn't say Rust has a large capacity for FP. I am not familiar with
>> F#. The thing that makes FP infeasible in Rust is not the lack of purity
>> but rather the fact that affine types make it difficult to treat
>> functions as first-class values.
>>
>>
>> On 07/12/2018 01:40 AM, Brett Gilio wrote:
>>
>> Tony,
>>
>> I am curious on your attitude towards multi-paradigm and ML-like
>> languages. I agree that functional programming is easily the better of
>> the bundle in many forms of application logic and elegance (which is
>> why I have come to love Scheme and Haskell), but do you see any room
>> for those languages like F# or Rust which have large capacities for FP
>> but are either functional-first (but not pure) or a hybrid?
>>
>> Brett Gilio
>>
>> On 07/12/2018 01:35 AM, Tony Morris wrote:
>>
>>   I used to teach undergrad OOP nonsense. I have been teaching FP for 15
>> years. [^1]
>>
>> The latter is *way* easier. Existing programmers are more difficult than
>> children, but still way easier to teach FP than all the other stuff.
>>
>> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
>>
>>
>> On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>>
>> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>>
>>
>> I speak only from my own narrow perspective. I'd say programming is
>> hard, but functional programming is harder.
>>
>>
>> Actually it's pretty much the opposite, I hear from teachers.
>>
>>
>> Maybe that's why Java replaced Haskell in some universities
>> curricula
>>
>> The considerations are marketable skills.
>> A considerable fraction of students is looking at the curriculum and
>> at job offers, and if they find that the lists don't match, they will
>> go to another university.
>> Also, industry keeps lobbying for teaching skills that they can use.
>> Industry can give money to universities so this gives them influence
>> on the curriculum (and only if they get time to talk the topic over
>> with the dean). This aspect can vary considerably between countries,
>> depending on how much money the universities tend to acquire from
>> industry.
>>
>>
>> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>> most programmers I know are not scared of learning OO, but they fear
>> functional programming.
>>
>>
>> Programmers were *very* scared of OO in the nineties. It took roughly
>> a decade or two (depending on where you put the starting point) to get
>> comfortable with OO.
>>
>>
>>     I think the reason might be that OO concepts
>>
>> like inheritance and passing messages between objects are a bit more
>> concrete and easier to grasp (when you present toy examples at least).
>>
>>
>> OO is about how to deal with having to pack everything into its own
>> class (and how to arrange stuff into classes).
>> Functional is about how to deal with the inability to update. Here,
>> the functional camp actually has the easier job, because you can just
>> tell people to just write code that creates new data objects and get
>> over with it. Performance concerns can be handwaved away by saying
>> that the compiler is hyper-aggressive, and "you can look at the
>> intermediate code if you suspect the compiler is the issue".
>> (Functional is a bit similar to SQL here, but the SQL optimizers are
>> much less competent than GHC at detecting optimization opportunities.)
>>
>>
>> Then you have design patterns, which have intuitive names and give
>> some very general guidelines that one can try after reading them (and
>> add his/her own personal twist). I doubt people can read the Monad
>> laws and make any sense out of them at the first try.
>>
>>
>> That's true, but much of the misconceptions around monads from the
>> first days have been cleared up.
>> But yes the monad laws are too hard to read. OTOH you won't be able to
>> read the Tree code in the JDK without the explanations either.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>> _______________________________________________
>> 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/20180712/274a3d1b/attachment-0001.html>

From donn at avvanta.com  Thu Jul 12 17:20:34 2018
From: donn at avvanta.com (Donn Cave)
Date: Thu, 12 Jul 2018 10:20:34 -0700 (PDT)
Subject: [Haskell-cafe] Investing in languages (Was: What is your
	favourite Haskell "aha" moment?)
In-Reply-To: <adc72531-7170-fc03-77cb-34ea6d5d7d19@durchholz.org>
References: <adc72531-7170-fc03-77cb-34ea6d5d7d19@durchholz.org>
Message-ID: <20180712172034.2777193C40@mail.avvanta.com>

quoth Joachim Durchholz <jo at durchholz.org>
 
> F# is OCaml, ported and adapted to .net.
> Or at least it started that way; I don't know how far they have diverged.

Rather far.  Don't quote me, I know only what I've read about F# and
am not sure I know that, but lots of Objective CAML was tossed, and
of course there's a lot of .NET.  The syntax apparently uses significant
white space, so that's one huge step forward if it works - the standard
Objective CAML syntax is quite evil in that respect.  But I believe the
interesting parts are gone: modules, and the OOP implementation, which
I have the impression might be one of the more respectable OO designs.

	Donn

From jgbm at acm.org  Thu Jul 12 17:50:15 2018
From: jgbm at acm.org (J. Garrett Morris)
Date: Thu, 12 Jul 2018 12:50:15 -0500
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
Message-ID: <CALqZiMwftb8EvGAG3T=DV=FivaudhhuptAfkzZN2vb5K7pF21A@mail.gmail.com>

On Thu, Jul 12, 2018 at 1:24 AM Joachim Durchholz <jo at durchholz.org> wrote:
> > Maybe that's why Java replaced Haskell in some universities
> > curricula
>
> The considerations are marketable skills.

That's certainly a consideration.  I doubt it weighs particularly
heavy on the departments at Austin, Berkeley, or MIT however.  Their
graduates will be plenty marketable regardless of the languages they
see most as undergraduates.

Another concern is who the courses serve.  At my institution, our
intro programming courses serve both electrical engineering and
computer science, so we have to include the EE folks needs in our
considerations.  Many institutions (Harvey Mudd has done an excellent
job of this) are also serving the wider data science community with
the same introductory course (albeit different sections).  This is
great news for exposing people to computer science, but may impose
additional requirements on how you teach.

Yet another concern is teaching load.  At my (relatively small) state
institution, we teach something like 4 sections of programming I, and
at least another two sections of intro CS for non-majors.  If I were
to champion updating that part of the curriculum, it'd be on me to
teach those sections, or to work with/train instructors to be able to
do so.  This is a non-trivial time commitment, and there's not
necessarily any guarantee that whoever ended up with the intro
sequence after I ran out of energy/time/employment would have the same
priorities.

A final note is that, just because a department chooses to teach their
introductory course in an imperative language doesn't mean they're
teaching C-style procedural programming.  Look at Harvey Mudd's CS 5
book: https://www.cs.hmc.edu/csforall/.  It's taught in Python, but
the first half of the book focuses on functional programming
paradigms.

 /g

From aquagnu at gmail.com  Thu Jul 12 18:07:27 2018
From: aquagnu at gmail.com (Paul)
Date: Thu, 12 Jul 2018 21:07:27 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavourite Haskell "aha" moment?)
In-Reply-To: <20180712172034.2777193C40@mail.avvanta.com>
References: <adc72531-7170-fc03-77cb-34ea6d5d7d19@durchholz.org>
 <20180712172034.2777193C40@mail.avvanta.com>
Message-ID: <5b4798dd.1c69fb81.7e66c.92db@mx.google.com>

ML structures/signatures/functors are gone IMHO due to namespaces and F# modules. As I know attempts to be more close to Haskell fail, so Microsoft decides to switch to ML as own dialect. All decisions were taken because of .NET architecture, sure (and OOP is close to .NET, original Ocaml OOP was not easy adapting). But for me it looks cool. For example, syntax for objects looks canonical, not like something alien for ML. My IMHO is that Microsoft takes right direction in F# as well as C#.



From: Donn Cave
Sent: 12 июля 2018 г. 20:21
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)

quoth Joachim Durchholz <jo at durchholz.org>
 
> F# is OCaml, ported and adapted to .net.
> Or at least it started that way; I don't know how far they have diverged.

Rather far.  Don't quote me, I know only what I've read about F# and
am not sure I know that, but lots of Objective CAML was tossed, and
of course there's a lot of .NET.  The syntax apparently uses significant
white space, so that's one huge step forward if it works - the standard
Objective CAML syntax is quite evil in that respect.  But I believe the
interesting parts are gone: modules, and the OOP implementation, which
I have the impression might be one of the more respectable OO designs.

	Donn
_______________________________________________
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/20180712/913a0fb9/attachment.html>

From aquagnu at gmail.com  Thu Jul 12 18:16:10 2018
From: aquagnu at gmail.com (Paul)
Date: Thu, 12 Jul 2018 21:16:10 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavouriteHaskell "aha" moment?)
In-Reply-To: <CAPq5PvJ7+3EzGMGKJ0ACQvKjbJiBCzyS07hjps3CN4xBNBXnqg@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <CAPq5PvK7s1qnhJhoG3wo_JVO_xrXXLrHHVugM1i=xJ+aR76d9A@mail.gmail.com>
 <5b4795d1.1c69fb81.15e76.2a68@mx.google.com>
 <CAPq5PvJ7+3EzGMGKJ0ACQvKjbJiBCzyS07hjps3CN4xBNBXnqg@mail.gmail.com>
Message-ID: <5b479ae8.1c69fb81.1565b.c7fd@mx.google.com>

Wooow! Yes!!
But today there is serious competition (Smalltalk, Python; I planned Scratch – but it’s for children of 7-9 years). I thing you are good teacher 😊
Btw, what do you think: what is better – textual programming or visual programming for children? For me, Labview/G was insight in 90s 😊 Today there is Luna language – it’s visual too. IMHO visual programming better illustrates ideas/concepts, or?

From: Chris Smith
Sent: 12 июля 2018 г. 21:00
To: aquagnu at gmail.com
Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)

Perhaps you mean something fun and visual like this? https://code.world/#PhFFj32Bx0FcpQvvoVJW0xw
Or this? https://code.world/#PO1BKCj-kA9ztKKnE7rOueA

These are written in the simplified variant of Haskell that I teach, which uses a custom Prelude that skips type classes and other advanced features, uses rebindable syntax to simplify types (for example, you'll see Number instead of Int, Double, etc.), and automatically provides graphics functions that work in the browser.

On Thu, Jul 12, 2018 at 1:54 PM Paul <aquagnu at gmail.com> wrote:
Hmm, Chris, thanks for answer. Interesting. I was surprised when I first learned that someone somewhere is teaching the children to Haskell, but if you say so – then it’s possible and may be it’s good! 😊  
Sometimes children don’t like right things, but like fun. So, I though that more preferable to show them some bright demo: UI, graphics, some simple games, databases, to rise the interest, you know – this feeling of first code. First “wooow! It works!!!” 😊 Haskell, for me, looks pedantic, not for fun. May be I’m not right, I have not such experience. 
 
 
From: Chris Smith
Sent: 12 июля 2018 г. 19:59
To: aquagnu at gmail.com
Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)
 
I'll answer this, since I have been teaching Haskell to children for six years or so. :)
 
I think it's important to distinguish between Haskell AS USED in most of the community, and Haskell as it COULD be used.  I agree that you don't want to teach the first of those to children.  But Haskell is still a great teaching choice, mainly because GHC is so configurable that you can create the environment you want, and just build it with a Haskell compiler.  With GHC plugins, this is becoming even more true, but it already arises from a combination of (a) very lightweight and intuitive core syntax in the first place, (b) great support for custom preludes, and (c) the RebindableSyntax extension, and the fact that so much syntax is defined in terms of desugaring.
 
If you're seriously talking about teaching children, then your concerns about web frameworks and such are a bit silly.  (Unless by "children" you meant mid to late teens and after, in which case this becomes relevant.)  "Advanced" type features are also not particularly relevant (though there's some fuzziness about what counts as "advanced"; for instance, I've recently decided it's better to teach GADT syntax as the only option for defining algebraic data types, even though I never expect most students to take advantage of the extra power of GADTs.)
 
The main concern I have with F#, though, is that the semantics are far too complex.  It has all the power of a functional language, but none of the semantic simplicity. If students already struggle with compositional programming (and they do), they struggle even more when the simplest way to understand what's going on -- namely, substitution -- is taken away from them.  If you're going to teach a computational model based on sequencing actions on a global state (the state being the screen, network, etc.), then you might as well include mutable variables in that global state, and you might as well teach Python, which will at least be more intuitive, if not simpler.
 
On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu at gmail.com> wrote:
I am afraid that it can lead to flame again, but F# has super-capacity: you can check measuring units, type providers, computation expressions, active patterns, static/dynamic types constraints, constraints on existing method, etc... It's clean, borrows some ideas from Haskell, some are original and Haskell borrows them (but with worse implementation). IMHO for children teaching to FP F# is the best. Even more, currently C# also has a lot of FP features (https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification  -- is not it super easy and beauty?). Rust is more low level: you should think about memory "management", OOP has some problems... And serious argument for children teaching: salary trends (joke sure) :-) But you can compare salary in F# and Haskell, for example - people often choice language after check current salaries in the market. Also F# is more focused on realistic tasks and business value. It lacks performance, UWP yet (but in progress)... To feel how F# is sexy compare Web application written in Websharper and in any Haskell framework. Haskell is beauty but I'm afraid its fate unfortunately will be the same as one of Common Lisp, NetBSD, etc - it's ground for ideas and experiments and has disputable design. Also it's more-more difficult to teach children to Haskell than to F#...
IMHO is general to teach FP is more easy than to teach OOP if FP is not Haskell (some language which targets more eager/efficient/dynamic/real goals instead of abstract types playing).
12.07.2018 13:28, Vanessa McHale wrote:
I wouldn't say Rust has a large capacity for FP. I am not familiar with
F#. The thing that makes FP infeasible in Rust is not the lack of purity
but rather the fact that affine types make it difficult to treat
functions as first-class values.
 
 
On 07/12/2018 01:40 AM, Brett Gilio wrote:
Tony,
 
I am curious on your attitude towards multi-paradigm and ML-like
languages. I agree that functional programming is easily the better of
the bundle in many forms of application logic and elegance (which is
why I have come to love Scheme and Haskell), but do you see any room
for those languages like F# or Rust which have large capacities for FP
but are either functional-first (but not pure) or a hybrid?
 
Brett Gilio
 
On 07/12/2018 01:35 AM, Tony Morris wrote:
  I used to teach undergrad OOP nonsense. I have been teaching FP for 15
years. [^1]
 
The latter is *way* easier. Existing programmers are more difficult than
children, but still way easier to teach FP than all the other stuff.
 
[^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
 
 
On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
Am 11.07.2018 um 16:36 schrieb Damian Nadales:
 
I speak only from my own narrow perspective. I'd say programming is
hard, but functional programming is harder.
 
Actually it's pretty much the opposite, I hear from teachers.
 
Maybe that's why Java replaced Haskell in some universities
curricula
The considerations are marketable skills.
A considerable fraction of students is looking at the curriculum and
at job offers, and if they find that the lists don't match, they will
go to another university.
Also, industry keeps lobbying for teaching skills that they can use.
Industry can give money to universities so this gives them influence
on the curriculum (and only if they get time to talk the topic over
with the dean). This aspect can vary considerably between countries,
depending on how much money the universities tend to acquire from
industry.
 
https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
most programmers I know are not scared of learning OO, but they fear
functional programming.
 
Programmers were *very* scared of OO in the nineties. It took roughly
a decade or two (depending on where you put the starting point) to get
comfortable with OO.
 
 
   I think the reason might be that OO concepts
like inheritance and passing messages between objects are a bit more
concrete and easier to grasp (when you present toy examples at least).
 
OO is about how to deal with having to pack everything into its own
class (and how to arrange stuff into classes).
Functional is about how to deal with the inability to update. Here,
the functional camp actually has the easier job, because you can just
tell people to just write code that creates new data objects and get
over with it. Performance concerns can be handwaved away by saying
that the compiler is hyper-aggressive, and "you can look at the
intermediate code if you suspect the compiler is the issue".
(Functional is a bit similar to SQL here, but the SQL optimizers are
much less competent than GHC at detecting optimization opportunities.)
 
Then you have design patterns, which have intuitive names and give
some very general guidelines that one can try after reading them (and
add his/her own personal twist). I doubt people can read the Monad
laws and make any sense out of them at the first try.
 
That's true, but much of the misconceptions around monads from the
first days have been cleared up.
But yes the monad laws are too hard to read. OTOH you won't be able to
read the Tree code in the JDK without the explanations either.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
 
 
 
 
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
 
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
 
 
_______________________________________________
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/20180712/d06bccd0/attachment.html>

From jo at durchholz.org  Thu Jul 12 20:03:25 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Thu, 12 Jul 2018 22:03:25 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <CALqZiMwftb8EvGAG3T=DV=FivaudhhuptAfkzZN2vb5K7pF21A@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <CALqZiMwftb8EvGAG3T=DV=FivaudhhuptAfkzZN2vb5K7pF21A@mail.gmail.com>
Message-ID: <3e785bb9-411a-61da-daff-dd573527f908@durchholz.org>

Am 12.07.2018 um 19:50 schrieb J. Garrett Morris:
> On Thu, Jul 12, 2018 at 1:24 AM Joachim Durchholz <jo at durchholz.org> wrote:
>>> Maybe that's why Java replaced Haskell in some universities
>>> curricula
>>
>> The considerations are marketable skills.
> 
> That's certainly a consideration.  I doubt it weighs particularly
> heavy on the departments at Austin, Berkeley, or MIT however.  Their
> graduates will be plenty marketable regardless of the languages they
> see most as undergraduates.

Yes, but 90% of universities are not elite, and since these educate 90% 
of the students, we still end with a prevalence of marketable 
programming language skills.

Not that I'm criticizing this. Not too strongly anyway; there are 
positive and negative aspects to this.

(Thanks for the rest, leaving it out because I have nothing of value to 
add, not because I disagree.)

From magnus at therning.org  Thu Jul 12 20:05:27 2018
From: magnus at therning.org (Magnus Therning)
Date: Thu, 12 Jul 2018 22:05:27 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAAExw5uhK=fniXTRhk026P6Ad1eCjftBSwm3fBWhqWyU=atMNA@mail.gmail.com>

On Wed, 11 Jul 2018, 14:10 Simon Peyton Jones via Haskell-Cafe, <
haskell-cafe at haskell.org> wrote:

> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> main question in their minds: *why should I even care about Haskell*?
> I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
> love to illustrate with copious examples of beautiful code.
>
>    - Can you identify a few lines of Haskell that best characterise what
>    you think makes Haskell distinctively worth caring about?   Something that
>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>    of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell, so
> muttering about Cartesian Closed Categories isn’t going to do it for them.
> I need examples that I can present in 5 minutes, without needing a long
> setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in C
> notoriously prone to fencepost errors etc.  But it also makes much less
> good use of memory, and is likely to run slower.  I think I can do that in
> 5 minutes.
>
> Another thing that I think comes over easily is the ability to abstract:
> generalising sum and product to fold by abstracting out a functional
> argument; generalising at the type level by polymorphism, including
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>
> But you will have more and better ideas, and (crucially) ideas that are
> more credibly grounded in the day to day reality of writing programs that
> get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I love
> the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant for
> the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be helpful
> to more than just me.
>

I wrote something about just this a few years ago, one such moment for me:
http://therning.org/magnus/posts/2007-10-22-324-aha-one-liners.html

/M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180712/179e42e1/attachment.html>

From monnier at iro.umontreal.ca  Thu Jul 12 20:20:13 2018
From: monnier at iro.umontreal.ca (Stefan Monnier)
Date: Thu, 12 Jul 2018 16:20:13 -0400
Subject: [Haskell-cafe] Investing in languages
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <CALqZiMwftb8EvGAG3T=DV=FivaudhhuptAfkzZN2vb5K7pF21A@mail.gmail.com>
 <3e785bb9-411a-61da-daff-dd573527f908@durchholz.org>
Message-ID: <jwvefg8438w.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>

> Yes, but 90% of universities are not elite, and since these educate 90% of
> the students, we still end with a prevalence of marketable programming
> language skills.

BTW, the choice of programming language is also often influenced by the
whole CS faculty members (not just the programming-language guys), and
guess what: most of them don't use anything like Haskell in
their projects.


        Stefan


From cdsmith at gmail.com  Thu Jul 12 20:48:28 2018
From: cdsmith at gmail.com (Chris Smith)
Date: Thu, 12 Jul 2018 16:48:28 -0400
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavouriteHaskell "aha" moment?)
In-Reply-To: <5b479ae8.1c69fb81.1565b.c7fd@mx.google.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <CAPq5PvK7s1qnhJhoG3wo_JVO_xrXXLrHHVugM1i=xJ+aR76d9A@mail.gmail.com>
 <5b4795d1.1c69fb81.15e76.2a68@mx.google.com>
 <CAPq5PvJ7+3EzGMGKJ0ACQvKjbJiBCzyS07hjps3CN4xBNBXnqg@mail.gmail.com>
 <5b479ae8.1c69fb81.1565b.c7fd@mx.google.com>
Message-ID: <CAPq5PvLSBQ0K7J-9Qqc_q6_3FFnGc=-6GVfsJMNEYG3et_q22g@mail.gmail.com>

This is a good question, and I think it depends on your goals.

If your goal is to inspire interest and attract children to programming,
then you are best served by making it obvious what can and can't be done,
and making it very difficult to make a mistake.  Some visual languages are
very good at this, and Scratch, for example, is a good example.  Going even
further, Scratch and similar languages are often used in situations where
the students can do literally anything, and *something* interesting
happens, inspiring that spark of excitement and feeling of "I did that!"
This is a magical moment, and it can change lives.

On the other hand, building new skills is the point of educating.  Avoiding
the need for new skills means avoiding the opportunity to learn.  Children
often still struggle with precise perception.  I've seen plenty of students
as old as 12 to 13 who literally cannot see whether there's a comma in an
expression, or whether a word is spelled "ie" or "ei", without extreme
measures like covering the surrounding text.  Their brain just skips over
these concerns.  Of course, they struggle in mathematics, and also basic
language and communication.  Once again, one can avoid the problem and try
to help them to be successful without needing that skill, which a visual
language is great at.  But of course, they ultimately do need the skill in
order to communicate in the first place!  So there's also value in placing
them in an environment where they need to learn it.  When making this
decision, though, it's important to focus on skills that are truly
necessary, and not (for example) remembering what order to write "public
static void main" in their Java programs.

On Thu, Jul 12, 2018 at 2:16 PM Paul <aquagnu at gmail.com> wrote:

> Wooow! Yes!!
>
> But today there is serious competition (Smalltalk, Python; I planned
> Scratch – but it’s for children of 7-9 years). I thing you are good teacher
> 😊
>
> Btw, what do you think: what is better – textual programming or visual
> programming for children? For me, Labview/G was insight in 90s 😊 Today
> there is Luna language – it’s visual too. IMHO visual programming better
> illustrates ideas/concepts, or?
>
>
>
> *From: *Chris Smith <cdsmith at gmail.com>
> *Sent: *12 июля 2018 г. 21:00
> *To: *aquagnu at gmail.com
> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
> yourfavouriteHaskell "aha" moment?)
>
>
>
> Perhaps you mean something fun and visual like this?
> https://code.world/#PhFFj32Bx0FcpQvvoVJW0xw
>
> Or this? https://code.world/#PO1BKCj-kA9ztKKnE7rOueA
>
>
>
> These are written in the simplified variant of Haskell that I teach, which
> uses a custom Prelude that skips type classes and other advanced features,
> uses rebindable syntax to simplify types (for example, you'll see Number
> instead of Int, Double, etc.), and automatically provides graphics
> functions that work in the browser.
>
>
>
> On Thu, Jul 12, 2018 at 1:54 PM Paul <aquagnu at gmail.com> wrote:
>
> Hmm, Chris, thanks for answer. Interesting. I was surprised when I first
> learned that someone somewhere is teaching the children to Haskell, but if
> you say so – then it’s possible and may be it’s good! 😊
>
> Sometimes children don’t like right things, but like fun. So, I though
> that more preferable to show them some bright demo: UI, graphics, some
> simple games, databases, to rise the interest, you know – this feeling of
> first code. First “wooow! It works!!!” 😊 Haskell, for me, looks
> pedantic, not for fun. May be I’m not right, I have not such experience.
>
>
>
>
>
> *From: *Chris Smith <cdsmith at gmail.com>
> *Sent: *12 июля 2018 г. 19:59
> *To: *aquagnu at gmail.com
> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
> yourfavourite Haskell "aha" moment?)
>
>
>
> I'll answer this, since I have been teaching Haskell to children for six
> years or so. :)
>
>
>
> I think it's important to distinguish between Haskell AS USED in most of
> the community, and Haskell as it COULD be used.  I agree that you don't
> want to teach the first of those to children.  But Haskell is still a great
> teaching choice, mainly because GHC is so configurable that you can create
> the environment you want, and just build it with a Haskell compiler.  With
> GHC plugins, this is becoming even more true, but it already arises from a
> combination of (a) very lightweight and intuitive core syntax in the first
> place, (b) great support for custom preludes, and (c) the RebindableSyntax
> extension, and the fact that so much syntax is defined in terms of
> desugaring.
>
>
>
> If you're seriously talking about teaching children, then your concerns
> about web frameworks and such are a bit silly.  (Unless by "children" you
> meant mid to late teens and after, in which case this becomes relevant.)
> "Advanced" type features are also not particularly relevant (though there's
> some fuzziness about what counts as "advanced"; for instance, I've recently
> decided it's better to teach GADT syntax as the only option for defining
> algebraic data types, even though I never expect most students to take
> advantage of the extra power of GADTs.)
>
>
>
> The main concern I have with F#, though, is that the semantics are far too
> complex.  It has all the power of a functional language, but none of the
> semantic simplicity. If students already struggle with compositional
> programming (and they do), they struggle even more when the simplest way to
> understand what's going on -- namely, substitution -- is taken away from
> them.  If you're going to teach a computational model based on sequencing
> actions on a global state (the state being the screen, network, etc.), then
> you might as well include mutable variables in that global state, and you
> might as well teach Python, which will at least be more intuitive, if not
> simpler.
>
>
>
> On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu at gmail.com> wrote:
>
> I am afraid that it can lead to flame again, but F# has super-capacity:
> you can check measuring units, type providers, computation expressions,
> active patterns, static/dynamic types constraints, constraints on existing
> method, etc... It's clean, borrows some ideas from Haskell, some are
> original and Haskell borrows them (but with worse implementation). IMHO for
> children teaching to FP F# is the best. Even more, currently C# also has a
> lot of FP features (
> https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification
> -- is not it super easy and beauty?). Rust is more low level: you should
> think about memory "management", OOP has some problems... And serious
> argument for children teaching: salary trends (joke sure) :-) But you can
> compare salary in F# and Haskell, for example - people often choice
> language after check current salaries in the market. Also F# is more
> focused on realistic tasks and business value. It lacks performance, UWP
> yet (but in progress)... To feel how F# is sexy compare Web application
> written in Websharper and in any Haskell framework. Haskell is beauty but
> I'm afraid its fate unfortunately will be the same as one of Common Lisp,
> NetBSD, etc - it's ground for ideas and experiments and has disputable
> design. Also it's more-more difficult to teach children to Haskell than to
> F#...
>
> IMHO is general to teach FP is more easy than to teach OOP if FP is not
> Haskell (some language which targets more eager/efficient/dynamic/real
> goals instead of abstract types playing).
>
> 12.07.2018 13:28, Vanessa McHale wrote:
>
> I wouldn't say Rust has a large capacity for FP. I am not familiar with
>
> F#. The thing that makes FP infeasible in Rust is not the lack of purity
>
> but rather the fact that affine types make it difficult to treat
>
> functions as first-class values.
>
>
>
>
>
> On 07/12/2018 01:40 AM, Brett Gilio wrote:
>
> Tony,
>
>
>
> I am curious on your attitude towards multi-paradigm and ML-like
>
> languages. I agree that functional programming is easily the better of
>
> the bundle in many forms of application logic and elegance (which is
>
> why I have come to love Scheme and Haskell), but do you see any room
>
> for those languages like F# or Rust which have large capacities for FP
>
> but are either functional-first (but not pure) or a hybrid?
>
>
>
> Brett Gilio
>
>
>
> On 07/12/2018 01:35 AM, Tony Morris wrote:
>
>   I used to teach undergrad OOP nonsense. I have been teaching FP for 15
>
> years. [^1]
>
>
>
> The latter is *way* easier. Existing programmers are more difficult than
>
> children, but still way easier to teach FP than all the other stuff.
>
>
>
> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
>
>
>
>
>
> On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>
> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>
>
>
> I speak only from my own narrow perspective. I'd say programming is
>
> hard, but functional programming is harder.
>
>
>
> Actually it's pretty much the opposite, I hear from teachers.
>
>
>
> Maybe that's why Java replaced Haskell in some universities
>
> curricula
>
> The considerations are marketable skills.
>
> A considerable fraction of students is looking at the curriculum and
>
> at job offers, and if they find that the lists don't match, they will
>
> go to another university.
>
> Also, industry keeps lobbying for teaching skills that they can use.
>
> Industry can give money to universities so this gives them influence
>
> on the curriculum (and only if they get time to talk the topic over
>
> with the dean). This aspect can vary considerably between countries,
>
> depending on how much money the universities tend to acquire from
>
> industry.
>
>
>
> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>
> most programmers I know are not scared of learning OO, but they fear
>
> functional programming.
>
>
>
> Programmers were *very* scared of OO in the nineties. It took roughly
>
> a decade or two (depending on where you put the starting point) to get
>
> comfortable with OO.
>
>
>
>
>
>    I think the reason might be that OO concepts
>
> like inheritance and passing messages between objects are a bit more
>
> concrete and easier to grasp (when you present toy examples at least).
>
>
>
> OO is about how to deal with having to pack everything into its own
>
> class (and how to arrange stuff into classes).
>
> Functional is about how to deal with the inability to update. Here,
>
> the functional camp actually has the easier job, because you can just
>
> tell people to just write code that creates new data objects and get
>
> over with it. Performance concerns can be handwaved away by saying
>
> that the compiler is hyper-aggressive, and "you can look at the
>
> intermediate code if you suspect the compiler is the issue".
>
> (Functional is a bit similar to SQL here, but the SQL optimizers are
>
> much less competent than GHC at detecting optimization opportunities.)
>
>
>
> Then you have design patterns, which have intuitive names and give
>
> some very general guidelines that one can try after reading them (and
>
> add his/her own personal twist). I doubt people can read the Monad
>
> laws and make any sense out of them at the first try.
>
>
>
> That's true, but much of the misconceptions around monads from the
>
> first days have been cleared up.
>
> But yes the monad laws are too hard to read. OTOH you won't be able to
>
> read the Tree code in the JDK without the explanations either.
>
> _______________________________________________
>
> Haskell-Cafe mailing list
>
> To (un)subscribe, modify options or view archives go to:
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> Only members subscribed via the mailman list are allowed to post.
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Haskell-Cafe mailing list
>
> To (un)subscribe, modify options or view archives go to:
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> Only members subscribed via the mailman list are allowed to post.
>
>
>
> _______________________________________________
>
> Haskell-Cafe mailing list
>
> To (un)subscribe, modify options or view archives go to:
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> Only members subscribed via the mailman list are allowed to post.
>
>
>
>
>
> _______________________________________________
>
> 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/20180712/594d6419/attachment-0001.html>

From stuart at cs.uchicago.edu  Thu Jul 12 20:57:16 2018
From: stuart at cs.uchicago.edu (Stuart A. Kurtz)
Date: Thu, 12 Jul 2018 15:57:16 -0500
Subject: [Haskell-cafe] Investing in languages
In-Reply-To: <jwvefg8438w.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <CALqZiMwftb8EvGAG3T=DV=FivaudhhuptAfkzZN2vb5K7pF21A@mail.gmail.com>
 <3e785bb9-411a-61da-daff-dd573527f908@durchholz.org>
 <jwvefg8438w.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>
Message-ID: <D97E35CF-D876-4403-BEBE-2B57D7FF93E9@cs.uchicago.edu>

Dear Stefan,

> BTW, the choice of programming language is also often influenced by the
> whole CS faculty members (not just the programming-language guys), and
> guess what: most of them don't use anything like Haskell in
> their projects.

I suspect this varies from institution to institution. My experience is that the faculty who most often teach a course have the most to say regarding its subject matter. Of course, the decision isn’t a simple matter of personal preference, as there are other collegial considerations, e.g., preparing students for subsequent classes, and in making it easy to recruit other faculty and teaching staff to cover other sections.

What this has meant at Chicago is that our mainstream intro course starts with Typed Racket, even though John Reppy (who regularly teaches it) would naturally prefer SMLNJ. On the other hand, the course was Scheme/Racket before, and the movement to Typed Racket is consistent with both the longstanding traditions of the course (which go back to SICP), and the idiosyncrasies of its faculty lead. On the other hand, I teach the honors version, and for many years the only section of it. Having no one to satisfy but myself, I settled on Haskell. These days, there’s a second section, and Ravi Chugh and I collaborate. FWIW, I’m not a PL guy, but rather am a theoretician via mathematical logic and computability theory. We get less push-back than you’d expect, as the quality of our students is taken as indicative of the quality of our choices.

My public justification for teaching Haskell is that the honors students I encounter either already have programming experience (usually Java, these days), or are hard core math geeks. Both have something substantial to add to the course, and their disadvantages and advantages largely offset. It makes for a productive community. My private justification includes the public one, but adds the very real consideration that by teaching Haskell, I continue to grow with the language and its practice. Ravi and I end up re-writing about 1/4th to 1/3rd of the course every year, which keeps it and us fresh.

Peace,

Stu

---------------

Stuart A. Kurtz
Professor, Department of Computer Science and the College
Master, Physical Sciences Collegiate Division
The University of Chicago



From sivanov at colimite.fr  Thu Jul 12 21:25:10 2018
From: sivanov at colimite.fr (Sergiu Ivanov)
Date: Thu, 12 Jul 2018 23:25:10 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What is your
	favourite Haskell "aha" moment?)
In-Reply-To: <CAPq5PvLSBQ0K7J-9Qqc_q6_3FFnGc=-6GVfsJMNEYG3et_q22g@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <CAPq5PvK7s1qnhJhoG3wo_JVO_xrXXLrHHVugM1i=xJ+aR76d9A@mail.gmail.com>
 <5b4795d1.1c69fb81.15e76.2a68@mx.google.com>
 <CAPq5PvJ7+3EzGMGKJ0ACQvKjbJiBCzyS07hjps3CN4xBNBXnqg@mail.gmail.com>
 <5b479ae8.1c69fb81.1565b.c7fd@mx.google.com>
 <CAPq5PvLSBQ0K7J-9Qqc_q6_3FFnGc=-6GVfsJMNEYG3et_q22g@mail.gmail.com>
Message-ID: <87fu0ow3ih.fsf@colimite.fr>

Hello Chris,

Thus quoth  Chris Smith  on Thu Jul 12 2018 at 22:48 (+0200):
> I've seen plenty of students as old as 12 to 13 who literally cannot
> see whether there's a comma in an expression, or whether a word is
> spelled "ie" or "ei", without extreme measures like covering the
> surrounding text.

This sounds a lot like symptoms of dyslexia.  Are you talking about
students _without_ such disorders?

-
Sergiu


Thus quoth  Chris Smith  on Thu Jul 12 2018 at 22:48 (+0200):
> This is a good question, and I think it depends on your goals.
>
> If your goal is to inspire interest and attract children to programming,
> then you are best served by making it obvious what can and can't be done,
> and making it very difficult to make a mistake.  Some visual languages are
> very good at this, and Scratch, for example, is a good example.  Going even
> further, Scratch and similar languages are often used in situations where
> the students can do literally anything, and *something* interesting
> happens, inspiring that spark of excitement and feeling of "I did that!"
> This is a magical moment, and it can change lives.
>
> On the other hand, building new skills is the point of educating.  Avoiding
> the need for new skills means avoiding the opportunity to learn.  Children
> often still struggle with precise perception.  I've seen plenty of students
> as old as 12 to 13 who literally cannot see whether there's a comma in an
> expression, or whether a word is spelled "ie" or "ei", without extreme
> measures like covering the surrounding text.  Their brain just skips over
> these concerns.  Of course, they struggle in mathematics, and also basic
> language and communication.  Once again, one can avoid the problem and try
> to help them to be successful without needing that skill, which a visual
> language is great at.  But of course, they ultimately do need the skill in
> order to communicate in the first place!  So there's also value in placing
> them in an environment where they need to learn it.  When making this
> decision, though, it's important to focus on skills that are truly
> necessary, and not (for example) remembering what order to write "public
> static void main" in their Java programs.
>
> On Thu, Jul 12, 2018 at 2:16 PM Paul <aquagnu at gmail.com> wrote:
>
>> Wooow! Yes!!
>>
>> But today there is serious competition (Smalltalk, Python; I planned
>> Scratch – but it’s for children of 7-9 years). I thing you are good teacher
>> 😊
>>
>> Btw, what do you think: what is better – textual programming or visual
>> programming for children? For me, Labview/G was insight in 90s 😊 Today
>> there is Luna language – it’s visual too. IMHO visual programming better
>> illustrates ideas/concepts, or?
>>
>>
>>
>> *From: *Chris Smith <cdsmith at gmail.com>
>> *Sent: *12 июля 2018 г. 21:00
>> *To: *aquagnu at gmail.com
>> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
>> yourfavouriteHaskell "aha" moment?)
>>
>>
>>
>> Perhaps you mean something fun and visual like this?
>> https://code.world/#PhFFj32Bx0FcpQvvoVJW0xw
>>
>> Or this? https://code.world/#PO1BKCj-kA9ztKKnE7rOueA
>>
>>
>>
>> These are written in the simplified variant of Haskell that I teach, which
>> uses a custom Prelude that skips type classes and other advanced features,
>> uses rebindable syntax to simplify types (for example, you'll see Number
>> instead of Int, Double, etc.), and automatically provides graphics
>> functions that work in the browser.
>>
>>
>>
>> On Thu, Jul 12, 2018 at 1:54 PM Paul <aquagnu at gmail.com> wrote:
>>
>> Hmm, Chris, thanks for answer. Interesting. I was surprised when I first
>> learned that someone somewhere is teaching the children to Haskell, but if
>> you say so – then it’s possible and may be it’s good! 😊
>>
>> Sometimes children don’t like right things, but like fun. So, I though
>> that more preferable to show them some bright demo: UI, graphics, some
>> simple games, databases, to rise the interest, you know – this feeling of
>> first code. First “wooow! It works!!!” 😊 Haskell, for me, looks
>> pedantic, not for fun. May be I’m not right, I have not such experience.
>>
>>
>>
>>
>>
>> *From: *Chris Smith <cdsmith at gmail.com>
>> *Sent: *12 июля 2018 г. 19:59
>> *To: *aquagnu at gmail.com
>> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
>> yourfavourite Haskell "aha" moment?)
>>
>>
>>
>> I'll answer this, since I have been teaching Haskell to children for six
>> years or so. :)
>>
>>
>>
>> I think it's important to distinguish between Haskell AS USED in most of
>> the community, and Haskell as it COULD be used.  I agree that you don't
>> want to teach the first of those to children.  But Haskell is still a great
>> teaching choice, mainly because GHC is so configurable that you can create
>> the environment you want, and just build it with a Haskell compiler.  With
>> GHC plugins, this is becoming even more true, but it already arises from a
>> combination of (a) very lightweight and intuitive core syntax in the first
>> place, (b) great support for custom preludes, and (c) the RebindableSyntax
>> extension, and the fact that so much syntax is defined in terms of
>> desugaring.
>>
>>
>>
>> If you're seriously talking about teaching children, then your concerns
>> about web frameworks and such are a bit silly.  (Unless by "children" you
>> meant mid to late teens and after, in which case this becomes relevant.)
>> "Advanced" type features are also not particularly relevant (though there's
>> some fuzziness about what counts as "advanced"; for instance, I've recently
>> decided it's better to teach GADT syntax as the only option for defining
>> algebraic data types, even though I never expect most students to take
>> advantage of the extra power of GADTs.)
>>
>>
>>
>> The main concern I have with F#, though, is that the semantics are far too
>> complex.  It has all the power of a functional language, but none of the
>> semantic simplicity. If students already struggle with compositional
>> programming (and they do), they struggle even more when the simplest way to
>> understand what's going on -- namely, substitution -- is taken away from
>> them.  If you're going to teach a computational model based on sequencing
>> actions on a global state (the state being the screen, network, etc.), then
>> you might as well include mutable variables in that global state, and you
>> might as well teach Python, which will at least be more intuitive, if not
>> simpler.
>>
>>
>>
>> On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu at gmail.com> wrote:
>>
>> I am afraid that it can lead to flame again, but F# has super-capacity:
>> you can check measuring units, type providers, computation expressions,
>> active patterns, static/dynamic types constraints, constraints on existing
>> method, etc... It's clean, borrows some ideas from Haskell, some are
>> original and Haskell borrows them (but with worse implementation). IMHO for
>> children teaching to FP F# is the best. Even more, currently C# also has a
>> lot of FP features (
>> https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification
>> -- is not it super easy and beauty?). Rust is more low level: you should
>> think about memory "management", OOP has some problems... And serious
>> argument for children teaching: salary trends (joke sure) :-) But you can
>> compare salary in F# and Haskell, for example - people often choice
>> language after check current salaries in the market. Also F# is more
>> focused on realistic tasks and business value. It lacks performance, UWP
>> yet (but in progress)... To feel how F# is sexy compare Web application
>> written in Websharper and in any Haskell framework. Haskell is beauty but
>> I'm afraid its fate unfortunately will be the same as one of Common Lisp,
>> NetBSD, etc - it's ground for ideas and experiments and has disputable
>> design. Also it's more-more difficult to teach children to Haskell than to
>> F#...
>>
>> IMHO is general to teach FP is more easy than to teach OOP if FP is not
>> Haskell (some language which targets more eager/efficient/dynamic/real
>> goals instead of abstract types playing).
>>
>> 12.07.2018 13:28, Vanessa McHale wrote:
>>
>> I wouldn't say Rust has a large capacity for FP. I am not familiar with
>>
>> F#. The thing that makes FP infeasible in Rust is not the lack of purity
>>
>> but rather the fact that affine types make it difficult to treat
>>
>> functions as first-class values.
>>
>>
>>
>>
>>
>> On 07/12/2018 01:40 AM, Brett Gilio wrote:
>>
>> Tony,
>>
>>
>>
>> I am curious on your attitude towards multi-paradigm and ML-like
>>
>> languages. I agree that functional programming is easily the better of
>>
>> the bundle in many forms of application logic and elegance (which is
>>
>> why I have come to love Scheme and Haskell), but do you see any room
>>
>> for those languages like F# or Rust which have large capacities for FP
>>
>> but are either functional-first (but not pure) or a hybrid?
>>
>>
>>
>> Brett Gilio
>>
>>
>>
>> On 07/12/2018 01:35 AM, Tony Morris wrote:
>>
>>   I used to teach undergrad OOP nonsense. I have been teaching FP for 15
>>
>> years. [^1]
>>
>>
>>
>> The latter is *way* easier. Existing programmers are more difficult than
>>
>> children, but still way easier to teach FP than all the other stuff.
>>
>>
>>
>> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
>>
>>
>>
>>
>>
>> On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>>
>> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>>
>>
>>
>> I speak only from my own narrow perspective. I'd say programming is
>>
>> hard, but functional programming is harder.
>>
>>
>>
>> Actually it's pretty much the opposite, I hear from teachers.
>>
>>
>>
>> Maybe that's why Java replaced Haskell in some universities
>>
>> curricula
>>
>> The considerations are marketable skills.
>>
>> A considerable fraction of students is looking at the curriculum and
>>
>> at job offers, and if they find that the lists don't match, they will
>>
>> go to another university.
>>
>> Also, industry keeps lobbying for teaching skills that they can use.
>>
>> Industry can give money to universities so this gives them influence
>>
>> on the curriculum (and only if they get time to talk the topic over
>>
>> with the dean). This aspect can vary considerably between countries,
>>
>> depending on how much money the universities tend to acquire from
>>
>> industry.
>>
>>
>>
>> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>>
>> most programmers I know are not scared of learning OO, but they fear
>>
>> functional programming.
>>
>>
>>
>> Programmers were *very* scared of OO in the nineties. It took roughly
>>
>> a decade or two (depending on where you put the starting point) to get
>>
>> comfortable with OO.
>>
>>
>>
>>
>>
>>    I think the reason might be that OO concepts
>>
>> like inheritance and passing messages between objects are a bit more
>>
>> concrete and easier to grasp (when you present toy examples at least).
>>
>>
>>
>> OO is about how to deal with having to pack everything into its own
>>
>> class (and how to arrange stuff into classes).
>>
>> Functional is about how to deal with the inability to update. Here,
>>
>> the functional camp actually has the easier job, because you can just
>>
>> tell people to just write code that creates new data objects and get
>>
>> over with it. Performance concerns can be handwaved away by saying
>>
>> that the compiler is hyper-aggressive, and "you can look at the
>>
>> intermediate code if you suspect the compiler is the issue".
>>
>> (Functional is a bit similar to SQL here, but the SQL optimizers are
>>
>> much less competent than GHC at detecting optimization opportunities.)
>>
>>
>>
>> Then you have design patterns, which have intuitive names and give
>>
>> some very general guidelines that one can try after reading them (and
>>
>> add his/her own personal twist). I doubt people can read the Monad
>>
>> laws and make any sense out of them at the first try.
>>
>>
>>
>> That's true, but much of the misconceptions around monads from the
>>
>> first days have been cleared up.
>>
>> But yes the monad laws are too hard to read. OTOH you won't be able to
>>
>> read the Tree code in the JDK without the explanations either.
>>
>> _______________________________________________
>>
>> Haskell-Cafe mailing list
>>
>> To (un)subscribe, modify options or view archives go to:
>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Haskell-Cafe mailing list
>>
>> To (un)subscribe, modify options or view archives go to:
>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>> _______________________________________________
>>
>> Haskell-Cafe mailing list
>>
>> To (un)subscribe, modify options or view archives go to:
>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Haskell-Cafe mailing list
>>
>> To (un)subscribe, modify options or view archives go to:
>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
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/20180712/2069461d/attachment.sig>

From tonymorris at gmail.com  Thu Jul 12 23:36:17 2018
From: tonymorris at gmail.com (Tony Morris)
Date: Fri, 13 Jul 2018 09:36:17 +1000
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
Message-ID: <5a1cec82-ad67-3300-7dcc-c00d4841b361@gmail.com>

Hi Brett,
I see room for other languages, with other potential paradigms, but of
all those implementations that I know of, I have never seen anything
with a practical result. They all fall for the Fallacy of False
Moderation in my opinion. Perhaps this makes me a hardliner, but until
something more useful comes along, it's going to have to stay that way.
The code I am writing at this very moment cannot even exist in F# or Rust.

PS: I thought I had already sent this, sorry.


On 07/12/2018 04:40 PM, Brett Gilio wrote:
> Tony,
>
> I am curious on your attitude towards multi-paradigm and ML-like
> languages. I agree that functional programming is easily the better of
> the bundle in many forms of application logic and elegance (which is
> why I have come to love Scheme and Haskell), but do you see any room
> for those languages like F# or Rust which have large capacities for FP
> but are either functional-first (but not pure) or a hybrid?
>
> Brett Gilio
>
> On 07/12/2018 01:35 AM, Tony Morris wrote:
>>   I used to teach undergrad OOP nonsense. I have been teaching FP for 15
>> years. [^1]
>>
>> The latter is *way* easier. Existing programmers are more difficult than
>> children, but still way easier to teach FP than all the other stuff.
>>
>> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
>>
>>
>> On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>>> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>>>>
>>>> I speak only from my own narrow perspective. I'd say programming is
>>>> hard, but functional programming is harder.
>>>
>>> Actually it's pretty much the opposite, I hear from teachers.
>>>
>>>> Maybe that's why Java replaced Haskell in some universities
>>>> curricula
>>> The considerations are marketable skills.
>>> A considerable fraction of students is looking at the curriculum and
>>> at job offers, and if they find that the lists don't match, they will
>>> go to another university.
>>> Also, industry keeps lobbying for teaching skills that they can use.
>>> Industry can give money to universities so this gives them influence
>>> on the curriculum (and only if they get time to talk the topic over
>>> with the dean). This aspect can vary considerably between countries,
>>> depending on how much money the universities tend to acquire from
>>> industry.
>>>
>>>> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>>>> most programmers I know are not scared of learning OO, but they fear
>>>> functional programming.
>>>
>>> Programmers were *very* scared of OO in the nineties. It took roughly
>>> a decade or two (depending on where you put the starting point) to get
>>> comfortable with OO.
>>>
>>>>
>>>    I think the reason might be that OO concepts
>>>> like inheritance and passing messages between objects are a bit more
>>>> concrete and easier to grasp (when you present toy examples at least).
>>>
>>> OO is about how to deal with having to pack everything into its own
>>> class (and how to arrange stuff into classes).
>>> Functional is about how to deal with the inability to update. Here,
>>> the functional camp actually has the easier job, because you can just
>>> tell people to just write code that creates new data objects and get
>>> over with it. Performance concerns can be handwaved away by saying
>>> that the compiler is hyper-aggressive, and "you can look at the
>>> intermediate code if you suspect the compiler is the issue".
>>> (Functional is a bit similar to SQL here, but the SQL optimizers are
>>> much less competent than GHC at detecting optimization opportunities.)
>>>
>>>> Then you have design patterns, which have intuitive names and give
>>>> some very general guidelines that one can try after reading them (and
>>>> add his/her own personal twist). I doubt people can read the Monad
>>>> laws and make any sense out of them at the first try.
>>>
>>> That's true, but much of the misconceptions around monads from the
>>> first days have been cleared up.
>>> But yes the monad laws are too hard to read. OTOH you won't be able to
>>> read the Tree code in the JDK without the explanations either.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


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

From tonymorris at gmail.com  Thu Jul 12 23:40:51 2018
From: tonymorris at gmail.com (Tony Morris)
Date: Fri, 13 Jul 2018 09:40:51 +1000
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
Message-ID: <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>

On python, we are fixing it (WIP):
https://github.com/qfpl/hpython

Did you see the recent "default mutable arguments" post?
https://lethain.com/digg-v4/

Here is a Haskell program that transforms any python program that uses
default mutable arguments:
https://github.com/qfpl/hpython/blob/master/example/FixMutableDefaultArguments.hs

Someone once said that python will never have tail call optimisation.
Here is the Haskell program that transforms any Python (direct only)
tail call into a loop:
https://github.com/qfpl/hpython/blob/master/example/OptimizeTailRecursion.hs

Two python programmers once argued over preferred indentation levels.
Let's put their disagreement into a Haskell function so that they can
stop arguing:
https://github.com/qfpl/hpython/blob/master/example/Indentation.hs


On 07/12/2018 07:58 PM, Brett Gilio wrote:
> Python is poison, indeed. ;)
>
> Brett Gilio
> brettg at posteo.net | bmg at member.fsf.org
> Free Software -- Free Society!
>
> On 07/12/2018 04:56 AM, Graham Klyne wrote:
>> Although I don't program regularly in Haskell these days (my poison
>> is Python, mainly for Web framework support), I do occasionally find
>> myself coding tricky manipulations in Haskell first as I find it
>> easier to concentrate on the essentials of an algorithm.  Once I have
>> the Haskell code written and tested, I generally find it fairly easy
>> to map the algorithm into Python (using higher order functions as
>> appropriate).
>>
>> Here are some examples:
>>
>> https://github.com/gklyne/annalist/blob/master/spike/rearrange-list/move_up.lhs
>>
>> https://github.com/gklyne/annalist/blob/master/spike/tree-scan/tree_scan.lhs
>>
>>
>> And the corresponding code in the actual application:
>>
>> https://github.com/gklyne/annalist/blob/4d21250a3457c72d4f6525e5a4fac40d4c0ca1c8/src/annalist_root/annalist/views/entityedit.py#L2489
>>
>>
>> https://github.com/gklyne/annalist/blob/master/src/annalist_root/annalist/models/entity.py#L245
>>
>>
>> #g
>> -- 
>>
>>
>> On 11/07/2018 13:10, Simon Peyton Jones via Haskell-Cafe wrote:
>>> Friends
>>> In a few weeks I'm giving a talk to a bunch of genomics folk at the
>>> Sanger Institute<https://www.sanger.ac.uk/> about Haskell.   They do
>>> lots of programming, but they aren't computer scientists.
>>> I can tell them plenty about Haskell, but I'm ill-equipped to answer
>>> the main question in their minds: why should I even care about
>>> Haskell?  I'm too much of a biased witness.
>>>
>>> So I thought I'd ask you for help.  War stories perhaps - how using
>>> Haskell worked (or didn't) for you.  But rather than talk
>>> generalities, I'd love to illustrate with copious examples of
>>> beautiful code.
>>>
>>>    *   Can you identify a few lines of Haskell that best
>>> characterise what you think makes Haskell distinctively worth caring
>>> about?   Something that gave you an "aha" moment, or that feeling of
>>> joy when you truly make sense of something for the first time.
>>> The challenge is, of course, that this audience will know no
>>> Haskell, so muttering about Cartesian Closed Categories isn't going
>>> to do it for them.  I need examples that I can present in 5 minutes,
>>> without needing a long setup.
>>> To take a very basic example, consider Quicksort using list
>>> comprehensions, compared with its equivalent in C.  It's so short,
>>> so obviously right, whereas doing the right thing with in-place
>>> update in C notoriously prone to fencepost errors etc.  But it also
>>> makes much less good use of memory, and is likely to run slower.  I
>>> think I can do that in 5 minutes.
>>> Another thing that I think comes over easily is the ability to
>>> abstract: generalising sum and product to fold by abstracting out a
>>> functional argument; generalising at the type level by polymorphism,
>>> including polymorphism over higher-kinded type constructors.   Maybe
>>> 8 minutes.
>>> But you will have more and better ideas, and (crucially) ideas that
>>> are more credibly grounded in the day to day reality of writing
>>> programs that get work done.
>>> Pointers to your favourite blog posts would be another avenue.  (I
>>> love the Haskell Weekly News.)
>>> Finally, I know that some of you use Haskell specifically for
>>> genomics work, and maybe some of your insights would be particularly
>>> relevant for the Sanger audience.
>>> Thank you!  Perhaps your responses on this thread (if any) may be
>>> helpful to more than just me.
>>> Simon
>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


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

From brettg at posteo.net  Thu Jul 12 23:45:52 2018
From: brettg at posteo.net (Brett Gilio)
Date: Thu, 12 Jul 2018 18:45:52 -0500
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <5a1cec82-ad67-3300-7dcc-c00d4841b361@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <5a1cec82-ad67-3300-7dcc-c00d4841b361@gmail.com>
Message-ID: <feb30240-f986-654c-198c-9bc9890982e9@posteo.net>

On 07/12/2018 06:36 PM, Tony Morris wrote:
> Hi Brett,
> I see room for other languages, with other potential paradigms, but of
> all those implementations that I know of, I have never seen anything
> with a practical result. 

I agree with your thesis here, the facts are pretty clear that even in 
multi-paradigm approach there is still a clearer and more elegant way to 
approach the programmatic logic. My interest in F# and other more 
"multi-paradigm" languages (even C++, nowadays) came to a... shall we 
say, bridge point when I discovered the power of Scheme 
implemementations and Haskell/Idris.

> PS: I thought I had already sent this, sorry.

You had, it was my mistake that I responded off of the list.


-- 
Brett Gilio
brettg at posteo.net | bmg at member.fsf.org
Free Software -- Free Society!

From brettg at posteo.net  Thu Jul 12 23:56:34 2018
From: brettg at posteo.net (Brett Gilio)
Date: Thu, 12 Jul 2018 18:56:34 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <CACf4mn9PSVG011SdhyTWk5Wf8iZ2Yb2beMqDXYTvRL1hKLFcww@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACf4mn9nMFx45YzvYua8FzSjeGjX6M90whqoWrp+QTUqn1K+UQ@mail.gmail.com>
 <cd8763f5-8f06-6007-46f6-5c0d59b58191@posteo.net>
 <CACf4mn9PSVG011SdhyTWk5Wf8iZ2Yb2beMqDXYTvRL1hKLFcww@mail.gmail.com>
Message-ID: <fb77c00e-cac8-511d-afe6-00c9218f4399@posteo.net>

On 07/12/2018 09:04 AM, Alexey Raga wrote:
> Another thing is that sometimes I'd just play "Type Tetris" to make 
> things compile and work. Try something, the compiler says "No, can't 
> have this", perhaps make a suggestion, try another thing, "aha, next 
> step", etc. Learned so much from these "games" :)

Ha! I like your approach. Thank you for your explanation.


-- 
Brett Gilio
brettg at posteo.net | bmg at member.fsf.org
Free Software -- Free Society!

From brettg at posteo.net  Thu Jul 12 23:52:33 2018
From: brettg at posteo.net (Brett Gilio)
Date: Thu, 12 Jul 2018 18:52:33 -0500
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
Message-ID: <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>

On 07/12/2018 06:46 AM, PY wrote:
  written in Websharper and in any Haskell framework. Haskell is beauty
> but I'm afraid its fate unfortunately will be the same as one of Common 
> Lisp, NetBSD, etc - it's ground for ideas and experiments and has 
> disputable design. Also it's more-more difficult to teach children to 
> Haskell than to F#...
> 

I wonder if this is simply a result of the marketing of the language, 
itself, rather than the strength of the language. I agree, F# has a lot 
of beauty, but there remain many things that Haskell has a leg up on 
that F# lacks, like dependent types.


-- 
Brett Gilio
brettg at posteo.net | bmg at member.fsf.org
Free Software -- Free Society!

From joshchia at gmail.com  Fri Jul 13 01:50:26 2018
From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=)
Date: Fri, 13 Jul 2018 09:50:26 +0800
Subject: [Haskell-cafe] Lifetime control of webserver
Message-ID: <CALxtSbQs2zQuaZ_afNSFHswdrf89Oc_svgQogsPhpsy=xPPOwQ@mail.gmail.com>

Hi,

My application is not a webserver but needs to run a webserver for part but
not all of its lifetime. Particularly, there's a part that does some
complex computation and I want a webserver to expose its internal
state/progress through HTTP.

It seems that the typical and expected way to use a webserver is to
designate the entire app itself as a webserver, so that functions like the
following are basically infinite loops that serve HTTP:

Web.Scotty.scotty:
http://hackage.haskell.org/package/scotty-0.11.2/docs/Web-Scotty.html#v:scotty

Network.Wai.Handler.Warp.run:
http://hackage.haskell.org/package/warp-3.2.22/docs/Network-Wai-Handler-Warp.html#v:run

Can I run a webserver with explicit control of its lifetime? Particularly,
I want to be able to kill it without killing the app or explicitly serve
one request at a time. I'm not restricted to scotty or warp.

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

From maydwell at gmail.com  Fri Jul 13 02:00:58 2018
From: maydwell at gmail.com (Lyndon Maydwell)
Date: Fri, 13 Jul 2018 12:00:58 +1000
Subject: [Haskell-cafe] Lifetime control of webserver
In-Reply-To: <CALxtSbQs2zQuaZ_afNSFHswdrf89Oc_svgQogsPhpsy=xPPOwQ@mail.gmail.com>
References: <CALxtSbQs2zQuaZ_afNSFHswdrf89Oc_svgQogsPhpsy=xPPOwQ@mail.gmail.com>
Message-ID: <CAM5QZtwKOZ=pTRNc+LQhvjj4ooSyi0U7UeR2wkUTWrb14CMOdw@mail.gmail.com>

Not sure if I'm missing something, but is there any reason why you couldn't
spin up the server in a thread then kill it when required?


 - Lyndon

On Fri, Jul 13, 2018 at 11:51 AM ☂Josh Chia (謝任中) <joshchia at gmail.com>
wrote:

> Hi,
>
> My application is not a webserver but needs to run a webserver for part
> but not all of its lifetime. Particularly, there's a part that does some
> complex computation and I want a webserver to expose its internal
> state/progress through HTTP.
>
> It seems that the typical and expected way to use a webserver is to
> designate the entire app itself as a webserver, so that functions like the
> following are basically infinite loops that serve HTTP:
>
> Web.Scotty.scotty:
> http://hackage.haskell.org/package/scotty-0.11.2/docs/Web-Scotty.html#v:scotty
>
> Network.Wai.Handler.Warp.run:
> http://hackage.haskell.org/package/warp-3.2.22/docs/Network-Wai-Handler-Warp.html#v:run
>
> Can I run a webserver with explicit control of its lifetime? Particularly,
> I want to be able to kill it without killing the app or explicitly serve
> one request at a time. I'm not restricted to scotty or warp.
>
> 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/20180713/a811ca6d/attachment.html>

From vanessa.mchale at iohk.io  Fri Jul 13 02:01:25 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Thu, 12 Jul 2018 21:01:25 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <cd852c1f-dcab-3afa-5018-aaabf917e670@iohk.io>

Oh, and this may not be appropriate for your particular audience, but I
definitely like the fact that you can write some algorithms extremely
elegantly with recursion schemes, viz.

|

import Data.Functor.Foldable import Data.Ratio (Ratio, denominator, (%))

isInteger :: (RealFrac a) => a -> Bool isInteger = idem (realToFrac .
floor) where idem = ((==) <*>)

continuedFraction :: (RealFrac a, Integral b) => a -> [b]
continuedFraction = apo coalgebra where coalgebra x | isInteger x = go $
Left [] | otherwise = go $ Right alpha where alpha = 1 / (x - realToFrac
(floor x)) go = Cons (floor x)

|


I wrote up a whole bunch of examples here:
http://blog.vmchale.com/article/recursion-examples

I think such examples are really great because they are things which are
not possible in Rust (or F#, if I am not mistaken).

On 07/11/2018 07:10 AM, Simon Peyton Jones via Haskell-Cafe wrote:
>
> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the
> Sanger Institute <https://www.sanger.ac.uk/> about Haskell.   They do
> lots of programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer
> the main question in their minds: /why should I even care about
> Haskell/?  I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk
> generalities, I’d love to illustrate with copious examples of
> beautiful code.
>
>   * Can you identify a few lines of Haskell that best characterise
>     what you think makes Haskell distinctively worth caring about?  
>     Something that gave you an “aha” moment, or that feeling of joy
>     when you truly make sense of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell,
> so muttering about Cartesian Closed Categories isn’t going to do it
> for them.  I need examples that I can present in 5 minutes, without
> needing a long setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in
> C notoriously prone to fencepost errors etc.  But it also makes much
> less good use of memory, and is likely to run slower.  I think I can
> do that in 5 minutes.
>
> Another thing that I think comes over easily is the ability to
> abstract: generalising sum and product to fold by abstracting out a
> functional argument; generalising at the type level by polymorphism,
> including polymorphism over higher-kinded type constructors.   Maybe 8
> minutes.
>
> But you will have more and better ideas, and (crucially) ideas that
> are more credibly grounded in the day to day reality of writing
> programs that get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I
> love the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant
> for the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be
> helpful to more than just me.
>
> Simon
>
>
>
> _______________________________________________
> 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/20180712/ae1e74c9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180712/ae1e74c9/attachment.sig>

From joshchia at gmail.com  Fri Jul 13 02:32:47 2018
From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=)
Date: Fri, 13 Jul 2018 10:32:47 +0800
Subject: [Haskell-cafe] Lifetime control of webserver
In-Reply-To: <CAM5QZtwKOZ=pTRNc+LQhvjj4ooSyi0U7UeR2wkUTWrb14CMOdw@mail.gmail.com>
References: <CALxtSbQs2zQuaZ_afNSFHswdrf89Oc_svgQogsPhpsy=xPPOwQ@mail.gmail.com>
 <CAM5QZtwKOZ=pTRNc+LQhvjj4ooSyi0U7UeR2wkUTWrb14CMOdw@mail.gmail.com>
Message-ID: <CALxtSbT4vT5OG1K7CbePJZkoNgwwb8S+gzgGQmtmpis+1btu3Q@mail.gmail.com>

Do you mean something like calling the scotty function in a server thread
and then killing the server thread when I want to stop serving? If proper
cleanup happens when I kill the thread, this should work for me.

On Fri, Jul 13, 2018 at 10:01 AM Lyndon Maydwell <maydwell at gmail.com> wrote:

> Not sure if I'm missing something, but is there any reason why you
> couldn't spin up the server in a thread then kill it when required?
>
>
>  - Lyndon
>
> On Fri, Jul 13, 2018 at 11:51 AM ☂Josh Chia (謝任中) <joshchia at gmail.com>
> wrote:
>
>> Hi,
>>
>> My application is not a webserver but needs to run a webserver for part
>> but not all of its lifetime. Particularly, there's a part that does some
>> complex computation and I want a webserver to expose its internal
>> state/progress through HTTP.
>>
>> It seems that the typical and expected way to use a webserver is to
>> designate the entire app itself as a webserver, so that functions like the
>> following are basically infinite loops that serve HTTP:
>>
>> Web.Scotty.scotty:
>> http://hackage.haskell.org/package/scotty-0.11.2/docs/Web-Scotty.html#v:scotty
>>
>> Network.Wai.Handler.Warp.run:
>> http://hackage.haskell.org/package/warp-3.2.22/docs/Network-Wai-Handler-Warp.html#v:run
>>
>> Can I run a webserver with explicit control of its lifetime?
>> Particularly, I want to be able to kill it without killing the app or
>> explicitly serve one request at a time. I'm not restricted to scotty or
>> warp.
>>
>> 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/20180713/501e582d/attachment.html>

From maydwell at gmail.com  Fri Jul 13 02:54:41 2018
From: maydwell at gmail.com (Lyndon Maydwell)
Date: Fri, 13 Jul 2018 12:54:41 +1000
Subject: [Haskell-cafe] Lifetime control of webserver
In-Reply-To: <CALxtSbT4vT5OG1K7CbePJZkoNgwwb8S+gzgGQmtmpis+1btu3Q@mail.gmail.com>
References: <CALxtSbQs2zQuaZ_afNSFHswdrf89Oc_svgQogsPhpsy=xPPOwQ@mail.gmail.com>
 <CAM5QZtwKOZ=pTRNc+LQhvjj4ooSyi0U7UeR2wkUTWrb14CMOdw@mail.gmail.com>
 <CALxtSbT4vT5OG1K7CbePJZkoNgwwb8S+gzgGQmtmpis+1btu3Q@mail.gmail.com>
Message-ID: <CAM5QZtzEsE3eYWWSfGzm+GgOzz54NdeVNrS+=MaWgFWGYcyGmQ@mail.gmail.com>

Yes that's what I had in mind.

You can do some fun things with Control.Concurrent.Chan as well if you need
special sequencing, or limits on requests served or callbacks into the main
thread etc.

 - Lyndon

On Fri, Jul 13, 2018 at 12:32 PM ☂Josh Chia (謝任中) <joshchia at gmail.com>
wrote:

> Do you mean something like calling the scotty function in a server thread
> and then killing the server thread when I want to stop serving? If proper
> cleanup happens when I kill the thread, this should work for me.
>
> On Fri, Jul 13, 2018 at 10:01 AM Lyndon Maydwell <maydwell at gmail.com>
> wrote:
>
>> Not sure if I'm missing something, but is there any reason why you
>> couldn't spin up the server in a thread then kill it when required?
>>
>>
>>  - Lyndon
>>
>> On Fri, Jul 13, 2018 at 11:51 AM ☂Josh Chia (謝任中) <joshchia at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> My application is not a webserver but needs to run a webserver for part
>>> but not all of its lifetime. Particularly, there's a part that does some
>>> complex computation and I want a webserver to expose its internal
>>> state/progress through HTTP.
>>>
>>> It seems that the typical and expected way to use a webserver is to
>>> designate the entire app itself as a webserver, so that functions like the
>>> following are basically infinite loops that serve HTTP:
>>>
>>> Web.Scotty.scotty:
>>> http://hackage.haskell.org/package/scotty-0.11.2/docs/Web-Scotty.html#v:scotty
>>>
>>> Network.Wai.Handler.Warp.run:
>>> http://hackage.haskell.org/package/warp-3.2.22/docs/Network-Wai-Handler-Warp.html#v:run
>>>
>>> Can I run a webserver with explicit control of its lifetime?
>>> Particularly, I want to be able to kill it without killing the app or
>>> explicitly serve one request at a time. I'm not restricted to scotty or
>>> warp.
>>>
>>> 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/20180713/3e36a25e/attachment-0001.html>

From jo at durchholz.org  Fri Jul 13 06:27:43 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 13 Jul 2018 08:27:43 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <87fu0ow3ih.fsf@colimite.fr>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <CAPq5PvK7s1qnhJhoG3wo_JVO_xrXXLrHHVugM1i=xJ+aR76d9A@mail.gmail.com>
 <5b4795d1.1c69fb81.15e76.2a68@mx.google.com>
 <CAPq5PvJ7+3EzGMGKJ0ACQvKjbJiBCzyS07hjps3CN4xBNBXnqg@mail.gmail.com>
 <5b479ae8.1c69fb81.1565b.c7fd@mx.google.com>
 <CAPq5PvLSBQ0K7J-9Qqc_q6_3FFnGc=-6GVfsJMNEYG3et_q22g@mail.gmail.com>
 <87fu0ow3ih.fsf@colimite.fr>
Message-ID: <68e1dc88-1ab0-02bf-3fac-3f23657db4e3@durchholz.org>

Am 12.07.2018 um 23:25 schrieb Sergiu Ivanov:
> Hello Chris,
> 
> Thus quoth  Chris Smith  on Thu Jul 12 2018 at 22:48 (+0200):
>> I've seen plenty of students as old as 12 to 13 who literally cannot
>> see whether there's a comma in an expression, or whether a word is
>> spelled "ie" or "ei", without extreme measures like covering the
>> surrounding text.
> 
> This sounds a lot like symptoms of dyslexia.  Are you talking about
> students _without_ such disorders?
Of course they are dyslexic - it's defined as having lower reading 
capabilities than their peers.

It doesn't matter much. Most children catch up on their reading 
capabilities, or they learn to cope.
And IQ is not correlated to reading (or writing) ability, so it is 
useful to introduce them to the field if possible.
Even IQ isn't too relevant to the ability to code. IQ measures a whole 
lot of pretty unrelated things, and while the ability to code and IQ are 
correlated, they are not 1:1.

Regards,
Jo

From jo at durchholz.org  Fri Jul 13 06:47:56 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 13 Jul 2018 08:47:56 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
Message-ID: <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>

Am 13.07.2018 um 01:40 schrieb Tony Morris:
> On python, we are fixing it (WIP):
> https://github.com/qfpl/hpython

Some poisonous aspects of Python are unfixable.
E.g. having declarations as program-visible update to a global state 
causes all kinds of unnecessary pain, such as having to deal with 
half-initialized peer modules during module initialization.

> Did you see the recent "default mutable arguments" post?
> https://lethain.com/digg-v4/

Yeah, the "default parameter is an empty list but that's then going to 
be updated across invocations" classic.
Other languages have made the same mistake. Default data needs to be 
either immutable or recreated on each call.
Such mistakes can be mitigated, but they cannot be fixed while staying 
backwards-compatible.

Python actually did an incompatible switch from 2 to 3, but for some 
reason Guido didn't fix the above two, or some other things (such as 
Python's broken idea of multiple inheritance, or the horribly 
overcomplicated way annotations work).
Python is nice for small tasks. If you accept its invitation to extend 
it you get fragility (due to the inability to define hard constraints so 
whatever you extend will violate *somebody's* assumptions), and if you 
scale to large systems you get fragility as well (because Python 
modularization is too weak).

Well, enough of the off-topic thing here.

> On 07/12/2018 07:58 PM, Brett Gilio wrote:
>> Python is poison, indeed. ;)

From tonymorris at gmail.com  Fri Jul 13 06:52:58 2018
From: tonymorris at gmail.com (Tony Morris)
Date: Fri, 13 Jul 2018 16:52:58 +1000
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
 <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
Message-ID: <e0e3fe57-d3dc-ca4f-dbda-f810b7ac5c18@gmail.com>

I am not fixing python. I am fixing the consequences of the fact that it
exists.


On 07/13/2018 04:47 PM, Joachim Durchholz wrote:
> Am 13.07.2018 um 01:40 schrieb Tony Morris:
>> On python, we are fixing it (WIP):
>> https://github.com/qfpl/hpython
>
> Some poisonous aspects of Python are unfixable.
> E.g. having declarations as program-visible update to a global state
> causes all kinds of unnecessary pain, such as having to deal with
> half-initialized peer modules during module initialization.
>
>> Did you see the recent "default mutable arguments" post?
>> https://lethain.com/digg-v4/
>
> Yeah, the "default parameter is an empty list but that's then going to
> be updated across invocations" classic.
> Other languages have made the same mistake. Default data needs to be
> either immutable or recreated on each call.
> Such mistakes can be mitigated, but they cannot be fixed while staying
> backwards-compatible.
>
> Python actually did an incompatible switch from 2 to 3, but for some
> reason Guido didn't fix the above two, or some other things (such as
> Python's broken idea of multiple inheritance, or the horribly
> overcomplicated way annotations work).
> Python is nice for small tasks. If you accept its invitation to extend
> it you get fragility (due to the inability to define hard constraints
> so whatever you extend will violate *somebody's* assumptions), and if
> you scale to large systems you get fragility as well (because Python
> modularization is too weak).
>
> Well, enough of the off-topic thing here.
>
>> On 07/12/2018 07:58 PM, Brett Gilio wrote:
>>> Python is poison, indeed. ;)
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180713/1359a21a/attachment.sig>

From aquagnu at gmail.com  Fri Jul 13 07:07:41 2018
From: aquagnu at gmail.com (PY)
Date: Fri, 13 Jul 2018 10:07:41 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavouriteHaskell "aha" moment?)
In-Reply-To: <CAPq5PvLSBQ0K7J-9Qqc_q6_3FFnGc=-6GVfsJMNEYG3et_q22g@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <CAPq5PvK7s1qnhJhoG3wo_JVO_xrXXLrHHVugM1i=xJ+aR76d9A@mail.gmail.com>
 <5b4795d1.1c69fb81.15e76.2a68@mx.google.com>
 <CAPq5PvJ7+3EzGMGKJ0ACQvKjbJiBCzyS07hjps3CN4xBNBXnqg@mail.gmail.com>
 <5b479ae8.1c69fb81.1565b.c7fd@mx.google.com>
 <CAPq5PvLSBQ0K7J-9Qqc_q6_3FFnGc=-6GVfsJMNEYG3et_q22g@mail.gmail.com>
Message-ID: <5534296f-486c-d9bc-c7f0-13a3e5c9803c@gmail.com>

12.07.2018 23:48, Chris Smith wrote:
> This is a good question, and I think it depends on your goals.
>
> If your goal is to inspire interest and attract children to 
> programming, then you are best served by making it obvious what can 
> and can't be done, and making it very difficult to make a mistake.  
> Some visual languages are very good at this, and Scratch, for example, 
> is a good example.  Going even further, Scratch and similar languages 
> are often used in situations where the students can do literally 
> anything, and *something* interesting happens, inspiring that spark of 
> excitement and feeling of "I did that!"  This is a magical moment, and 
> it can change lives.
>
> On the other hand, building new skills is the point of educating.  
> Avoiding the need for new skills means avoiding the opportunity to 
> learn.  Children often still struggle with precise perception.  I've 
> seen plenty of students as old as 12 to 13 who literally cannot see 
> whether there's a comma in an expression, or whether a word is spelled 
> "ie" or "ei", without extreme measures like covering the surrounding 
> text.  Their brain just skips over these concerns.  Of course, they 
> struggle in mathematics, and also basic language and communication.  
> Once again, one can avoid the problem and try to help them to be 
> successful

Yes! Even more, mature brain has such selectivity too :)
We can miss something totally, because most people are thinking in 
traditional, standard ways (something like good known roads) and will 
not take new knowledge but will dispute with new knowledge and to try to 
ignore it or "destroy it mentally", but this is a slightly different 
disease ;)

> without needing that skill, which a visual language is great at.  But 
> of course, they ultimately do need the skill in order to communicate 
> in the first place!  So there's also value in placing them in an 
> environment where they need to learn it.  When making this decision, 
> though, it's important to focus on skills that are truly necessary, 
> and not (for example) remembering what order to write "public static 
> void main" in their Java programs.
>
> On Thu, Jul 12, 2018 at 2:16 PM Paul <aquagnu at gmail.com 
> <mailto:aquagnu at gmail.com>> wrote:
>
>     Wooow! Yes!!
>
>     But today there is serious competition (Smalltalk, Python; I
>     planned Scratch – but it’s for children of 7-9 years). I thing you
>     are good teacher 😊
>
>     Btw, what do you think: what is better – textual programming or
>     visual programming for children? For me, Labview/G was insight in
>     90s 😊Today there is Luna language – it’s visual too. IMHO visual
>     programming better illustrates ideas/concepts, or?
>
>     *From: *Chris Smith <mailto:cdsmith at gmail.com>
>     *Sent: *12 июля 2018 г. 21:00
>     *To: *aquagnu at gmail.com <mailto:aquagnu at gmail.com>
>     *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
>     yourfavouriteHaskell "aha" moment?)
>
>     Perhaps you mean something fun and visual like this?
>     https://code.world/#PhFFj32Bx0FcpQvvoVJW0xw
>
>     Or this? https://code.world/#PO1BKCj-kA9ztKKnE7rOueA
>
>     These are written in the simplified variant of Haskell that I
>     teach, which uses a custom Prelude that skips type classes and
>     other advanced features, uses rebindable syntax to simplify types
>     (for example, you'll see Number instead of Int, Double, etc.), and
>     automatically provides graphics functions that work in the browser.
>
>     On Thu, Jul 12, 2018 at 1:54 PM Paul <aquagnu at gmail.com
>     <mailto:aquagnu at gmail.com>> wrote:
>
>         Hmm, Chris, thanks for answer. Interesting. I was surprised
>         when I first learned that someone somewhere is teaching the
>         children to Haskell, but if you say so – then it’s possible
>         and may be it’s good! 😊
>
>         Sometimes children don’t like right things, but like fun. So,
>         I though that more preferable to show them some bright demo:
>         UI, graphics, some simple games, databases, to rise the
>         interest, you know – this feeling of first code. First “wooow!
>         It works!!!” 😊Haskell, for me, looks pedantic, not for fun.
>         May be I’m not right, I have not such experience.
>
>         *From: *Chris Smith <mailto:cdsmith at gmail.com>
>         *Sent: *12 июля 2018 г. 19:59
>         *To: *aquagnu at gmail.com <mailto:aquagnu at gmail.com>
>         *Subject: *Re: [Haskell-cafe] Investing in languages (Was:
>         What is yourfavourite Haskell "aha" moment?)
>
>         I'll answer this, since I have been teaching Haskell to
>         children for six years or so. :)
>
>         I think it's important to distinguish between Haskell AS USED
>         in most of the community, and Haskell as it COULD be used.  I
>         agree that you don't want to teach the first of those to
>         children.  But Haskell is still a great teaching choice,
>         mainly because GHC is so configurable that you can create the
>         environment you want, and just build it with a Haskell
>         compiler. With GHC plugins, this is becoming even more true,
>         but it already arises from a combination of (a) very
>         lightweight and intuitive core syntax in the first place, (b)
>         great support for custom preludes, and (c) the
>         RebindableSyntax extension, and the fact that so much syntax
>         is defined in terms of desugaring.
>
>         If you're seriously talking about teaching children, then your
>         concerns about web frameworks and such are a bit silly. 
>         (Unless by "children" you meant mid to late teens and after,
>         in which case this becomes relevant.)  "Advanced" type
>         features are also not particularly relevant (though there's
>         some fuzziness about what counts as "advanced"; for instance,
>         I've recently decided it's better to teach GADT syntax as the
>         only option for defining algebraic data types, even though I
>         never expect most students to take advantage of the extra
>         power of GADTs.)
>
>         The main concern I have with F#, though, is that the semantics
>         are far too complex.  It has all the power of a functional
>         language, but none of the semantic simplicity. If students
>         already struggle with compositional programming (and they do),
>         they struggle even more when the simplest way to understand
>         what's going on -- namely, substitution -- is taken away from
>         them.  If you're going to teach a computational model based on
>         sequencing actions on a global state (the state being the
>         screen, network, etc.), then you might as well include mutable
>         variables in that global state, and you might as well teach
>         Python, which will at least be more intuitive, if not simpler.
>
>         On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu at gmail.com
>         <mailto:aquagnu at gmail.com>> wrote:
>
>             I am afraid that it can lead to flame again, but F# has
>             super-capacity: you can check measuring units, type
>             providers, computation expressions, active patterns,
>             static/dynamic types constraints, constraints on existing
>             method, etc... It's clean, borrows some ideas from
>             Haskell, some are original and Haskell borrows them (but
>             with worse implementation). IMHO for children teaching to
>             FP F# is the best. Even more, currently C# also has a lot
>             of FP features
>             (https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification
>             -- is not it super easy and beauty?). Rust is more low
>             level: you should think about memory "management", OOP has
>             some problems... And serious argument for children
>             teaching: salary trends (joke sure) :-) But you can
>             compare salary in F# and Haskell, for example - people
>             often choice language after check current salaries in the
>             market. Also F# is more focused on realistic tasks and
>             business value. It lacks performance, UWP yet (but in
>             progress)... To feel how F# is sexy compare Web
>             application written in Websharper and in any Haskell
>             framework. Haskell is beauty but I'm afraid its fate
>             unfortunately will be the same as one of Common Lisp,
>             NetBSD, etc - it's ground for ideas and experiments and
>             has disputable design. Also it's more-more difficult to
>             teach children to Haskell than to F#...
>
>             IMHO is general to teach FP is more easy than to teach OOP
>             if FP is not Haskell (some language which targets more
>             eager/efficient/dynamic/real goals instead of abstract
>             types playing).
>
>             12.07.2018 13:28, Vanessa McHale wrote:
>
>                 I wouldn't say Rust has a large capacity for FP. I am not familiar with
>
>                 F#. The thing that makes FP infeasible in Rust is not the lack of purity
>
>                 but rather the fact that affine types make it difficult to treat
>
>                 functions as first-class values.
>
>                   
>
>                   
>
>                 On 07/12/2018 01:40 AM, Brett Gilio wrote:
>
>                     Tony,
>
>                       
>
>                     I am curious on your attitude towards multi-paradigm and ML-like
>
>                     languages. I agree that functional programming is easily the better of
>
>                     the bundle in many forms of application logic and elegance (which is
>
>                     why I have come to love Scheme and Haskell), but do you see any room
>
>                     for those languages like F# or Rust which have large capacities for FP
>
>                     but are either functional-first (but not pure) or a hybrid?
>
>                       
>
>                     Brett Gilio
>
>                       
>
>                     On 07/12/2018 01:35 AM, Tony Morris wrote:
>
>                            I used to teach undergrad OOP nonsense. I have been teaching FP for 15
>
>                         years. [^1]
>
>                           
>
>                         The latter is *way* easier. Existing programmers are more difficult than
>
>                         children, but still way easier to teach FP than all the other stuff.
>
>                           
>
>                         [^1]: Canberra anyone?https://qfpl.io/posts/2018-canberra-intro-to-fp/
>
>                           
>
>                           
>
>                         On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>
>                             Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>
>                                   
>
>                                 I speak only from my own narrow perspective. I'd say programming is
>
>                                 hard, but functional programming is harder.
>
>                               
>
>                             Actually it's pretty much the opposite, I hear from teachers.
>
>                               
>
>                                 Maybe that's why Java replaced Haskell in some universities
>
>                                 curricula
>
>                             The considerations are marketable skills.
>
>                             A considerable fraction of students is looking at the curriculum and
>
>                             at job offers, and if they find that the lists don't match, they will
>
>                             go to another university.
>
>                             Also, industry keeps lobbying for teaching skills that they can use.
>
>                             Industry can give money to universities so this gives them influence
>
>                             on the curriculum (and only if they get time to talk the topic over
>
>                             with the dean). This aspect can vary considerably between countries,
>
>                             depending on how much money the universities tend to acquire from
>
>                             industry.
>
>                               
>
>                                 https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>
>                                 most programmers I know are not scared of learning OO, but they fear
>
>                                 functional programming.
>
>                               
>
>                             Programmers were *very* scared of OO in the nineties. It took roughly
>
>                             a decade or two (depending on where you put the starting point) to get
>
>                             comfortable with OO.
>
>                               
>
>                                   
>
>                                 I think the reason might be that OO concepts
>
>                                 like inheritance and passing messages between objects are a bit more
>
>                                 concrete and easier to grasp (when you present toy examples at least).
>
>                               
>
>                             OO is about how to deal with having to pack everything into its own
>
>                             class (and how to arrange stuff into classes).
>
>                             Functional is about how to deal with the inability to update. Here,
>
>                             the functional camp actually has the easier job, because you can just
>
>                             tell people to just write code that creates new data objects and get
>
>                             over with it. Performance concerns can be handwaved away by saying
>
>                             that the compiler is hyper-aggressive, and "you can look at the
>
>                             intermediate code if you suspect the compiler is the issue".
>
>                             (Functional is a bit similar to SQL here, but the SQL optimizers are
>
>                             much less competent than GHC at detecting optimization opportunities.)
>
>                               
>
>                                 Then you have design patterns, which have intuitive names and give
>
>                                 some very general guidelines that one can try after reading them (and
>
>                                 add his/her own personal twist). I doubt people can read the Monad
>
>                                 laws and make any sense out of them at the first try.
>
>                               
>
>                             That's true, but much of the misconceptions around monads from the
>
>                             first days have been cleared up.
>
>                             But yes the monad laws are too hard to read. OTOH you won't be able to
>
>                             read the Tree code in the JDK without the explanations either.
>
>                             _______________________________________________
>
>                             Haskell-Cafe mailing list
>
>                             To (un)subscribe, modify options or view archives go to:
>
>                             http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>                             Only members subscribed via the mailman list are allowed to post.
>
>                           
>
>                           
>
>                           
>
>                           
>
>                         _______________________________________________
>
>                         Haskell-Cafe mailing list
>
>                         To (un)subscribe, modify options or view archives go to:
>
>                         http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>                         Only members subscribed via the mailman list are allowed to post.
>
>                           
>
>                     _______________________________________________
>
>                     Haskell-Cafe mailing list
>
>                     To (un)subscribe, modify options or view archives go to:
>
>                     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>                     Only members subscribed via the mailman list are allowed to post.
>
>                   
>
>                 _______________________________________________
>
>                 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/20180713/0cfd2b4b/attachment.html>

From aquagnu at gmail.com  Fri Jul 13 07:17:05 2018
From: aquagnu at gmail.com (PY)
Date: Fri, 13 Jul 2018 10:17:05 +0300
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
Message-ID: <f0b61b68-72db-c306-793e-e9c9c54b8b69@gmail.com>

13.07.2018 02:40, Tony Morris wrote:
> On python, we are fixing it (WIP):
> https://github.com/qfpl/hpython
>
> Did you see the recent "default mutable arguments" post?
> https://lethain.com/digg-v4/
>
> Here is a Haskell program that transforms any python program that uses
> default mutable arguments:
> https://github.com/qfpl/hpython/blob/master/example/FixMutableDefaultArguments.hs
>
> Someone once said that python will never have tail call optimisation.
> Here is the Haskell program that transforms any Python (direct only)
> tail call into a loop:
> https://github.com/qfpl/hpython/blob/master/example/OptimizeTailRecursion.hs
>
> Two python programmers once argued over preferred indentation levels.
> Let's put their disagreement into a Haskell function so that they can
> stop arguing:
> https://github.com/qfpl/hpython/blob/master/example/Indentation.hs

IMHO will be good to port such successful "experiments" to PyPy project 
in some way, if it's possible

>
> On 07/12/2018 07:58 PM, Brett Gilio wrote:
>> Python is poison, indeed. ;)
>>
>> Brett Gilio
>> brettg at posteo.net | bmg at member.fsf.org
>> Free Software -- Free Society!
>>
>> On 07/12/2018 04:56 AM, Graham Klyne wrote:
>>> Although I don't program regularly in Haskell these days (my poison
>>> is Python, mainly for Web framework support), I do occasionally find
>>> myself coding tricky manipulations in Haskell first as I find it
>>> easier to concentrate on the essentials of an algorithm.  Once I have
>>> the Haskell code written and tested, I generally find it fairly easy
>>> to map the algorithm into Python (using higher order functions as
>>> appropriate).
>>>
>>> Here are some examples:
>>>
>>> https://github.com/gklyne/annalist/blob/master/spike/rearrange-list/move_up.lhs
>>>
>>> https://github.com/gklyne/annalist/blob/master/spike/tree-scan/tree_scan.lhs
>>>
>>>
>>> And the corresponding code in the actual application:
>>>
>>> https://github.com/gklyne/annalist/blob/4d21250a3457c72d4f6525e5a4fac40d4c0ca1c8/src/annalist_root/annalist/views/entityedit.py#L2489
>>>
>>>
>>> https://github.com/gklyne/annalist/blob/master/src/annalist_root/annalist/models/entity.py#L245
>>>
>>>
>>> #g
>>> -- 
>>>
>>>
>>> On 11/07/2018 13:10, Simon Peyton Jones via Haskell-Cafe wrote:
>>>> Friends
>>>> In a few weeks I'm giving a talk to a bunch of genomics folk at the
>>>> Sanger Institute<https://www.sanger.ac.uk/> about Haskell.   They do
>>>> lots of programming, but they aren't computer scientists.
>>>> I can tell them plenty about Haskell, but I'm ill-equipped to answer
>>>> the main question in their minds: why should I even care about
>>>> Haskell?  I'm too much of a biased witness.
>>>>
>>>> So I thought I'd ask you for help.  War stories perhaps - how using
>>>> Haskell worked (or didn't) for you.  But rather than talk
>>>> generalities, I'd love to illustrate with copious examples of
>>>> beautiful code.
>>>>
>>>>     *   Can you identify a few lines of Haskell that best
>>>> characterise what you think makes Haskell distinctively worth caring
>>>> about?   Something that gave you an "aha" moment, or that feeling of
>>>> joy when you truly make sense of something for the first time.
>>>> The challenge is, of course, that this audience will know no
>>>> Haskell, so muttering about Cartesian Closed Categories isn't going
>>>> to do it for them.  I need examples that I can present in 5 minutes,
>>>> without needing a long setup.
>>>> To take a very basic example, consider Quicksort using list
>>>> comprehensions, compared with its equivalent in C.  It's so short,
>>>> so obviously right, whereas doing the right thing with in-place
>>>> update in C notoriously prone to fencepost errors etc.  But it also
>>>> makes much less good use of memory, and is likely to run slower.  I
>>>> think I can do that in 5 minutes.
>>>> Another thing that I think comes over easily is the ability to
>>>> abstract: generalising sum and product to fold by abstracting out a
>>>> functional argument; generalising at the type level by polymorphism,
>>>> including polymorphism over higher-kinded type constructors.   Maybe
>>>> 8 minutes.
>>>> But you will have more and better ideas, and (crucially) ideas that
>>>> are more credibly grounded in the day to day reality of writing
>>>> programs that get work done.
>>>> Pointers to your favourite blog posts would be another avenue.  (I
>>>> love the Haskell Weekly News.)
>>>> Finally, I know that some of you use Haskell specifically for
>>>> genomics work, and maybe some of your insights would be particularly
>>>> relevant for the Sanger audience.
>>>> Thank you!  Perhaps your responses on this thread (if any) may be
>>>> helpful to more than just me.
>>>> Simon
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
> _______________________________________________
> 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/20180713/f0df7c42/attachment.html>

From aquagnu at gmail.com  Fri Jul 13 07:38:41 2018
From: aquagnu at gmail.com (PY)
Date: Fri, 13 Jul 2018 10:38:41 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
Message-ID: <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>

13.07.2018 02:52, Brett Gilio wrote:
> On 07/12/2018 06:46 AM, PY wrote:
>  written in Websharper and in any Haskell framework. Haskell is beauty
>> but I'm afraid its fate unfortunately will be the same as one of 
>> Common Lisp, NetBSD, etc - it's ground for ideas and experiments and 
>> has disputable design. Also it's more-more difficult to teach 
>> children to Haskell than to F#...
https://jackfoxy.github.io/DependentTypes/
https://github.com/caindy/DependentTypesProvider
Discussion: https://news.ycombinator.com/item?id=15852517

Also F# has F*  ;)

> I wonder if this is simply a result of the marketing of the language, 
> itself, rather than the strength of the language. I agree, F# has a 
> lot of beauty, but there remain many things that Haskell has a leg up 
> on that F# lacks, like dependent types
IMHO there are several reasons:

1. Haskell limits itself to lambda-only. Example, instead to add other 
abstractions and to become modern MULTI-paradigm languages, it keeps 
lambda, so record accessors leading to names collision will lead to 
adding of 1,2 extensions to the language instead to add standard syntax 
(dot, sharp, something similar). So, point #1 is limitation in 
abstraction: monads, transformers, anything - is function. It's not 
good. There were such languages already: Forth, Joy/Cat, APL/J/K... Most 
of them look dead. When you try to be elegant, your product (language) 
died. This is not my opinion, this is only my observation. People like 
diversity and variety: in food, in programming languages, in relations, 
anywhere :)

2. When language has killer app and killer framework, IMHO it has more 
chances. But if it has _killer ideas_ only... So, those ideas will be 
re-implemented in other languages and frameworks but with more simple 
and typical syntax :)  It's difficult to compete with product, 
framework, big library, but it's easy to compete with ideas. It's an 
observation too :-) You can find it in politics for example. Or in 
industry. To repeat big solution is more difficult, but we are neutrally 
to languages, language itself is not argument for me. Argument for me (I 
am usual developer) are killer apps/frameworks/libraries/ecosystem/etc. 
Currently Haskell has stack only - it's very good, but most languages 
has similar tools (not all have LTS analogue, but big frameworks are the 
same).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180713/a72ee9b5/attachment.html>

From aquagnu at gmail.com  Fri Jul 13 07:54:44 2018
From: aquagnu at gmail.com (PY)
Date: Fri, 13 Jul 2018 10:54:44 +0300
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
 <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
Message-ID: <d2392c04-1e6b-f07d-9b85-137504e6ff62@gmail.com>

13.07.2018 09:47, Joachim Durchholz wrote:
> Am 13.07.2018 um 01:40 schrieb Tony Morris:
>> On python, we are fixing it (WIP):
>> https://github.com/qfpl/hpython
>
> Some poisonous aspects of Python are unfixable.
> E.g. having declarations as program-visible update to a global state 
> causes all kinds of unnecessary pain, such as having to deal with 
> half-initialized peer modules during module initialization.
>
I never understand that point. Mostly Python programs have not global 
state, only global constants. You can have "application" monad in 
Haskell (read), the same in Python: most Python programmers create some 
Application class. Also OOP has long been solved "global state" problem, 
for example, Smalltalk (similar idea you can find in Erlang): state is 
hidden behind some FSM which is represented as class (process in 
Erlang). You can not change state anywhere, you can only send message. 
FSM guards you from any errors. Even more, FSM-style is super safe and 
robust: you can visualize its behavior, to develop it very quickly, to 
debug it easy, final code usually does not contain errors even...

Even I can imagine read monad with big record inside with a lot of 
fields, flags, etc and to get absolutely the same spaghetti code with 
flags manipulation and testing in Haskell, but under monad ;)

>> Did you see the recent "default mutable arguments" post?
>> https://lethain.com/digg-v4/
>
> Yeah, the "default parameter is an empty list but that's then going to 
> be updated across invocations" classic.
> Other languages have made the same mistake. Default data needs to be 
> either immutable or recreated on each call.
> Such mistakes can be mitigated, but they cannot be fixed while staying 
> backwards-compatible.
>
> Python actually did an incompatible switch from 2 to 3, but for some 
> reason Guido didn't fix the above two, or some other things (such as 
> Python's broken idea of multiple inheritance, or the horribly 
> overcomplicated way annotations work).
> Python is nice for small tasks. If you accept its invitation to extend 
> it you get fragility (due to the inability to define hard constraints 
> so whatever you extend will violate *somebody's* assumptions), and if 
> you scale to large systems you get fragility as well (because Python 
> modularization is too weak).
>


Interesting here is that there are a big enterprise products written in 
Python and they are very useful: 
https://www.codeinstitute.net/blog/7-popular-software-programs-written-in-python/



> Well, enough of the off-topic thing here.
>
>> On 07/12/2018 07:58 PM, Brett Gilio wrote:
>>> Python is poison, indeed. ;)
> _______________________________________________
> 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 asandroq at gmail.com  Fri Jul 13 07:59:10 2018
From: asandroq at gmail.com (Alex Silva)
Date: Fri, 13 Jul 2018 09:59:10 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <d2392c04-1e6b-f07d-9b85-137504e6ff62@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
 <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
 <d2392c04-1e6b-f07d-9b85-137504e6ff62@gmail.com>
Message-ID: <a7be8500-83ba-b94c-6f42-d211070f5711@gmail.com>

Hallo,

On 13/07/18 09:54, PY wrote:
> Application class. Also OOP has long been solved "global state" problem,
https://en.wikipedia.org/wiki/Singleton_pattern

Cheers,
-- 
-alex
https://unendli.ch/

From dburke.gw at gmail.com  Fri Jul 13 13:12:42 2018
From: dburke.gw at gmail.com (Doug Burke)
Date: Fri, 13 Jul 2018 09:12:42 -0400
Subject: [Haskell-cafe] Lifetime control of webserver
In-Reply-To: <CAM5QZtzEsE3eYWWSfGzm+GgOzz54NdeVNrS+=MaWgFWGYcyGmQ@mail.gmail.com>
References: <CALxtSbQs2zQuaZ_afNSFHswdrf89Oc_svgQogsPhpsy=xPPOwQ@mail.gmail.com>
 <CAM5QZtwKOZ=pTRNc+LQhvjj4ooSyi0U7UeR2wkUTWrb14CMOdw@mail.gmail.com>
 <CALxtSbT4vT5OG1K7CbePJZkoNgwwb8S+gzgGQmtmpis+1btu3Q@mail.gmail.com>
 <CAM5QZtzEsE3eYWWSfGzm+GgOzz54NdeVNrS+=MaWgFWGYcyGmQ@mail.gmail.com>
Message-ID: <CALkjVLCb64xg6uFgB4qYF8zO0oBOc1Y2CRnp5cWX91UOEMMy8w@mail.gmail.com>

You could also look at ekg for "inspiration" (at least for the "expose data
via a URL" part): http://hackage.haskell.org/package/ekg

Doug

On Thu, Jul 12, 2018 at 10:55 PM Lyndon Maydwell <maydwell at gmail.com> wrote:

> Yes that's what I had in mind.
>
> You can do some fun things with Control.Concurrent.Chan as well if you
> need special sequencing, or limits on requests served or callbacks into the
> main thread etc.
>
>
>  - Lyndon
>
> On Fri, Jul 13, 2018 at 12:32 PM ☂Josh Chia (謝任中) <joshchia at gmail.com>
> wrote:
>
>> Do you mean something like calling the scotty function in a server thread
>> and then killing the server thread when I want to stop serving? If proper
>> cleanup happens when I kill the thread, this should work for me.
>>
>> On Fri, Jul 13, 2018 at 10:01 AM Lyndon Maydwell <maydwell at gmail.com>
>> wrote:
>>
>>> Not sure if I'm missing something, but is there any reason why you
>>> couldn't spin up the server in a thread then kill it when required?
>>>
>>>
>>>  - Lyndon
>>>
>>> On Fri, Jul 13, 2018 at 11:51 AM ☂Josh Chia (謝任中) <joshchia at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> My application is not a webserver but needs to run a webserver for part
>>>> but not all of its lifetime. Particularly, there's a part that does some
>>>> complex computation and I want a webserver to expose its internal
>>>> state/progress through HTTP.
>>>>
>>>> It seems that the typical and expected way to use a webserver is to
>>>> designate the entire app itself as a webserver, so that functions like the
>>>> following are basically infinite loops that serve HTTP:
>>>>
>>>> Web.Scotty.scotty:
>>>> http://hackage.haskell.org/package/scotty-0.11.2/docs/Web-Scotty.html#v:scotty
>>>>
>>>> Network.Wai.Handler.Warp.run:
>>>> http://hackage.haskell.org/package/warp-3.2.22/docs/Network-Wai-Handler-Warp.html#v:run
>>>>
>>>> Can I run a webserver with explicit control of its lifetime?
>>>> Particularly, I want to be able to kill it without killing the app or
>>>> explicitly serve one request at a time. I'm not restricted to scotty or
>>>> warp.
>>>>
>>>> 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.
>>>
>>> _______________________________________________
> 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/20180713/cd6680d5/attachment.html>

From vanessa.mchale at iohk.io  Fri Jul 13 13:19:26 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Fri, 13 Jul 2018 08:19:26 -0500
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
Message-ID: <616abe84-36d0-889f-4972-612685411cb8@iohk.io>

The idea that Haskell is in the same category as Forth or APL is
completely wrong and the idea that Haskell only has stack for tooling is
just plain wrong. Haskell already has libraries that are superior to
anything else available for certain use cases.

The idea that abstraction occurs only over functions is false. As of GHC
8.2.2, one can abstract over modules as well. Adding special syntax for
record accesses would be inadvisable when principled approaches such as
row polymorphism exist.

On 07/13/2018 02:38 AM, PY wrote:
> 13.07.2018 02:52, Brett Gilio wrote:
>> On 07/12/2018 06:46 AM, PY wrote:
>>  written in Websharper and in any Haskell framework. Haskell is beauty
>>> but I'm afraid its fate unfortunately will be the same as one of
>>> Common Lisp, NetBSD, etc - it's ground for ideas and experiments and
>>> has disputable design. Also it's more-more difficult to teach
>>> children to Haskell than to F#...
> https://jackfoxy.github.io/DependentTypes/
> https://github.com/caindy/DependentTypesProvider
> Discussion: https://news.ycombinator.com/item?id=15852517
>
> Also F# has F*  ;)
>
>> I wonder if this is simply a result of the marketing of the language,
>> itself, rather than the strength of the language. I agree, F# has a
>> lot of beauty, but there remain many things that Haskell has a leg up
>> on that F# lacks, like dependent types
> IMHO there are several reasons:
>
> 1. Haskell limits itself to lambda-only. Example, instead to add other
> abstractions and to become modern MULTI-paradigm languages, it keeps
> lambda, so record accessors leading to names collision will lead to
> adding of 1,2 extensions to the language instead to add standard
> syntax (dot, sharp, something similar). So, point #1 is limitation in
> abstraction: monads, transformers, anything - is function. It's not
> good. There were such languages already: Forth, Joy/Cat, APL/J/K...
> Most of them look dead. When you try to be elegant, your product
> (language) died. This is not my opinion, this is only my observation.
> People like diversity and variety: in food, in programming languages,
> in relations, anywhere :)
>
> 2. When language has killer app and killer framework, IMHO it has more
> chances. But if it has _killer ideas_ only... So, those ideas will be
> re-implemented in other languages and frameworks but with more simple
> and typical syntax :)  It's difficult to compete with product,
> framework, big library, but it's easy to compete with ideas. It's an
> observation too :-) You can find it in politics for example. Or in
> industry. To repeat big solution is more difficult, but we are
> neutrally to languages, language itself is not argument for me.
> Argument for me (I am usual developer) are killer
> apps/frameworks/libraries/ecosystem/etc. Currently Haskell has stack
> only - it's very good, but most languages has similar tools (not all
> have LTS analogue, but big frameworks are the same).
>
>
> _______________________________________________
> 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/20180713/ca67e1d4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180713/ca67e1d4/attachment.sig>

From massimo.zaniboni at gmail.com  Fri Jul 13 14:51:06 2018
From: massimo.zaniboni at gmail.com (Massimo Zaniboni)
Date: Fri, 13 Jul 2018 16:51:06 +0200
Subject: [Haskell-cafe] BlockedIndefinitelyOnMVar
Message-ID: <709d0f25-ba71-fa4e-6d88-1514752f493b@gmail.com>

Hi,

I have a code like this

```
producer :: Int -> MVar Int -> IO ()
producer c mvar
   = case c > 10 of
       True -> throwIO HighNumberException
       False -> do putMVar mvar (c + 1)
                   producer (c + 1) mvar

consumer :: MVar Int -> IO ()
consumer mvar = do
   _ <- takeMVar mvar
   consumer mvar

coordinator :: MVar Int -> IO ()
coordinator mvar = do
   withAsync (producer 0 mvar) $ \p ->
     withAsync (consumer mvar) $ \c -> do
       wait c
       wait p

main :: IO ()
main = do
   mvar <- newEmptyMVar
   withAsync (coordinator mvar) (wait)
   putStrLn "done"
```

The producer send the informative exception HighNumberException, but the 
coordinator job receives a generic BlockedIndefinitelyOnMVar, because 
the producer stop working.

How can I discard the generic exception, and re-throw/catch only 
HighNumberException?

In case the complete source code is on 
https://github.com/massimo-zaniboni/blocked-on-mvar

Thanks in any case,
Massimo

From massimo.zaniboni at gmail.com  Fri Jul 13 15:29:59 2018
From: massimo.zaniboni at gmail.com (Massimo Zaniboni)
Date: Fri, 13 Jul 2018 17:29:59 +0200
Subject: [Haskell-cafe] BlockedIndefinitelyOnMVar
In-Reply-To: <709d0f25-ba71-fa4e-6d88-1514752f493b@gmail.com>
References: <709d0f25-ba71-fa4e-6d88-1514752f493b@gmail.com>
Message-ID: <2113c72d-1693-283e-f43b-72253e7127d0@gmail.com>

Hi,

I were discussing the problem on #haskell-it , and they noted that the 
correct exception is thrown changing from

```
   wait c
   wait p
```

to

```
   wait p
   wait c
```

More importantly, this code

```
   () <$ (waitAny [c, p])
```

and this

```
   () <$ (waitAny [p, c])
```

works in the expected way. So it seems that ``waitAny`` is a lot more 
robust, and extensible to 2 or more threads.

I'm not interested to the final result of threads, so ``waitAny`` it is 
a good solution, but in the real code (not this example) I have many 
nested threads, so I need to create a unique ``waitAny`` on the main 
caller, that is not optimal, but probably viable.

So I'm still interested, if there are better solutions, not requring a 
`waitAny` with all launched threads.

Regards,
Massimo

Il 13/07/2018 16:51, Massimo Zaniboni ha scritto:
> Hi,
> 
> I have a code like this
> 
> ```
> producer :: Int -> MVar Int -> IO ()
> producer c mvar
>    = case c > 10 of
>        True -> throwIO HighNumberException
>        False -> do putMVar mvar (c + 1)
>                    producer (c + 1) mvar
> 
> consumer :: MVar Int -> IO ()
> consumer mvar = do
>    _ <- takeMVar mvar
>    consumer mvar
> 
> coordinator :: MVar Int -> IO ()
> coordinator mvar = do
>    withAsync (producer 0 mvar) $ \p ->
>      withAsync (consumer mvar) $ \c -> do
>        wait c
>        wait p
> 
> main :: IO ()
> main = do
>    mvar <- newEmptyMVar
>    withAsync (coordinator mvar) (wait)
>    putStrLn "done"
> ```
> 
> The producer send the informative exception HighNumberException, but the 
> coordinator job receives a generic BlockedIndefinitelyOnMVar, because 
> the producer stop working.
> 
> How can I discard the generic exception, and re-throw/catch only 
> HighNumberException?
> 
> In case the complete source code is on 
> https://github.com/massimo-zaniboni/blocked-on-mvar
> 
> Thanks in any case,
> Massimo

From jo at durchholz.org  Fri Jul 13 18:49:02 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 13 Jul 2018 20:49:02 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
Message-ID: <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>

Am 13.07.2018 um 09:38 schrieb PY:
> 1. Haskell limits itself to lambda-only. Example, instead to add other 
> abstractions and to become modern MULTI-paradigm languages,

"modern"?
That's not an interesting property.
"maintainable", "expressive" - THESE are interesting. Multi-paradigm can 
help, but if overdone can hinder it - the earliest multi-paradigm 
language I'm aware of was PL/I, and that was a royal mess I hear.

> So, point #1 is limitation in 
> abstraction: monads, transformers, anything - is function. It's not 
> good.

Actually limiting yourself to a single abstraciton tool can be good. 
This simplifies semantics and makes it easier to build stuff on top of it.

Not that I'm saying that this is necessarily the best thing.

> There were such languages already: Forth, Joy/Cat, APL/J/K... Most of
> them look dead.
Which proves nothing, because many multi-paradigm languages look dead, too.

> When you try to be elegant, your product (language) died.
Proven by Lisp... er, disproven.

> This is not my opinion, this is only my observation. People like 
> diversity and variety: in food, in programming languages, in relations, 
> anywhere :)

Not in programming languages.
Actually multi-paradigm is usually a bad idea. It needs to be done in an 
excellent fashion to create something even remotely usable, while a 
single-paradigm language is much easier to do well.
And in practice, bad language design has much nastier consequences than 
leaving out some desirable feature.

> 2. When language has killer app and killer framework, IMHO it has more 
> chances. But if it has _killer ideas_ only... So, those ideas will be 
> re-implemented in other languages and frameworks but with more simple 
> and typical syntax :)

"Typical" is in the eye of the beholder, so that's another non-argument.

> It's difficult to compete with product, 
> framework, big library, but it's easy to compete with ideas. It's an 
> observation too :-)

Sure, but Haskell has product, framework, big library.
What's missing is commitment by a big company, that's all. Imagine 
Google adopting Haskell, committing to building libraries and looking 
for Haskell programmers in the streets - all of a sudden, Haskell is 
going to be the talk of the day. (Replace "Google" with whatever 
big-name company with deep pockets: Facebook, MS, IBM, you name it.)

> language itself is not argument for me.

You are arguing an awful lot about missing language features 
("multi-paradigm") to credibly make that statement.

> Argument for me (I 
> am usual developer) are killer apps/frameworks/libraries/ecosystem/etc. 
> Currently Haskell has stack only - it's very good, but most languages 
> has similar tools (not all have LTS analogue, but big frameworks are the 
> same).

Yeah, a good library ecosystem is very important, and from the reports I 
see on this list it's not really good enough.
The other issue is that Haskell's extensions make it more difficult to 
have library code interoperate. Though that's a trade-off: The freedom 
to add language features vs. full interoperability. Java opted for the 
other opposite: 100% code interoperability at the cost of a really 
annoying language evolution process, and that gave it a huge library 
ecosystem.

But... I'm not going to make the Haskell developers' decisions. If they 
don't feel comfortable with reversing the whole culture and make 
interoperability trump everything else, then I'm not going to blame 
them. I'm not even going to predict anything about Haskell's future, 
because my glass orb is out for repairs and I cannot currently predict 
the future.

Regards,
Jo

From jo at durchholz.org  Fri Jul 13 19:07:42 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 13 Jul 2018 21:07:42 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <d2392c04-1e6b-f07d-9b85-137504e6ff62@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
 <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
 <d2392c04-1e6b-f07d-9b85-137504e6ff62@gmail.com>
Message-ID: <98791dc2-e369-a7ba-315a-9b37e149fa2a@durchholz.org>

Am 13.07.2018 um 09:54 schrieb PY:
> 13.07.2018 09:47, Joachim Durchholz wrote:
>> Am 13.07.2018 um 01:40 schrieb Tony Morris:
>>> On python, we are fixing it (WIP):
>>> https://github.com/qfpl/hpython
>>
>> Some poisonous aspects of Python are unfixable.
>> E.g. having declarations as program-visible update to a global state 
>> causes all kinds of unnecessary pain, such as having to deal with 
>> half-initialized peer modules during module initialization.
>>
> I never understand that point. Mostly Python programs have not global 
> state, only global constants.

Well, try doing work on SymPy then.
I did. And I know for a fact that your idea is completely wrong; Python 
has a lot of global state, first and foremost all its modules and the 
data that lives inside them.

> Also OOP has long been solved "global state" problem, for example,
> Smalltalk (similar idea you can find in Erlang): state is hidden
> behind some FSM which is represented as class (process in Erlang).
No amount of TLAs will solve the issues with mutable global state.

Actually the Digg story was having mutable global state, in the form of 
a default parameter. Now that's insiduous.

> You can not change state anywhere, you can only send message.
If the responses depend on the history of previous message sends, you 
have mutable state back, just by another name.

> FSM guards you from any errors. Even more, FSM-style is super safe and 
> robust: you can visualize its behavior, to develop it very quickly, to 
> debug it easy, final code usually does not contain errors even...

This all holds only for trivial FSMs.
Once the FSM holds more than a dozen states, these advantages evaporate.

> Even I can imagine read monad with big record inside with a lot of 
> fields, flags, etc and to get absolutely the same spaghetti code with 
> flags manipulation and testing in Haskell, but under monad ;)

"Real programmers can write FORTRAN code in any language."
Sure.
Except that it's not idiomatic.

> Interesting here is that there are a big enterprise products written in 
> Python and they are very useful: 
> https://www.codeinstitute.net/blog/7-popular-software-programs-written-in-python/ 

Sure. Except they do not use some features, such as lists in default 
parameters, or face the consequences (as the Digg story demonstrates).
Which means that this feature is conceptually broken. Except Python 
can't fix it by mandating that default parameters need to be read-only, 
which is impossible because Python has no hard-and-fast way to mark 
read-only objects as such. (Read-only means: ALL function calls must 
ALWAYS return the same results given equal arguments. With additional 
constraints on argument behaviour vs. constness, but that's a pretty big 
can of worm to define properly.)

Also, such companies use extra-lingual process to get the modularization 
under control. Such as conventions, patterns, style guidelines - and woe 
to the company where a programmer accidentally broke them.

Finally, that "but large software IS successfully written in unsuitable 
languages" argument never held water. Entire operating systems have been 
written in assembly language, and are still being written in C. Which is 
a horrible misdecision from a reliability perspective, but it's being 
done, and the inevitable security holes are being duct-taped to keep the 
infrastructure limping along.
Which the large companies are doing, too. They just make enough money to 
keep that infrastructure going. The same goes for Linux BTW, they have 
enough paid^Wsponsored engineers to solve all the problems they're having.

The Haskell community does not have the luxury of excess engineers that 
can hold all the ripped-up steel together with duct tape.

From vl81 at kent.ac.uk  Fri Jul 13 19:14:31 2018
From: vl81 at kent.ac.uk (Vilem-Benjamin Liepelt)
Date: Fri, 13 Jul 2018 20:14:31 +0100
Subject: [Haskell-cafe] What is your favourite Haskell "aha" 	moment?
Message-ID: <6B7E13E5-BAB9-4CD2-A763-C071E992C275@kent.ac.uk>

Dear Simon,

I was always impressed by Haskell, but my "aha" moment was when I realised how great it is as a scripting language. How cool is the fact that you can glue together a bunch of small programs and make a bigger program out of it without toil? Haskell helps you get mundane tasks done while being a pleasure to write (in relative terms)!

There are much better examples online—I love Gabriel Gonzalez' turtle library—but I find the following compelling enough, and anybody can understand more or less what is going on with some explanation:



#!/usr/bin/env stack
-- stack script --resolver lts-10.1 --install-ghc

{-# LANGUAGE TypeApplications #-}

import Data.Maybe (mapMaybe)
import Text.Read (readMaybe)

main :: IO ()
main =
  interact
  ( show @Double
  . sum
  . mapMaybe readMaybe
  . words
  )

-- Adapted from a script by Taylor Fausak: https://gist.github.com/tfausak/fcd11dfcec616622033dfb64eb2378e1



Good luck with the presentation!

Best,

Vilem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180713/0f661714/attachment.html>

From brettg at posteo.net  Fri Jul 13 19:17:48 2018
From: brettg at posteo.net (Brett Gilio)
Date: Fri, 13 Jul 2018 14:17:48 -0500
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <6B7E13E5-BAB9-4CD2-A763-C071E992C275@kent.ac.uk>
References: <6B7E13E5-BAB9-4CD2-A763-C071E992C275@kent.ac.uk>
Message-ID: <20fa2783-7655-36ed-5e4b-ec130c6e289b@posteo.net>

On 07/13/2018 02:14 PM, Vilem-Benjamin Liepelt wrote> I was always 
impressed by Haskell, but my "aha" moment was when I > realised how 
great it is as a *scripting language.*

Absolutely, this. Have you ever tried Xmonad, Vilem? It is such a great 
environment for using Haskell in a multitude of capacities, even as a 
scripting language.


-- 
Brett Gilio
brettg at posteo.net | bmg at member.fsf.org
https://www.parabola.nu/ | https://www.emacs.org/
Free Software -- Free Society!

From whosekiteneverfly at gmail.com  Sat Jul 14 06:32:05 2018
From: whosekiteneverfly at gmail.com (Yuji Yamamoto)
Date: Sat, 14 Jul 2018 15:32:05 +0900
Subject: [Haskell-cafe] Taking over unicode-show
Message-ID: <CA+6J5GHWzkcj9J2dZ13dKvQPSHoEzNtw0qXaP=ZM0hea4sj_Uw@mail.gmail.com>

Hello Haskellers,

I'm trying to take over the unicode-show
<http://hackage.haskell.org/package/unicode-show> package,
whose author Takayuki Muranushi died about a year ago [1].

We Japanese (and perhaps non-alphabet writers) are often
annoyed by the result of the show function, which converts various
characters
into non-human-readable strings.
The unicode-show package solves the problem, and I'm going to introduce
the package in an educational content I'm creating to help Japanese Haskell
newbies.

Thanks to the simple structure, there is nothing to maintain
(unfortunately except hard one).
It works even on GHC 8.4.

[1]: (In Japanese) http://www.asj.or.jp/tennet/archives/msg07622.html

-- 
山本悠滋
twitter: @igrep
GitHub: https://github.com/igrep
GitLab: https://gitlab.com/igrep
Facebook: http://www.facebook.com/igrep
Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180714/b14b4b34/attachment.html>

From aquagnu at gmail.com  Sat Jul 14 07:05:01 2018
From: aquagnu at gmail.com (Paul)
Date: Sat, 14 Jul 2018 10:05:01 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavourite Haskell "aha" moment?)
In-Reply-To: <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
Message-ID: <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>

I understand that my points are disputable, sure, example, multi-pardigm Oz – dead 😊 Any rule has exceptions. But my point was that people don’t like elegant and one-abstraction languages. It’s my observation. For me, Smalltalk was good language (mostly dead, except Pharo, which looks cool). Forth – high-level “stack-around-assembler”, mostly dead (Factor looks abandoned, only 8th looks super cool, but it’s not free). What else? Lisp? OK, there are SBCL, Clojure, Racket... But you don’t find even Clojure in languages trends usually. APL, J – super cool! Seems dead (I don’t know what happens with K). ML, SML? By the way, Haskell role was to kill SML community, sure it is sad to acknowledge it, but it’s 100% true...

Haskell try to be minimalistic and IMHO this can lead to death. Joachim, I’m not talking “it’s good/it’s bad”, “multiparadigm is good” or else... I don’t know what is right. It’s my observations only. Looks like it can happen.

If we will look to Haskell history then we see strange curve. I’ll try to describe it with humour, so, please, don;t take it seriously 😊 
- Let’s be pure lambda fanatics!
- Is it possible to create a big application?
- Is it possible to compile and optimize it?!
- Let’s try...
- Wow, it’s possible!!! (sure, it’s possible, Lisp did it long-long ago).
- Looks like puzzle, can be used to write a lot of articles (there were articles about combinators, Jay/Cat/Scheme, etc, now there are a lot of Haskell articles – big interesting in academia. But IMHO academia interest to language can kill it too: Clean, Strongtalk, etc)
- Stop! How to do I/O? Real programming?!!
- Ohh, if we will wrap it in lambda and defer it to top level (main::IO ()), it will have I/O type (wrapper is hidden in type)
- Let’s call it... Monad!!
- Wow, cool! Works! Anybody should use monads! Does not your language have monads? Then we fly to you! (everybody forgot that monads are workaround of Haskell limitation and are not needed in another languages. Also they lead to low-performance code)
- But how to compose them???!?!
- We will wrap/unwrap, wrap/unwrap.. Let’s call it... transformers!!! “Monad transformers” – sounds super cool. Your language does not have “lift” operation, right? Ugh...
- How to access records fields... How... That’s a question. ‘.’ - no! ‘#’ - no! Eureka! We will add several language extensions and voila!
- To be continued... 😊

I love Haskell but I think such curve is absolutely impossible in commercial language. With IT managers 😊 To solve problem in a way when solution leads to another problem which needs new solution again and reason is only to keep lambda-abstraction-only (OK, Vanessa, backpacks also 😉) Can you imagine that all cars will have red color? Or any food will be sweet? It’s not technical question, but psychological and linguistic. Why native languages are not so limited? They even borrow words and forms from another one 😊 

Haskell’s core team knows how better then me, and I respect a lot of Haskell users, most of them helped me A LOT (!!!). It’s not opinion even, because I don’t know what is a right way. Let’s call it observation and feeling of the future.

I feel: Haskell has 3 cases: 1) to die 2) to change itself 3) to fork to another language
How I see commercial successful Haskell-like language:
- No monads, no transformers
- There are dependent types, linear types
- There are other evaluation models/abstractions (not only lambda)
- Special syntax for records fields, etc
- Less operators noise, language extensions (but it’s very disputable)
- Solve problems with numerous from/to conversions (strings, etc)
- Solve problems with libraries

Last point needs explanation:
- There is a lot of libraries written to check some type concepts only, no any business value. Also there are a lot of libraries written by students while they are learning Haskell: mostly without any business value/abandoned
- There is situation when you have alternative libraries in one project due to dependencies (but should be one only, not both!)
- Strange dependencies: I have installed Agda even! Why???!

IMHO problems with libraries and lambda-only-abstraction lead to super slow compilation, big and complex compiler.
So, currently I see (again, it’s my observation only) 2 big “camps”:
1. Academia, which has own interests, for example, to keep Haskell minimalistic (one-only-abstraction). Trade-off only was to add language extensions but they fragmentizes the language
2. Practical programmers, which interests are different from 1st “camp”

Another my observation is: a lot of peoples tried Haskell and switched to another languages (C#, F#, etc) because they cannot use it for big enterprise projects (Haskell becomes hobby for small experiments or is dropped off).

Joachim, I’m absolutely agreed that a big company can solve a lot of these problems. But some of them have already own languages (you can compare measure units in Haskell and in F#, what looks better...).

When I said about killer app, I mean: devs like Ruby not due to syntax but RoR. The same Python: sure, Python syntax is very good, but without Zope, Django, TurboGears, SQLAlchemy, Twisted, Tornado, Cheetah, Jinja, etc – nobody will use Python. Sure, there are exceptions: Delphi, CBuilder, for example. But this is bad karma of Borland 😊 They had a lot of compilers (pascal, prolog, c/c++, etc), but... On the other hand after reincarnation we have C# 😊  Actually all these are only observations: nobody knows the future.


/Best regards, Paul

From: Joachim Durchholz
Sent: 13 июля 2018 г. 21:49
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)

Am 13.07.2018 um 09:38 schrieb PY:
> 1. Haskell limits itself to lambda-only. Example, instead to add other 
> abstractions and to become modern MULTI-paradigm languages,

"modern"?
That's not an interesting property.
"maintainable", "expressive" - THESE are interesting. Multi-paradigm can 
help, but if overdone can hinder it - the earliest multi-paradigm 
language I'm aware of was PL/I, and that was a royal mess I hear.

> So, point #1 is limitation in 
> abstraction: monads, transformers, anything - is function. It's not 
> good.

Actually limiting yourself to a single abstraciton tool can be good. 
This simplifies semantics and makes it easier to build stuff on top of it.

Not that I'm saying that this is necessarily the best thing.

> There were such languages already: Forth, Joy/Cat, APL/J/K... Most of
> them look dead.
Which proves nothing, because many multi-paradigm languages look dead, too.

> When you try to be elegant, your product (language) died.
Proven by Lisp... er, disproven.

> This is not my opinion, this is only my observation. People like 
> diversity and variety: in food, in programming languages, in relations, 
> anywhere :)

Not in programming languages.
Actually multi-paradigm is usually a bad idea. It needs to be done in an 
excellent fashion to create something even remotely usable, while a 
single-paradigm language is much easier to do well.
And in practice, bad language design has much nastier consequences than 
leaving out some desirable feature.

> 2. When language has killer app and killer framework, IMHO it has more 
> chances. But if it has _killer ideas_ only... So, those ideas will be 
> re-implemented in other languages and frameworks but with more simple 
> and typical syntax :)

"Typical" is in the eye of the beholder, so that's another non-argument.

> It's difficult to compete with product, 
> framework, big library, but it's easy to compete with ideas. It's an 
> observation too :-)

Sure, but Haskell has product, framework, big library.
What's missing is commitment by a big company, that's all. Imagine 
Google adopting Haskell, committing to building libraries and looking 
for Haskell programmers in the streets - all of a sudden, Haskell is 
going to be the talk of the day. (Replace "Google" with whatever 
big-name company with deep pockets: Facebook, MS, IBM, you name it.)

> language itself is not argument for me.

You are arguing an awful lot about missing language features 
("multi-paradigm") to credibly make that statement.

> Argument for me (I 
> am usual developer) are killer apps/frameworks/libraries/ecosystem/etc. 
> Currently Haskell has stack only - it's very good, but most languages 
> has similar tools (not all have LTS analogue, but big frameworks are the 
> same).

Yeah, a good library ecosystem is very important, and from the reports I 
see on this list it's not really good enough.
The other issue is that Haskell's extensions make it more difficult to 
have library code interoperate. Though that's a trade-off: The freedom 
to add language features vs. full interoperability. Java opted for the 
other opposite: 100% code interoperability at the cost of a really 
annoying language evolution process, and that gave it a huge library 
ecosystem.

But... I'm not going to make the Haskell developers' decisions. If they 
don't feel comfortable with reversing the whole culture and make 
interoperability trump everything else, then I'm not going to blame 
them. I'm not even going to predict anything about Haskell's future, 
because my glass orb is out for repairs and I cannot currently predict 
the future.

Regards,
Jo
_______________________________________________
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/20180714/c8887afd/attachment-0001.html>

From aquagnu at gmail.com  Sat Jul 14 07:17:43 2018
From: aquagnu at gmail.com (Paul)
Date: Sat, 14 Jul 2018 10:17:43 +0300
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <98791dc2-e369-a7ba-315a-9b37e149fa2a@durchholz.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
 <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
 <d2392c04-1e6b-f07d-9b85-137504e6ff62@gmail.com>
 <98791dc2-e369-a7ba-315a-9b37e149fa2a@durchholz.org>
Message-ID: <5b49a397.1c69fb81.8b33f.320d@mx.google.com>

I agreed with most of your the arguments.

Yes, Python has serious problem with modules locking mechanism in multi-process apps. And GIL. But it’s trade-off. And also not all Python implementations have GIL.

> "Real programmers can write FORTRAN code in any language."
The same with my example of read monad usage 😉 No problem to avoid manipulation of global state in a way which leads to spaghetti-code.

> Once the FSM holds more than a dozen states, these advantages evaporate.
This is point only where I can not agree. I used FSM with hundreds states/transitions. It was automatically generated, I only check them. Also I know that in car automatics FSM are widely used (BMW, Mercedes, Audi). Also it’s using in software for space industry widely. My IMHO is: FSM is most reliable way to do soft without bugs. Also it’s easy to verify them (for example, with transitions’ assertions)

From: Joachim Durchholz
Sent: 13 июля 2018 г. 22:08
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?

Am 13.07.2018 um 09:54 schrieb PY:
> 13.07.2018 09:47, Joachim Durchholz wrote:
>> Am 13.07.2018 um 01:40 schrieb Tony Morris:
>>> On python, we are fixing it (WIP):
>>> https://github.com/qfpl/hpython
>>
>> Some poisonous aspects of Python are unfixable.
>> E.g. having declarations as program-visible update to a global state 
>> causes all kinds of unnecessary pain, such as having to deal with 
>> half-initialized peer modules during module initialization.
>>
> I never understand that point. Mostly Python programs have not global 
> state, only global constants.

Well, try doing work on SymPy then.
I did. And I know for a fact that your idea is completely wrong; Python 
has a lot of global state, first and foremost all its modules and the 
data that lives inside them.

> Also OOP has long been solved "global state" problem, for example,
> Smalltalk (similar idea you can find in Erlang): state is hidden
> behind some FSM which is represented as class (process in Erlang).
No amount of TLAs will solve the issues with mutable global state.

Actually the Digg story was having mutable global state, in the form of 
a default parameter. Now that's insiduous.

> You can not change state anywhere, you can only send message.
If the responses depend on the history of previous message sends, you 
have mutable state back, just by another name.

> FSM guards you from any errors. Even more, FSM-style is super safe and 
> robust: you can visualize its behavior, to develop it very quickly, to 
> debug it easy, final code usually does not contain errors even...

This all holds only for trivial FSMs.
Once the FSM holds more than a dozen states, these advantages evaporate.

> Even I can imagine read monad with big record inside with a lot of 
> fields, flags, etc and to get absolutely the same spaghetti code with 
> flags manipulation and testing in Haskell, but under monad ;)

"Real programmers can write FORTRAN code in any language."
Sure.
Except that it's not idiomatic.

> Interesting here is that there are a big enterprise products written in 
> Python and they are very useful: 
> https://www.codeinstitute.net/blog/7-popular-software-programs-written-in-python/ 

Sure. Except they do not use some features, such as lists in default 
parameters, or face the consequences (as the Digg story demonstrates).
Which means that this feature is conceptually broken. Except Python 
can't fix it by mandating that default parameters need to be read-only, 
which is impossible because Python has no hard-and-fast way to mark 
read-only objects as such. (Read-only means: ALL function calls must 
ALWAYS return the same results given equal arguments. With additional 
constraints on argument behaviour vs. constness, but that's a pretty big 
can of worm to define properly.)

Also, such companies use extra-lingual process to get the modularization 
under control. Such as conventions, patterns, style guidelines - and woe 
to the company where a programmer accidentally broke them.

Finally, that "but large software IS successfully written in unsuitable 
languages" argument never held water. Entire operating systems have been 
written in assembly language, and are still being written in C. Which is 
a horrible misdecision from a reliability perspective, but it's being 
done, and the inevitable security holes are being duct-taped to keep the 
infrastructure limping along.
Which the large companies are doing, too. They just make enough money to 
keep that infrastructure going. The same goes for Linux BTW, they have 
enough paid^Wsponsored engineers to solve all the problems they're having.

The Haskell community does not have the luxury of excess engineers that 
can hold all the ripped-up steel together with duct tape.
_______________________________________________
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/20180714/5dd8ee74/attachment.html>

From theedge456 at free.fr  Sat Jul 14 09:00:55 2018
From: theedge456 at free.fr (Fabien R)
Date: Sat, 14 Jul 2018 11:00:55 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <1c191976-c686-03db-5888-865feef26b2b@free.fr>

Definitely after reading the book "category theory for programmers" by Bartosz Milewski.
The next step is to get a link from algorithms to category theory to get:
 algorithms -> category theory -> haskell

--
Fabien

From takenobu.hs at gmail.com  Sat Jul 14 10:05:25 2018
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Sat, 14 Jul 2018 19:05:25 +0900
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAPB_Nvz3SEhJgjMWdgK8r=FOS4RLhWrv+fW1MGsTjgR8Ggm2KQ@mail.gmail.com>

Hi simon,

I feel a lot of aha in Haskell.
However, the most basic characterise I think are the following.

  * Algebraic data type (*Extremely wonderful*)
  * Pattern matches
  * Higher-order function
  * Partial application
  * Polymorphic type
  * Recursion and Lazy pattern


I show its features in the code below.

Simple code example 1:

    ```Haskell
    -- Algebraic data type
    data DNA = A | C | G | T
               deriving Show

    -- Using algebraic data type with list
    dna1 :: [DNA]
    dna1 = [A,A,T,C,C,G,C,T,A,G]

    -- Pattern matches
    abbrev :: DNA -> String
    abbrev A = "adenine"
    abbrev C = "cytosine"
    abbrev G = "guanine"
    abbrev T = "thymine"

    -- Higher-order function and Partial application
    abbrevDNAs = map abbrev

    -- Interactive example
    {-
    ghci> abbrevDNAs [A,A,C,G,A,T]
    ["adenine","adenine","cytosine","guanine","adenine","thymine"]
    -}
    ```


Simple code example 2:

    ```Haskell
    -- Algebraic data type
    data RNA = A | C | G | U
               deriving Show

    data Amino = Ala | Arg | Asn | Asp | Cys | Gln | Glu |
                 Gly | His | Ile | Leu | Lys | Met | Phe |
                 Pro | Ser | Thr | Trp | Tyr | Val | Error
                 deriving Show

    -- Pattern matches
    rna2amino :: [RNA] -> Amino
    rna2amino [A,A,A] = Lys
    rna2amino [A,A,G] = Lys
    rna2amino [G,A,A] = Glu
    rna2amino [A,U,G] = Met
    rna2amino [C,A,U] = His
    rna2amino _       = Error

    -- Higher-order function
    convert :: [RNA] -> [Amino]
    convert xss = map rna2amino $ splitN 3 xss

    -- Polymorphic type, Recursion and Lazy pattern
    splitN :: Int -> [a] -> [[a]]
    splitN _ [] = []
    splitN n xs = let (as,bs) = splitAt n xs
                  in as : splitN n bs

    -- Interactive example
    {-
    ghci> convert [A,A,A,G,A,A,A,U,G,C,A,U]
    [Lys,Glu,Met,His]
    -}
    ```

Of course, I am not familiar with genom :)

Regards,
Takenobu



2018-07-11 21:10 GMT+09:00 Simon Peyton Jones via Haskell-Cafe <
haskell-cafe at haskell.org>:

> Friends
>
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger
> Institute <https://www.sanger.ac.uk/> about Haskell.   They do lots of
> programming, but they aren’t computer scientists.
>
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the
> main question in their minds: *why should I even care about Haskell*?
> I’m too much of a biased witness.
>
> So I thought I’d ask you for help.  War stories perhaps – how using
> Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d
> love to illustrate with copious examples of beautiful code.
>
>    - Can you identify a few lines of Haskell that best characterise what
>    you think makes Haskell distinctively worth caring about?   Something that
>    gave you an “aha” moment, or that feeling of joy when you truly make sense
>    of something for the first time.
>
> The challenge is, of course, that this audience will know no Haskell, so
> muttering about Cartesian Closed Categories isn’t going to do it for them.
> I need examples that I can present in 5 minutes, without needing a long
> setup.
>
> To take a very basic example, consider Quicksort using list
> comprehensions, compared with its equivalent in C.  It’s so short, so
> obviously right, whereas doing the right thing with in-place update in C
> notoriously prone to fencepost errors etc.  But it also makes much less
> good use of memory, and is likely to run slower.  I think I can do that in
> 5 minutes.
>
> Another thing that I think comes over easily is the ability to abstract:
> generalising sum and product to fold by abstracting out a functional
> argument; generalising at the type level by polymorphism, including
> polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
>
> But you will have more and better ideas, and (crucially) ideas that are
> more credibly grounded in the day to day reality of writing programs that
> get work done.
>
> Pointers to your favourite blog posts would be another avenue.  (I love
> the Haskell Weekly News.)
>
> Finally, I know that some of you use Haskell specifically for genomics
> work, and maybe some of your insights would be particularly relevant for
> the Sanger audience.
>
> Thank you!  Perhaps your responses on this thread (if any) may be helpful
> to more than just me.
>
> Simon
>
> _______________________________________________
> 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/20180714/ebe6f0bb/attachment.html>

From monkleyon at gmail.com  Sat Jul 14 11:33:31 2018
From: monkleyon at gmail.com (MarLinn)
Date: Sat, 14 Jul 2018 13:33:31 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <6B7E13E5-BAB9-4CD2-A763-C071E992C275@kent.ac.uk>
References: <6B7E13E5-BAB9-4CD2-A763-C071E992C275@kent.ac.uk>
Message-ID: <c7a00886-f32b-c4ae-617d-450394278b58@gmail.com>

Warning: I'll be overly harsh in this mail because I assume some people 
that are new to Haskell might browse this thread now and in the future. 
I don't mean my comments to be considered personal. On the contrary, I 
think some of us can learn for their own teaching endeavours.

> #!/usr/bin/env stack
> -- stack script --resolver lts-10.1 --install-ghc

Imagine a "newbie" running this script just to see what it does. After 
15 minutes they'll be disappointed why your small demo took so long to 
build. Only /then/ do they realize that, what is it today, about half a 
gigabyte maybe, of their monthly "high speed" bandwidth and of their 
precious space on the cheap but decade-old hard drive is gone.

Of course you need all that data because there's a ghc in that data, but 
it should say so on the tin. So please never send a script with this 
line to a "newbie" without big warnings so they can make an informed 
decision. Maybe they would want to install ghc at their uni to save on 
that precious bandwidth at home or something similar.

In fact don't even send scripts with this line to seasoned haskellers. 
If your code is compatible with the ghc 8.2.1 on my system, why should 
your script assume I want stack to install 8.2.2 right now?

Of course this behaviour is ingrained in the DNA of stack – after all it 
values convenience for the professional user more than convenience for 
the unprivileged newcomer – but AFAIU it /can/ be persuaded to be more 
inclusive. So especially here, we should maybe try to do that.

>    interact
>    ( show @Double
>    . sum
>    . mapMaybe readMaybe
>    . words
>    )

Also, while I do like the scripting possibilities, interact is possibly 
the worst way to introduce a newcomer to it because you can't really 
test it in ghci. Apart from all the other shortcomings it has. It is 
nice in that it hides IO, but…

Again, not meant as an attack, but since we're talking about giving 
newcomers a good experience, I thought these two points important.

Cheers,
MarLinn

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

From alexey.raga at gmail.com  Sat Jul 14 12:30:13 2018
From: alexey.raga at gmail.com (Alexey Raga)
Date: Sat, 14 Jul 2018 22:30:13 +1000
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavourite Haskell "aha" moment?)
In-Reply-To: <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
Message-ID: <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>

Hi Paul,

As someone who uses Haskell commercially for a couple of years now, I think
I have something to add.

A small disclaimer: none of the members of our team has an academic
background. We all have different backgrounds: C#, Java, Ruby, Python, C,
even Perl if I am not mistaken. Yet we ended up with FP first, and then
with Haskell.

We have switched to Haskell from Scala, which _is_ a multi-paradigm
language borrowing bits and pieces from other languages/paradigms and
mixing them together. It is an enormously hard work to do it and for that,
I very much respect Odersky and the core Scala team. But at the same time,
Scala is a very complicated language where pretty much nothing feels
consistent or conceptually finished. Too many things in Scala can get you
only that far before they become unprincipled. And then it justs stops and
you have to find a workaround.
This isn't a problem with Scala particularly though, it is exactly a
problem of borrowing bits of foreign concepts: they simply don't fuse into
one cohesive system.
As a result, the language becomes overly complicated and less useful.
In his talk (https://www.youtube.com/watch?v=v8IQ-X2HkGE) John De Goes
explains exactly the same problem, talking about Scala, but the reasoning
is applicable generally. One of the conclusions is very interesting: the
mix, the middle ground between different paradigms is often imagined as a
"paradise" that attracts peoples from all the sides. However, in reality,
it is the place where no one is happy, no one is really interested in it,
no one wants it. Watch the talk, it is fun.
Also: https://twitter.com/chris__martin/status/1016462268073209856

I bring this in because you name lots of languages, but when you speak
about "borrowing" you don't name any. So I did. We lived throuh such a
life, we felt it. Thank you very much, no desire to repeat it again.

I personally went through F# in my career (and I am still coming back to
F#, and I am writing F# right now).  With it, I have not exactly the same,
but similar experience.

Your joke about how Haskell has been made misses one point: it was
initially designed as a lazy language (at least as far as I know). Many
features that Haskell has now are there because of laziness: if you want to
be lazy, then you have to be pure, you have to sequence your effects, etc.

"Let's defer lambda, name it IO and let's call it Monad" -  this bit isn't
even funny. Monad isn't IO. IO happens to be a monad (as many things do,
List as an example), but monad isn't IO and has nothing to do with IO. A
horse is classified as Mammal, but Mammal doesn't mean horse _at all_.

Now back to your items:


   - No monads, no transformers

In a context of a lazy language, you need to sequence your effects
(including side effects), that's the first point. The second is that
instead of disappearing from Haskell, monads (and other concepts) are
making their way to other languages. Scala has them, F# has them, even C#
has them (however indirectly). Try to take away List Monad from C#
developers and they'll kill you ;)
Watch "What Haskell taught us when we were not looking" by Eric Torreborre (
https://www.youtube.com/watch?v=aNL3137C74c)
Also: https://twitter.com/Horusiath/status/1016593663626014720?s=09 :)


   - There are dependent types, linear types

Agree here.  And they are coming to Haskell, naturally and without breaking
it dramatically into another language.


   - There are other evaluation models/abstractions (not only lambda)

I think I made my point above.


   - Special syntax for records fields, etc

That would be nice. Although even coming from C# background, I don't
entirely understand why it is _that much_ important for some people. For me
personally, it is just a bit of annoyance. I have never felt like "Oh, I
could achieve so much more if only I had records!" :) Lenses and generic
lenses help, so be it. But I don't think that anything prevents Haskell
from having it, and I don't think that Haskell as a language needs a
dramatic change as you depict to make it happen. Just a feature.


   - Less operators noise, language extensions (but it’s very disputable)

I don't agree that operators are noise. You certainly can write Haskell
almost without operators if you wish.
As for extensions, I think that many more should be just switched on by
default.


   - Solve problems with numerous from/to conversions (strings, etc)

You mean that conversion should happen implicitly? Thank you, but no, thank
you. This is a source of problems in many languages, and it is such a great
thing that Haskell doesn't coerce types implicitly.


   - Solve problems with libraries

Surely, more libraries are better. I don't understand this "no business
value" statement. Value for which business? What does it mean "check types,
no business value"?
I also strongly disagree that there should only be one library for one
thing. Do you know many ways are there to, say, parse XML? Or Json? How
many different tradeoffs can be made while implementing a
parser/serialiser? Some are valuable in one "business" but totally not
acceptable in another, and vice versa. In our company, we have a set of
requirements such that _none_ of the tradeoffs made by the existing XML
parsers would satisfy them. So we had to write our own. Deliver business
value, yeah. And you say that there should only be one XML parser for a
given language? Absurd.
I think Haskell has only one problem with libraries: we need more of them.
And then it falls into a famous joke: "The problem with Open Source
Software is YOU because YOU are not contributing" :) Meaning that if we
want more good libs then we should write more good libs :)

Regards,
Alexey.



On Sat, Jul 14, 2018 at 5:05 PM Paul <aquagnu at gmail.com> wrote:

> I understand that my points are disputable, sure, example, multi-pardigm
> Oz – dead 😊 Any rule has exceptions. But my point was that people don’t
> like elegant and one-abstraction languages. It’s my observation. For me,
> Smalltalk was good language (mostly dead, except Pharo, which looks cool).
> Forth – high-level “stack-around-assembler”, mostly dead (Factor looks
> abandoned, only 8th looks super cool, but it’s not free). What else?
> Lisp? OK, there are SBCL, Clojure, Racket... But you don’t find even
> Clojure in languages trends usually. APL, J – super cool! Seems dead (I
> don’t know what happens with K). ML, SML? By the way, Haskell role was to
> kill SML community, sure it is sad to acknowledge it, but it’s 100% true...
>
>
>
> Haskell try to be minimalistic and IMHO this can lead to death. Joachim,
> I’m not talking “it’s good/it’s bad”, “multiparadigm is good” or else... I
> don’t know what is right. It’s my observations only. Looks like it can
> happen.
>
>
>
> If we will look to Haskell history then we see strange curve. I’ll try to
> describe it with humour, so, please, don;t take it seriously 😊
>
>    - Let’s be pure lambda fanatics!
>    - Is it possible to create a big application?
>    - Is it possible to compile and optimize it?!
>    - Let’s try...
>    - Wow, it’s possible!!! (sure, it’s possible, Lisp did it long-long
>    ago).
>    - Looks like puzzle, can be used to write a lot of articles (there
>    were articles about combinators, Jay/Cat/Scheme, etc, now there are a lot
>    of Haskell articles – big interesting in academia. But IMHO academia
>    interest to language can kill it too: Clean, Strongtalk, etc)
>    - Stop! How to do I/O? Real programming?!!
>    - Ohh, if we will wrap it in lambda and defer it to top level
>    (main::IO ()), it will have I/O type (wrapper is hidden in type)
>    - Let’s call it... Monad!!
>    - Wow, cool! Works! Anybody should use monads! Does not your language
>    have monads? Then we fly to you! (everybody forgot that monads are
>    workaround of Haskell limitation and are not needed in another languages.
>    Also they lead to low-performance code)
>    - But how to compose them???!?!
>    - We will wrap/unwrap, wrap/unwrap.. Let’s call it... transformers!!!
>    “Monad transformers” – sounds super cool. Your language does not have
>    “lift” operation, right? Ugh...
>    - How to access records fields... How... That’s a question. ‘.’ - no!
>    ‘#’ - no! Eureka! We will add several language extensions and voila!
>    - To be continued... 😊
>
>
>
> I love Haskell but I think such curve is absolutely impossible in
> commercial language. With IT managers 😊 To solve problem in a way when
> solution leads to another problem which needs new solution again and reason
> is only to keep lambda-abstraction-only (OK, Vanessa, backpacks also 😉)
> Can you imagine that all cars will have red color? Or any food will be
> sweet? It’s not technical question, but psychological and linguistic. Why
> native languages are not so limited? They even borrow words and forms from
> another one 😊
>
>
>
> Haskell’s core team knows how better then me, and I respect a lot of
> Haskell users, most of them *helped me A LOT* (!!!). It’s not opinion
> even, because I don’t know what is a right way. Let’s call it observation
> and feeling of the future.
>
>
>
> I feel: Haskell has 3 cases: 1) to die 2) to change itself 3) to fork to
> another language
>
> How I see commercial successful Haskell-like language:
>
>    - No monads, no transformers
>    - There are dependent types, linear types
>    - There are other evaluation models/abstractions (not only lambda)
>    - Special syntax for records fields, etc
>    - Less operators noise, language extensions (but it’s very disputable)
>    - Solve problems with numerous from/to conversions (strings, etc)
>    - Solve problems with libraries
>
>
>
> Last point needs explanation:
>
>    - There is a lot of libraries written to check some type concepts
>    only, no any business value. Also there are a lot of libraries written by
>    students while they are learning Haskell: mostly without any business
>    value/abandoned
>    - There is situation when you have alternative libraries in one
>    project due to dependencies (but should be one only, not both!)
>    - Strange dependencies: I have installed Agda even! Why???!
>
>
>
> IMHO problems with libraries and lambda-only-abstraction lead to super
> slow compilation, big and complex compiler.
>
> So, currently I see (again, it’s my observation only) 2 big “camps”:
>
>    1. Academia, which has own interests, for example, to keep Haskell
>    minimalistic (one-only-abstraction). Trade-off only was to add language
>    extensions but they fragmentizes the language
>    2. Practical programmers, which interests are different from 1st “camp”
>
>
>
> Another my observation is: a lot of peoples tried Haskell and switched to
> another languages (C#, F#, etc) because they cannot use it for big
> enterprise projects (Haskell becomes hobby for small experiments or is
> dropped off).
>
>
>
> Joachim, I’m absolutely agreed that a big company can solve a lot of these
> problems. But some of them have already own languages (you can compare
> measure units in Haskell and in F#, what looks better...).
>
>
>
> When I said about killer app, I mean: devs like Ruby not due to syntax but
> RoR. The same Python: sure, Python syntax is very good, but without Zope,
> Django, TurboGears, SQLAlchemy, Twisted, Tornado, Cheetah, Jinja, etc –
> nobody will use Python. Sure, there are exceptions: Delphi, CBuilder, for
> example. But this is bad karma of Borland 😊 They had a lot of compilers
> (pascal, prolog, c/c++, etc), but... On the other hand after reincarnation
> we have C# 😊  Actually all these are only observations: nobody knows the
> future.
>
>
>
>
>
> /Best regards, Paul
>
>
>
> *From: *Joachim Durchholz <jo at durchholz.org>
> *Sent: *13 июля 2018 г. 21:49
> *To: *haskell-cafe at haskell.org
> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
> yourfavourite Haskell "aha" moment?)
>
>
>
> Am 13.07.2018 um 09:38 schrieb PY:
>
> > 1. Haskell limits itself to lambda-only. Example, instead to add other
>
> > abstractions and to become modern MULTI-paradigm languages,
>
>
>
> "modern"?
>
> That's not an interesting property.
>
> "maintainable", "expressive" - THESE are interesting. Multi-paradigm can
>
> help, but if overdone can hinder it - the earliest multi-paradigm
>
> language I'm aware of was PL/I, and that was a royal mess I hear.
>
>
>
> > So, point #1 is limitation in
>
> > abstraction: monads, transformers, anything - is function. It's not
>
> > good.
>
>
>
> Actually limiting yourself to a single abstraciton tool can be good.
>
> This simplifies semantics and makes it easier to build stuff on top of it.
>
>
>
> Not that I'm saying that this is necessarily the best thing.
>
>
>
> > There were such languages already: Forth, Joy/Cat, APL/J/K... Most of
>
> > them look dead.
>
> Which proves nothing, because many multi-paradigm languages look dead, too.
>
>
>
> > When you try to be elegant, your product (language) died.
>
> Proven by Lisp... er, disproven.
>
>
>
> > This is not my opinion, this is only my observation. People like
>
> > diversity and variety: in food, in programming languages, in relations,
>
> > anywhere :)
>
>
>
> Not in programming languages.
>
> Actually multi-paradigm is usually a bad idea. It needs to be done in an
>
> excellent fashion to create something even remotely usable, while a
>
> single-paradigm language is much easier to do well.
>
> And in practice, bad language design has much nastier consequences than
>
> leaving out some desirable feature.
>
>
>
> > 2. When language has killer app and killer framework, IMHO it has more
>
> > chances. But if it has _killer ideas_ only... So, those ideas will be
>
> > re-implemented in other languages and frameworks but with more simple
>
> > and typical syntax :)
>
>
>
> "Typical" is in the eye of the beholder, so that's another non-argument.
>
>
>
> > It's difficult to compete with product,
>
> > framework, big library, but it's easy to compete with ideas. It's an
>
> > observation too :-)
>
>
>
> Sure, but Haskell has product, framework, big library.
>
> What's missing is commitment by a big company, that's all. Imagine
>
> Google adopting Haskell, committing to building libraries and looking
>
> for Haskell programmers in the streets - all of a sudden, Haskell is
>
> going to be the talk of the day. (Replace "Google" with whatever
>
> big-name company with deep pockets: Facebook, MS, IBM, you name it.)
>
>
>
> > language itself is not argument for me.
>
>
>
> You are arguing an awful lot about missing language features
>
> ("multi-paradigm") to credibly make that statement.
>
>
>
> > Argument for me (I
>
> > am usual developer) are killer apps/frameworks/libraries/ecosystem/etc.
>
> > Currently Haskell has stack only - it's very good, but most languages
>
> > has similar tools (not all have LTS analogue, but big frameworks are the
>
> > same).
>
>
>
> Yeah, a good library ecosystem is very important, and from the reports I
>
> see on this list it's not really good enough.
>
> The other issue is that Haskell's extensions make it more difficult to
>
> have library code interoperate. Though that's a trade-off: The freedom
>
> to add language features vs. full interoperability. Java opted for the
>
> other opposite: 100% code interoperability at the cost of a really
>
> annoying language evolution process, and that gave it a huge library
>
> ecosystem.
>
>
>
> But... I'm not going to make the Haskell developers' decisions. If they
>
> don't feel comfortable with reversing the whole culture and make
>
> interoperability trump everything else, then I'm not going to blame
>
> them. I'm not even going to predict anything about Haskell's future,
>
> because my glass orb is out for repairs and I cannot currently predict
>
> the future.
>
>
>
> Regards,
>
> Jo
>
> _______________________________________________
>
> 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/20180714/9344f086/attachment.html>

From aquagnu at gmail.com  Sat Jul 14 15:28:24 2018
From: aquagnu at gmail.com (Paul)
Date: Sat, 14 Jul 2018 18:28:24 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavouriteHaskell "aha" moment?)
In-Reply-To: <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
Message-ID: <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>

Hello Alex!

> A small disclaimer: none of the members of our team has an academic background. We all have different backgrounds: C#, Java, Ruby, Python, C, even Perl if I am not mistaken. Yet we ended up with FP first, and then with Haskell.
> We have switched to Haskell from Scala, which _is_ a multi-paradigm language borrowing bits and pieces from other languages/paradigms and mixing them together. It is an enormously hard work to do it and for that, I very much respect 

Oh, my 1st question will be: did you try Eta, Frege? May be I’m wrong but Eta should support Haskell libraries as well as Java ones? They allow you to use libraries from the both world...

> As a result, the language becomes overly complicated and less useful.

Yes, this is another side. You know, anything has several sides: good and bad...

> Your joke about how Haskell has been made misses one point: it was initially designed as a lazy language (at least as far as I know). Many features that Haskell has now are there because of laziness: if you want to be lazy, then you have to be pure, you have to sequence your effects, etc.

True. Laziness makes Haskell unique. I think Haskell makes laziness so popular in modern languages although it was known long ago (as data in “infinite streams”, etc). I think, Miranda was lazy, so Haskell is lazy too 😊 And IMHO there was some lazy dialect of ML (may be, I’m not right).

> "Let's defer lambda, name it IO and let's call it Monad" -  this bit isn't even funny. Monad isn't IO. IO happens to be a monad (as many things do, List as an example), but monad isn't IO and has nothing to do with IO. A horse is classified as Mammal, but Mammal doesn't mean horse _at all_.

Sure. I mean, the need of side-effects (and firstly I/O) led to the monads.

> In a context of a lazy language, you need to sequence your effects (including side effects), that's the first point. The second is that instead of disappearing from Haskell, monads (and other concepts) are making their way to other languages. Scala has them, F# has them, even C# has them (however indirectly). Try to take away List Monad from C# developers and they'll kill you ;)

Better IMHO to have less infrastructure code. Better is to hide all “machinery” in compiler.

My point was that monads are workaround of Haskell problem, this was historically reason of their appearance. And if I have not such limitation in my language I don’t need any monads. What are the monad benefits in ML, for example? They are using in F#, but 1) comp. expressions are not monads but step forward, “monads++” and 2) they play different role in F#: simplifying of the code. And you can avoid them in all languages except Haskell. For example, Prolog can be “pure” and to do I/O without monads, also Clean can as well as F#. Monads have pros, sure, but they are not composable and workaround leads to another workaround – transformers. I’m not unique in my opinion: https://www.youtube.com/watch?v=rvRD_LRaiRs All of this looks like overengineering due to mentioned limitation. No such one in ML, F#. D has keyword “pure”, and didn’t introduce monads. Performance is very important feature of the language, that limitation is the reason #1 why Haskell has bad and unpredictable performance. “do”-block is not the same as “flat” block of C# statements and its performance is not the same. I can achieve Maybe effect with nullable+exceptions or ?-family operators, List with permutations/LINQ, guard with if+break/continue and to do it without sacrificing performance.. ListT/conduits – are just generators/enumerators. Benefit of monads IMHO is small, they are workaround of Haskell problem and are not needed in other languages. Sure, there are monads in Ocaml, Javascript, Python (as experimental libraries), but the reason is hype. Nobody will remember them after 5-10 years... 

Actually this is very-very subjective IMHHHHO 😊

> Lenses and generic lenses help, so be it. But I don't think that anything prevents Haskell from having it, and I don't think that Haskell as a language needs a dramatic change as you depict to make it happen. Just a feature.

When I have legacy code, there are a lot of types which fields are not starting with “_” prefix, so I need to create lenses explicitly... “Infrastructure” code. What is the business value of such code: nothing. For non-Haskell programmer it looks like you try to solve non-existing problem 😊  (very-very provocative point: all Haskell solutions looks very overengineering. The reason is: lambda-abstraction-only. When you try to build something big from little pieces then the process will be very overengineering. Imagine that the pyramids are built of small bricks).

> I don't agree that operators are noise. You certainly can write Haskell almost without operators if you wish.

Here I’m agree with D. Knuth ideas of literature programming: if code can not be easy read and understand on the hard-copy then used language is not fine. Haskell code needs help from IDE, types hints, etc. And I often meet a case when somebody does not understand what monads are in “do” blocks. Also there are a lot of operators in different libraries and no way to know what some operator means (different libraries, even different versions have own set of operators). 

> As for extensions, I think that many more should be just switched on by default.

+1

> You mean that conversion should happen implicitly? Thank you, but no, thank you. This is a source of problems in many languages, and it is such a great thing that Haskell doesn't coerce types implicitly. 

No... Actually, I have not idea what is better. Currently there are a lot of conversions. Some libraries functions expect String, another - Text, also ByteString, lazy/strict, the same with the numbers (word/int/integer). So, conversions happen often.

> I don't understand this "no business value" statement. Value for which business? What does it mean "check types, no business value"? 

There are libraries which nothing do in run-time. Only types playing. Only abstractions over types. And somebody says: oh man, see how many libraries has Haskell. But you can compare libraries of Haskell, Java, C#, Javascript, Perl, Python 😊 All libraries of Java, Python... have business value. Real-world functionality. Not abstract play with types. But more important point is a case with installed Agda 😊 or alternative libraries which does the same/similar things. The reason is important: Haskell moves a lot of functionality to libraries which is not good design IMHO. This is the root of the problem. Better is to have one good solid library bundled with GHC itself (“batteries included”) and only specific things will live in libraries and frameworks. Monads and monads transformers are central thing in Haskell. They a located in libraries. There is standard parser combinators in GHC itself, but you will have in the same project another one (or more than 1!). Etc, etc...

Also installed GHC... Why is it so big!? IMHO it’s time to clear ecosystem, to reduce it to “batteries” 😊

> And then it falls into a famous joke: "The problem with Open Source Software is YOU because YOU are not contributing" :) Meaning that if we want more good libs then we should write more good libs :)

Absolutely true 😊

On Sat, Jul 14, 2018 at 5:05 PM Paul <aquagnu at gmail.com> wrote:
I understand that my points are disputable, sure, example, multi-pardigm Oz – dead 😊 Any rule has exceptions. But my point was that people don’t like elegant and one-abstraction languages. It’s my observation. For me, Smalltalk was good language (mostly dead, except Pharo, which looks cool). Forth – high-level “stack-around-assembler”, mostly dead (Factor looks abandoned, only 8th looks super cool, but it’s not free). What else? Lisp? OK, there are SBCL, Clojure, Racket... But you don’t find even Clojure in languages trends usually. APL, J – super cool! Seems dead (I don’t know what happens with K). ML, SML? By the way, Haskell role was to kill SML community, sure it is sad to acknowledge it, but it’s 100% true...
 
Haskell try to be minimalistic and IMHO this can lead to death. Joachim, I’m not talking “it’s good/it’s bad”, “multiparadigm is good” or else... I don’t know what is right. It’s my observations only. Looks like it can happen.
 
If we will look to Haskell history then we see strange curve. I’ll try to describe it with humour, so, please, don;t take it seriously 😊 
• Let’s be pure lambda fanatics!
• Is it possible to create a big application?
• Is it possible to compile and optimize it?!
• Let’s try...
• Wow, it’s possible!!! (sure, it’s possible, Lisp did it long-long ago).
• Looks like puzzle, can be used to write a lot of articles (there were articles about combinators, Jay/Cat/Scheme, etc, now there are a lot of Haskell articles – big interesting in academia. But IMHO academia interest to language can kill it too: Clean, Strongtalk, etc)
• Stop! How to do I/O? Real programming?!!
• Ohh, if we will wrap it in lambda and defer it to top level (main::IO ()), it will have I/O type (wrapper is hidden in type)
• Let’s call it... Monad!!
• Wow, cool! Works! Anybody should use monads! Does not your language have monads? Then we fly to you! (everybody forgot that monads are workaround of Haskell limitation and are not needed in another languages. Also they lead to low-performance code)
• But how to compose them???!?!
• We will wrap/unwrap, wrap/unwrap.. Let’s call it... transformers!!! “Monad transformers” – sounds super cool. Your language does not have “lift” operation, right? Ugh...
• How to access records fields... How... That’s a question. ‘.’ - no! ‘#’ - no! Eureka! We will add several language extensions and voila!
• To be continued... 😊
 
I love Haskell but I think such curve is absolutely impossible in commercial language. With IT managers 😊 To solve problem in a way when solution leads to another problem which needs new solution again and reason is only to keep lambda-abstraction-only (OK, Vanessa, backpacks also 😉) Can you imagine that all cars will have red color? Or any food will be sweet? It’s not technical question, but psychological and linguistic. Why native languages are not so limited? They even borrow words and forms from another one 😊 
 
Haskell’s core team knows how better then me, and I respect a lot of Haskell users, most of them helped me A LOT (!!!). It’s not opinion even, because I don’t know what is a right way. Let’s call it observation and feeling of the future.
 
I feel: Haskell has 3 cases: 1) to die 2) to change itself 3) to fork to another language
How I see commercial successful Haskell-like language:
• No monads, no transformers
• There are dependent types, linear types
• There are other evaluation models/abstractions (not only lambda)
• Special syntax for records fields, etc
• Less operators noise, language extensions (but it’s very disputable)
• Solve problems with numerous from/to conversions (strings, etc)
• Solve problems with libraries
 
Last point needs explanation:
• There is a lot of libraries written to check some type concepts only, no any business value. Also there are a lot of libraries written by students while they are learning Haskell: mostly without any business value/abandoned
• There is situation when you have alternative libraries in one project due to dependencies (but should be one only, not both!)
• Strange dependencies: I have installed Agda even! Why???!
 
IMHO problems with libraries and lambda-only-abstraction lead to super slow compilation, big and complex compiler.
So, currently I see (again, it’s my observation only) 2 big “camps”:
1. Academia, which has own interests, for example, to keep Haskell minimalistic (one-only-abstraction). Trade-off only was to add language extensions but they fragmentizes the language
2. Practical programmers, which interests are different from 1st “camp”
 
Another my observation is: a lot of peoples tried Haskell and switched to another languages (C#, F#, etc) because they cannot use it for big enterprise projects (Haskell becomes hobby for small experiments or is dropped off).
 
Joachim, I’m absolutely agreed that a big company can solve a lot of these problems. But some of them have already own languages (you can compare measure units in Haskell and in F#, what looks better...).
 
When I said about killer app, I mean: devs like Ruby not due to syntax but RoR. The same Python: sure, Python syntax is very good, but without Zope, Django, TurboGears, SQLAlchemy, Twisted, Tornado, Cheetah, Jinja, etc – nobody will use Python. Sure, there are exceptions: Delphi, CBuilder, for example. But this is bad karma of Borland 😊 They had a lot of compilers (pascal, prolog, c/c++, etc), but... On the other hand after reincarnation we have C# 😊  Actually all these are only observations: nobody knows the future.
 
 
/Best regards, Paul
 
From: Joachim Durchholz
Sent: 13 июля 2018 г. 21:49
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)
 
Am 13.07.2018 um 09:38 schrieb PY:
> 1. Haskell limits itself to lambda-only. Example, instead to add other 
> abstractions and to become modern MULTI-paradigm languages,
 
"modern"?
That's not an interesting property.
"maintainable", "expressive" - THESE are interesting. Multi-paradigm can 
help, but if overdone can hinder it - the earliest multi-paradigm 
language I'm aware of was PL/I, and that was a royal mess I hear.
 
> So, point #1 is limitation in 
> abstraction: monads, transformers, anything - is function. It's not 
> good.
 
Actually limiting yourself to a single abstraciton tool can be good. 
This simplifies semantics and makes it easier to build stuff on top of it.
 
Not that I'm saying that this is necessarily the best thing.
 
> There were such languages already: Forth, Joy/Cat, APL/J/K... Most of
> them look dead.
Which proves nothing, because many multi-paradigm languages look dead, too.
 
> When you try to be elegant, your product (language) died.
Proven by Lisp... er, disproven.
 
> This is not my opinion, this is only my observation. People like 
> diversity and variety: in food, in programming languages, in relations, 
> anywhere :)
 
Not in programming languages.
Actually multi-paradigm is usually a bad idea. It needs to be done in an 
excellent fashion to create something even remotely usable, while a 
single-paradigm language is much easier to do well.
And in practice, bad language design has much nastier consequences than 
leaving out some desirable feature.
 
> 2. When language has killer app and killer framework, IMHO it has more 
> chances. But if it has _killer ideas_ only... So, those ideas will be 
> re-implemented in other languages and frameworks but with more simple 
> and typical syntax :)
 
"Typical" is in the eye of the beholder, so that's another non-argument.
 
> It's difficult to compete with product, 
> framework, big library, but it's easy to compete with ideas. It's an 
> observation too :-)
 
Sure, but Haskell has product, framework, big library.
What's missing is commitment by a big company, that's all. Imagine 
Google adopting Haskell, committing to building libraries and looking 
for Haskell programmers in the streets - all of a sudden, Haskell is 
going to be the talk of the day. (Replace "Google" with whatever 
big-name company with deep pockets: Facebook, MS, IBM, you name it.)
 
> language itself is not argument for me.
 
You are arguing an awful lot about missing language features 
("multi-paradigm") to credibly make that statement.
 
> Argument for me (I 
> am usual developer) are killer apps/frameworks/libraries/ecosystem/etc. 
> Currently Haskell has stack only - it's very good, but most languages 
> has similar tools (not all have LTS analogue, but big frameworks are the 
> same).
 
Yeah, a good library ecosystem is very important, and from the reports I 
see on this list it's not really good enough.
The other issue is that Haskell's extensions make it more difficult to 
have library code interoperate. Though that's a trade-off: The freedom 
to add language features vs. full interoperability. Java opted for the 
other opposite: 100% code interoperability at the cost of a really 
annoying language evolution process, and that gave it a huge library 
ecosystem.
 
But... I'm not going to make the Haskell developers' decisions. If they 
don't feel comfortable with reversing the whole culture and make 
interoperability trump everything else, then I'm not going to blame 
them. I'm not even going to predict anything about Haskell's future, 
because my glass orb is out for repairs and I cannot currently predict 
the future.
 
Regards,
Jo
_______________________________________________
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/20180714/d167d9c2/attachment.html>

From allbery.b at gmail.com  Sat Jul 14 16:02:47 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 14 Jul 2018 12:02:47 -0400
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavouriteHaskell "aha" moment?)
In-Reply-To: <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
Message-ID: <CAKFCL4V2CocUP197sx9+9J11QKxn-vmRZU-Nt5iyz=mHC1Eh5Q@mail.gmail.com>

On Sat, Jul 14, 2018 at 11:28 AM Paul <aquagnu at gmail.com> wrote:

> Better IMHO to have less infrastructure code. Better is to hide all
> “machinery” in compiler.
>

Hiding all "machinery" in the compiler leads to perl 5, PL/1, and similar
monoliths. Which, if they do manage to catch on, eventually get discarded
because the "compiler" can't keep up with the rest of the world without
becoming a completely different language… which will move everything into
the ecosystem so it can keep up.

Monoliths have one advantage: people can ignore all the stuff going inside
the monolith, and therefore think they're easier to work with. Until they
no longer do what those people need, and they get tossed on the trash heap,
never to be seen again. The languages that stick around, that are still
used, are the ones that are extensible instead of being monoliths.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180714/d639729a/attachment.html>

From vlatko.basic at gmail.com  Sat Jul 14 16:22:39 2018
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Sat, 14 Jul 2018 18:22:39 +0200
Subject: [Haskell-cafe] SqlPersistT action in MonadError issue
Message-ID: <31fe16b5-8ecb-5795-7ba5-58d5cb84a2b2@gmail.com>

Hello,

I'm trying to use SqlPersistT funcs with MonadError, but am failing in writing 
the runDB correctly.

I tried several things, but always getting:

     • Couldn't match type ‘IOException’ with ‘AppException’
         arising from a functional dependency between:
           constraint ‘MonadError AppException IO’ arising from a use of ‘f1’
           instance ‘MonadError IOException IO’ at <no location info>
     • In the second argument of ‘runPool’, namely ‘f1’
       In the second argument of ‘($)’, namely ‘runPool pgConf f1 pgPool’
       In a stmt of a 'do' block: liftIO $ runPool pgConf f1 pgPool

I understand there already is "instance MonadError IOException IO" and fundep 
says it can be only one for IO.

How to make it compile?


Best regards,

vlatko


Here is the minimal reproducible code:

module Test where

import Prelude
import Control.Exception.Base
import Control.Monad.Except
import Control.Monad.Trans.Reader
import Database.Persist.Postgresql

data AppException =
     ExcText String
   | ExcIO IOException
   deriving (Show)

type AppM m = ExceptT AppException (ReaderT App m)
data App    = App { pgConf :: PostgresConf, pgPool :: ConnectionPool}

runDB :: (MonadIO m, MonadError AppException m) => AppM m Bool
runDB = do
   App{..} <- lift ask
   liftIO $ runPool pgConf *f1* pgPool    -- error
   -- liftIO $ runPool pgConf *f2* pgPool  -- OK


f1 :: (MonadIO m, MonadError AppException m) => SqlPersistT m Bool
f1 = throwError $ ExcText "exception"

f2 :: MonadIO m => SqlPersistT m Bool
f2 = return True

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

From parsonsmatt at gmail.com  Sat Jul 14 18:09:09 2018
From: parsonsmatt at gmail.com (Matt)
Date: Sat, 14 Jul 2018 12:09:09 -0600
Subject: [Haskell-cafe] SqlPersistT action in MonadError issue
In-Reply-To: <31fe16b5-8ecb-5795-7ba5-58d5cb84a2b2@gmail.com>
References: <31fe16b5-8ecb-5795-7ba5-58d5cb84a2b2@gmail.com>
Message-ID: <CA+4qU94_fgEM4O-=-fSVsPD_f8VVSNKdpUhY7E_h_XfcmTxYHg@mail.gmail.com>

The type of `runPool` is given here:
https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#v:runPool

    runPool :: MonadUnliftIO
<https://www.stackage.org/haddock/lts-12.0/conduit-1.3.0.3/Conduit.html#t:MonadUnliftIO>
 m => c -> PersistConfigBackend
<https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#t:PersistConfigBackend>
 c m a -> PersistConfigPool
<https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#t:PersistConfigPool>
 c -> m a

The return type of `runPool`, then, is `m a`, for some `m` satisfying
`MonadUnliftIO`.

The type of `liftIO` is `liftIO :: (MonadIO m) => IO a -> m a`. This means
that the first argument to `liftIO` must be an `IO a`.

When we say `liftIO (runPool ...)`, GHC tries to unify the `m a` from
`runPool` and the `IO a` from `liftIO`. It is able to do this, as `IO` is
an instance of `MonadUnliftIO`. Then, the concrete type of `runPool pgConf
f1 pgPool` becomes `IO Bool`.

GHC now tries to unify the `m` in `f1 :: (MonadIO m, MonadError
AppException m) => SqlPersistT m Bool` with `IO`. It tries to satisfy the
constraints: `MonadIO` is easily satisfied, but `MonadError AppException m`
triggers the problem you mention.

Because `ExceptT` does not have an instance for `MonadUnliftIO`, we cannot
use it with the `m` in `SqlPersistT m Bool` directly. We can, instead, use
`mapReaderT` to push the `Either` into the return type, like this:

pushException :: SqlPersistT (ExceptT e m) a -> SqlPersistT m (Either e a)
pushException = mapReaderT runExceptT


Now, we can write:

liftIO $ runPool pgConf (pushException f1) pgPool

This gives us an `IO (Either AppException Bool)`, which, after lifting,
gives us `AppM IO (Either AppException Bool)`. You can then use `either
throwError pure` to pull the `AppException` into the `ExceptT` again.

---

I would suggest that you reconsider this approach, however. The
`persistent` library uses transactions and exceptions in a way that is
*almost always* what you want, but can be surprising, and using `ExceptT`
will break this system. Transactions are automatically rolled back on a
`MonadCatch`-style exception, but they are not automatically rolled back on
an `ExceptT`-style exception. Having a single `AppException` type that
represents errors that can occur in database transactions *and* the rest of
your application is also going to be a cause for unsafety and errors, as
the type cannot possibly be precise enough to provide any safety.


Matt Parsons

On Sat, Jul 14, 2018 at 10:22 AM, Vlatko Basic <vlatko.basic at gmail.com>
wrote:

> Hello,
>
> I'm trying to use SqlPersistT funcs with MonadError, but am failing in
> writing the runDB correctly.
>
> I tried several things, but always getting:
>
>     • Couldn't match type ‘IOException’ with ‘AppException’
>         arising from a functional dependency between:
>           constraint ‘MonadError AppException IO’ arising from a use of
> ‘f1’
>           instance ‘MonadError IOException IO’ at <no location info>
>     • In the second argument of ‘runPool’, namely ‘f1’
>       In the second argument of ‘($)’, namely ‘runPool pgConf f1 pgPool’
>       In a stmt of a 'do' block: liftIO $ runPool pgConf f1 pgPool
> I understand there already is "instance MonadError IOException IO" and
> fundep says it can be only one for IO.
>
> How to make it compile?
>
> Best regards,
>
> vlatko
>
>
>
> Here is the minimal reproducible code:
> module Test where
>
> import Prelude
> import Control.Exception.Base
> import Control.Monad.Except
> import Control.Monad.Trans.Reader
> import Database.Persist.Postgresql
>
> data AppException =
>     ExcText String
>   | ExcIO IOException
>   deriving (Show)
>
> type AppM m = ExceptT AppException (ReaderT App m)
> data App    = App { pgConf :: PostgresConf, pgPool :: ConnectionPool}
>
> runDB :: (MonadIO m, MonadError AppException m) => AppM m Bool
> runDB = do
>   App{..} <- lift ask
>   liftIO $ runPool pgConf *f1* pgPool    -- error
>   -- liftIO $ runPool pgConf *f2* pgPool  -- OK
>
>
> f1 :: (MonadIO m, MonadError AppException m) => SqlPersistT m Bool
> f1 = throwError $ ExcText "exception"
>
> f2 :: MonadIO m => SqlPersistT m Bool
> f2 = return True
>
>
> _______________________________________________
> 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/20180714/ce116343/attachment-0001.html>

From mail at joachim-breitner.de  Sat Jul 14 19:03:41 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 14 Jul 2018 15:03:41 -0400
Subject: [Haskell-cafe] Request for Nominations to the GHC Steering Committee
Message-ID: <4fcd78fed019414a0b90884c4b72f42aa09aa6ea.camel@joachim-breitner.de>

Dear Haskell community,

the GHC Steering committee is seeking nominations for a new member.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC.
Our processes are described at
   https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability 
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and 
   specifications,
 * comment constructively and improve the proposals,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the
   utility or otherwise of proposed features,
 * have made active contributions to the Haskell community, for
   some time,
 * have expertise in language design and implementation, in either
   Haskell or related languages, which they can share with us.

The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks (within days is even better). Please keep that in mind if your
email inbox is already overflowing.

The GHC developers themselves are already well represented already.  We
seek Haskell _users_ more than GHC hackers.

There is no shortage of people who are very eager to get fancy new
features into the language, both in the committee and the wider
community. But each new feature imposes a cost, to implement, to learn,
(particularly) through its unexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as GHC
always has) while still making Haskell attractive for real-world
production use and for teaching. We therefore explicitly invite
“conservative” members of the community to join the committee.

To make a nomination, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de until July 23th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

We explicitly encourage self-nominations. You can nominate others, but
please obtain their explicit consent to do so. (We don’t want to choose
someone who turns out to be unable to serve.)

On behalf of the committee,
Joachim Breitner

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180714/4725ee86/attachment.sig>

From serg.foo at gmail.com  Sat Jul 14 20:02:06 2018
From: serg.foo at gmail.com (Sergey Vinokurov)
Date: Sat, 14 Jul 2018 21:02:06 +0100
Subject: [Haskell-cafe] Package takeover: bencoding
Message-ID: <b5f6b317-0fb8-fcdd-5276-d47a24393042@gmail.com>

I'd like to take over maintainership of the bencoding package [1].

The package was not updated to work with ghc 8.0 and will likely require
more fixes to work with ghc 8.4 and some work to make a Stackage
release. There's a PR open for GHC 8.0, but it's still open for a year
and a half [2]. I've tried to ask the author in the PR thread to make me
a maintainer in January but it still hasn't happened.

Cheers,
Sergey

[1]: http://hackage.haskell.org/package/bencoding
[2]: https://github.com/pxqr/bencoding/pull/7

From jerzy.karczmarczuk at unicaen.fr  Sat Jul 14 22:33:29 2018
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Sun, 15 Jul 2018 00:33:29 +0200
Subject: [Haskell-cafe] Investing in languages
In-Reply-To: <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
Message-ID: <dcb50e2d-9f9c-f4af-80b7-411d810764b8@unicaen.fr>

Le 14/07/2018 à 17:28, Paul ["aquagnu"]a écrit :
> By the way, Haskell role was to kill SML community, sure it is sad to 
> acknowledge it, but it’s 100% true...

Could you please cite some */serious/* source supporting this claim?
===
> And IMHO there was some lazy dialect of ML (may be, I’m not right).

LML of Lennart Augustsson and Thomas Johnsson, 1984 ("LISP and 
Functional Programming"). It came before Miranda (1985)...
If you are not certain, read something, please...

> Smalltalk was good language (*mostly dead*, except Pharo, which looks 
> cool).
Well, Squeak is alive, its "children": Scratch, Snap, etc, as well. 
Pharo is a fork of Squeak as well.
The European Smalltalk User Group organizes in September quite a big 
conference in Cagliari.
It seems that you are exaggerating a bit, killing all the languages you 
have heard [a little...] about...

Jerzy Karczmarczuk
/Caen, France/



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180715/65ba2d75/attachment.html>

From ben at smart-cactus.org  Sat Jul 14 23:02:51 2018
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 14 Jul 2018 19:02:51 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.3 released
In-Reply-To: <37c19c47-5984-4a59-fb04-b4bd962d53d8@limperg.de>
References: <87lgc2kyyx.fsf@smart-cactus.org>
 <37c19c47-5984-4a59-fb04-b4bd962d53d8@limperg.de>
Message-ID: <87r2k5o1yg.fsf@smart-cactus.org>

Jannis Limperg <jannis at limperg.de> writes:

> Hej Ben,
>
> the release page for GHC 8.4.3 is currently missing a Fedora binary. Is
> this intentional?
>
Fixed. Sorry for the latency. My Fedora build environment died so it
took some time to bring things up again.

Cheers,

- Ben

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

From alexey.raga at gmail.com  Sun Jul 15 06:44:07 2018
From: alexey.raga at gmail.com (Alexey Raga)
Date: Sun, 15 Jul 2018 16:44:07 +1000
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavouriteHaskell "aha" moment?)
In-Reply-To: <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
Message-ID: <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>

> Oh, my 1st question will be: did you try Eta, Frege?
Yes, I tried Eta for some time, implemented a couple of Kafka-related
libraries in it (Kafka Client, Schema Registry, etc.)
Eta is Haskell 7.10.3 with C FFI replaced with Java FFI (plus some features
ported from GHC 8)

>  Eta should support Haskell libraries as well as Java ones?
Eta does. Through a very nice FFI. But so does Haskell. We have nice FFI to
use C libs. I maintain a couple of libs that use it extensively, works
quite well.
There are also things like "inline-c", "inline-r", "inline-java" in
Haskell, so we CAN call to another languages/paradigms quite nicely. I
don't see your point here making parallels with Eta.

>  expressions are not monads but step forward, “monads++”
Can I have a definition and laws of "monad++"? Otherwise, I don't
understand what you are talking about. If it obeys monadic laws it is a
monad. But I'll wait for the definition.

> Prolog can be “pure” and to do I/O without monads, also Clean can as well
as F#.
But it is not lazy - one. Remember, laziness is our requirement here.
Whatever you propose _must _ work in a context of laziness.
Second, the inability to track side effects in F# is not "simplification"
and is not a benefit, but rather a limitation and a disadvantage of the
language and its type system.
It is _just a bit_ less dramatic in F# because F# is not lazy, but it is
quite a miss anyway.
Third, AFAIK CLR restrictions do not allow implementing things like
Functor, Monad, etc. in F# directly because they can't support HKT. So they
workaround the problem.
But again, F# cannot be expressive enough: no HKT, no ability to express
constraints, no ability to track effects...

> I’m not unique in my opinion: https://www.youtube.com/watch?v=rvRD_LRaiRs
I've watched this talk and I haven't got the point. I don't take
"unfamiliar means bad" or "unfamiliar means complex" points.

> overengineering due to mentioned limitation. No such one in ML, F#.
Really?  You keep mentioning F#, and I struggle with it right now _because_
of such limitations. There are no meaningful ways abstract over generics,
it is impossible to reason about functions' behaviours from their type
signatures (because side effects can happen anywhere), it has Option, but
you still can get Null, you can't have constraints, etc., etc. It is
sooooo muuuuch mooore limited.

> I can achieve Maybe effect with nullable+exceptions or ?-family operators,
No, you can't.

> Nobody will remember them after 5-10 years...
OCaml exists for 22 years now, doing well and solves problems it has been
designed for very well. So _already_ more than twice compare to your
prediction.

>  fields are not starting with “_” prefix, so I need to create lenses
explicitly
No you don't. You don't have to have "_" prefix to generate a lense. You
have total control here.

> What is the business value of such code: nothing
Can you define "business value" please? You mention it for a couple of
times, so I am puzzled. Otherwise, it reminds me of
https://twitter.com/newhoggy/status/999930802589724672

> For non-Haskell programmer it looks like you try to solve non-existing
problem
For Haskell programmers, Java solves non-existing problems all the time :)
Every single time you see on twitter or here something like "I replaced
hundreds of lines of Java code with a single 'traverse'" you get the proof.
And it happens so often.
Also, what exactly is that "non-existent problem"?
In an immutable environment (and C# gives you that, F# does, even JS does),
how do these languages solve that non-existing problem that lens setters
do? I'll answer this question myself: they don't. So even in JavaScript my
non-FP colleagues working on frontend in JavaScript use JS lens library.
Precisely because it _does_ solve their very existing problems.

>  Haskell code needs help from IDE, types hints, etc.
Types are written and read by programmers. Java is impossible without IDE.
What is the point here?

> And I often meet a case when somebody does not understand what monads are
in “do” blocks.
Familiarity again. They learn and then they understand.
I don't understand C++. I barely understand C. I don't understand Ruby
(every time I have to work with it, it is a nightmare for me). I don't
understand Erlang.
Does it mean that all these languages are bad and need to die or change? Or
does it just mean that I am ignorant to learn them? I thinlk it is second.
I also understand English, I can understand Russian but not Japanese or
Swiss German. Or Tajik. Does it mean that Tajik is complicated? No, it is a
very simple  language I used to speak fluently when I was a child :)
Familiarity means nothing. I repeat: don't bring familiarity, it means
nothing.

> Text, also ByteString, lazy/strict, the same with the numbers
(word/int/integer)
But the problem is not with Text/ByteString! The problem is with the
perception that there must be just one string that rules them all!  But it
is wrong!
These types are different, for different use cases and with different
tradeoffs! It is good that I can choose what I need according to my
requirements.
Int/Word are not even close to being the same! Words cannot be negative, at
least.
If you do bits manipulations you want Words, not Ints! Java doesn't have
unsigned numbers, so bits manipulations are insanely hard in Java since you
_always_ need account to the sign bits. This the _real_ problem.

> Better is to have one good solid library bundled with GHC itself
(“batteries included”) and only specific things will live in libraries and
frameworks.
Better for whom? Definitely NOT better for me and my team using Haskell
commercially. Again, to effectively meet requirements, functional and
non-functional, we don't want just a mediocre compromise thing. I gave you
an example with parsers already: different parsers have different
tradeoffs. It is often a GOOD thing that there are many different libraries
doing the same thing differently.

As a person using Haskell commercially, I specifically don't want a
"batteries included, one way of doing things" solution.

Regards,
Alexey.

On Sun, Jul 15, 2018 at 1:28 AM Paul <aquagnu at gmail.com> wrote:

> Hello Alex!
>
>
>
> > A small disclaimer: none of the members of our team has an academic
> background. We all have different backgrounds: C#, Java, Ruby, Python, C,
> even Perl if I am not mistaken. Yet we ended up with FP first, and then
> with Haskell.
>
> > We have switched to Haskell from Scala, which _is_ a multi-paradigm
> language borrowing bits and pieces from other languages/paradigms and
> mixing them together. It is an enormously hard work to do it and for that,
> I very much respect
>
>
>
> Oh, my 1st question will be: did you try Eta, Frege? May be I’m wrong but
> Eta should support Haskell libraries as well as Java ones? They allow you
> to use libraries from the both world...
>
>
>
> > As a result, the language becomes overly complicated and less useful.
>
>
>
> Yes, this is another side. You know, anything has several sides: good and
> bad...
>
>
>
> > Your joke about how Haskell has been made misses one point: it was
> initially designed as a lazy language (at least as far as I know). Many
> features that Haskell has now are there because of laziness: if you want to
> be lazy, then you have to be pure, you have to sequence your effects, etc.
>
>
>
> True. Laziness makes Haskell unique. I think Haskell makes laziness so
> popular in modern languages although it was known long ago (as data in
> “infinite streams”, etc). I think, Miranda was lazy, so Haskell is lazy too
> 😊 And IMHO there was some lazy dialect of ML (may be, I’m not right).
>
>
>
> > "Let's defer lambda, name it IO and let's call it Monad" -  this bit
> isn't even funny. Monad isn't IO. IO happens to be a monad (as many things
> do, List as an example), but monad isn't IO and has nothing to do with IO.
> A horse is classified as Mammal, but Mammal doesn't mean horse _at all_.
>
>
>
> Sure. I mean, the need of side-effects (and firstly I/O) led to the monads.
>
>
>
> > In a context of a lazy language, you need to sequence your effects
> (including side effects), that's the first point. The second is that
> instead of disappearing from Haskell, monads (and other concepts) are
> making their way to other languages. Scala has them, F# has them, even C#
> has them (however indirectly). Try to take away List Monad from C#
> developers and they'll kill you ;)
>
>
>
> Better IMHO to have less infrastructure code. Better is to hide all
> “machinery” in compiler.
>
>
>
> My point was that monads are workaround of Haskell problem, this was
> historically reason of their appearance. And if I have not such limitation
> in my language I don’t need any monads. What are the monad benefits in ML,
> for example? They are using in F#, but 1) comp. expressions are not monads
> but step forward, “monads++” and 2) they play different role in F#:
> simplifying of the code. And you *can* avoid them in all languages except
> Haskell. For example, Prolog can be “pure” and to do I/O without monads,
> also Clean can as well as F#. Monads have pros, sure, but they are not
> composable and workaround leads to another workaround – transformers. I’m
> not unique in my opinion: https://www.youtube.com/watch?v=rvRD_LRaiRs All
> of this looks like overengineering due to mentioned limitation. No such one
> in ML, F#. D has keyword “pure”, and didn’t introduce monads. Performance
> is very important feature of the language, that limitation is the reason #1
> why Haskell has bad and unpredictable performance. “do”-block is not the
> same as “flat” block of C# statements and its performance is not the same.
> I can achieve Maybe effect with nullable+exceptions or ?-family operators,
> List with permutations/LINQ, guard with if+break/continue and to do it
> without sacrificing performance.. ListT/conduits – are just
> generators/enumerators. Benefit of monads IMHO is small, they are
> workaround of Haskell problem and are not needed in other languages. Sure,
> there are monads in Ocaml, Javascript, Python (as experimental libraries),
> but the reason is hype. Nobody will remember them after 5-10 years...
>
>
>
> Actually this is very-very subjective IMHHHHO 😊
>
>
>
> > Lenses and generic lenses help, so be it. But I don't think that
> anything prevents Haskell from having it, and I don't think that Haskell as
> a language needs a dramatic change as you depict to make it happen. Just a
> feature.
>
>
>
> When I have legacy code, there are a lot of types which fields are not
> starting with “_” prefix, so I need to create lenses explicitly...
> “Infrastructure” code. What is the business value of such code: nothing.
> For non-Haskell programmer it looks like you try to solve non-existing
> problem 😊  (*very-very provocative point: all Haskell solutions looks
> very overengineering. The reason is: lambda-abstraction-only. When you try
> to build something big from little pieces then the process will be very
> overengineering. Imagine that the pyramids are built of small bricks*).
>
>
>
> > I don't agree that operators are noise. You certainly can write Haskell
> almost without operators if you wish.
>
>
>
> Here I’m agree with D. Knuth ideas of literature programming: if code can
> not be easy read and understand on the hard-copy then used language is not
> fine. Haskell code needs help from IDE, types hints, etc. And I often meet
> a case when somebody does not understand what monads are in “do” blocks.
> Also there are a lot of operators in different libraries and no way to know
> what some operator means (different libraries, even different versions have
> own set of operators).
>
>
>
> > As for extensions, I think that many more should be just switched on by
> default.
>
>
>
> +1
>
>
>
> > You mean that conversion should happen implicitly? Thank you, but no,
> thank you. This is a source of problems in many languages, and it is such a
> great thing that Haskell doesn't coerce types implicitly.
>
>
>
> No... Actually, I have not idea what is better. Currently there are a lot
> of conversions. Some libraries functions expect String, another - Text,
> also ByteString, lazy/strict, the same with the numbers (word/int/integer).
> So, conversions happen often.
>
>
>
> > I don't understand this "no business value" statement. Value for which
> business? What does it mean "check types, no business value"?
>
> There are libraries which nothing do in run-time. Only types playing. Only
> abstractions over types. And somebody says: oh man, see how many libraries
> has Haskell. But you can compare libraries of Haskell, Java, C#,
> Javascript, Perl, Python 😊 All libraries of Java, Python... have
> business value. Real-world functionality. Not abstract play with types. But
> more important point is a case with installed Agda 😊 or alternative
> libraries which does the same/similar things. The reason is important:
> Haskell moves a lot of functionality to libraries which is not good design
> IMHO. This is the root of the problem. Better is to have one good solid
> library bundled with GHC itself (“batteries included”) and only specific
> things will live in libraries and frameworks. Monads and monads
> transformers are central thing in Haskell. They a located in libraries.
> There is standard parser combinators in GHC itself, but you will have in
> the same project another one (or more than 1!). Etc, etc...
>
>
>
> Also installed GHC... Why is it so big!? IMHO it’s time to clear
> ecosystem, to reduce it to “batteries” 😊
>
>
>
> > And then it falls into a famous joke: "The problem with Open Source
> Software is YOU because YOU are not contributing" :) Meaning that if we
> want more good libs then we should write more good libs :)
>
>
>
> Absolutely true 😊
>
>
>
> On Sat, Jul 14, 2018 at 5:05 PM Paul <aquagnu at gmail.com> wrote:
>
> I understand that my points are disputable, sure, example, multi-pardigm
> Oz – dead 😊 Any rule has exceptions. But my point was that people don’t
> like elegant and one-abstraction languages. It’s my observation. For me,
> Smalltalk was good language (mostly dead, except Pharo, which looks cool).
> Forth – high-level “stack-around-assembler”, mostly dead (Factor looks
> abandoned, only 8th looks super cool, but it’s not free). What else?
> Lisp? OK, there are SBCL, Clojure, Racket... But you don’t find even
> Clojure in languages trends usually. APL, J – super cool! Seems dead (I
> don’t know what happens with K). ML, SML? By the way, Haskell role was to
> kill SML community, sure it is sad to acknowledge it, but it’s 100% true...
>
>
>
> Haskell try to be minimalistic and IMHO this can lead to death. Joachim,
> I’m not talking “it’s good/it’s bad”, “multiparadigm is good” or else... I
> don’t know what is right. It’s my observations only. Looks like it can
> happen.
>
>
>
> If we will look to Haskell history then we see strange curve. I’ll try to
> describe it with humour, so, please, don;t take it seriously 😊
>
> ·       Let’s be pure lambda fanatics!
>
> ·       Is it possible to create a big application?
>
> ·       Is it possible to compile and optimize it?!
>
> ·       Let’s try...
>
> ·       Wow, it’s possible!!! (sure, it’s possible, Lisp did it long-long
> ago).
>
> ·       Looks like puzzle, can be used to write a lot of articles (there
> were articles about combinators, Jay/Cat/Scheme, etc, now there are a lot
> of Haskell articles – big interesting in academia. But IMHO academia
> interest to language can kill it too: Clean, Strongtalk, etc)
>
> ·       Stop! How to do I/O? Real programming?!!
>
> ·       Ohh, if we will wrap it in lambda and defer it to top level
> (main::IO ()), it will have I/O type (wrapper is hidden in type)
>
> ·       Let’s call it... Monad!!
>
> ·       Wow, cool! Works! Anybody should use monads! Does not your
> language have monads? Then we fly to you! (everybody forgot that monads are
> workaround of Haskell limitation and are not needed in another languages.
> Also they lead to low-performance code)
>
> ·       But how to compose them???!?!
>
> ·       We will wrap/unwrap, wrap/unwrap.. Let’s call it...
> transformers!!! “Monad transformers” – sounds super cool. Your language
> does not have “lift” operation, right? Ugh...
>
> ·       How to access records fields... How... That’s a question. ‘.’ -
> no! ‘#’ - no! Eureka! We will add several language extensions and voila!
>
> ·       To be continued... 😊
>
>
>
> I love Haskell but I think such curve is absolutely impossible in
> commercial language. With IT managers 😊 To solve problem in a way when
> solution leads to another problem which needs new solution again and reason
> is only to keep lambda-abstraction-only (OK, Vanessa, backpacks also 😉)
> Can you imagine that all cars will have red color? Or any food will be
> sweet? It’s not technical question, but psychological and linguistic. Why
> native languages are not so limited? They even borrow words and forms from
> another one 😊
>
>
>
> Haskell’s core team knows how better then me, and I respect a lot of
> Haskell users, most of them *helped me A LOT* (!!!). It’s not opinion
> even, because I don’t know what is a right way. Let’s call it observation
> and feeling of the future.
>
>
>
> I feel: Haskell has 3 cases: 1) to die 2) to change itself 3) to fork to
> another language
>
> How I see commercial successful Haskell-like language:
>
> ·       No monads, no transformers
>
> ·       There are dependent types, linear types
>
> ·       There are other evaluation models/abstractions (not only lambda)
>
> ·       Special syntax for records fields, etc
>
> ·       Less operators noise, language extensions (but it’s very
> disputable)
>
> ·       Solve problems with numerous from/to conversions (strings, etc)
>
> ·       Solve problems with libraries
>
>
>
> Last point needs explanation:
>
> ·       There is a lot of libraries written to check some type concepts
> only, no any business value. Also there are a lot of libraries written by
> students while they are learning Haskell: mostly without any business
> value/abandoned
>
> ·       There is situation when you have alternative libraries in one
> project due to dependencies (but should be one only, not both!)
>
> ·       Strange dependencies: I have installed Agda even! Why???!
>
>
>
> IMHO problems with libraries and lambda-only-abstraction lead to super
> slow compilation, big and complex compiler.
>
> So, currently I see (again, it’s my observation only) 2 big “camps”:
>
> 1.       Academia, which has own interests, for example, to keep Haskell
> minimalistic (one-only-abstraction). Trade-off only was to add language
> extensions but they fragmentizes the language
>
> 2.       Practical programmers, which interests are different from 1st
> “camp”
>
>
>
> Another my observation is: a lot of peoples tried Haskell and switched to
> another languages (C#, F#, etc) because they cannot use it for big
> enterprise projects (Haskell becomes hobby for small experiments or is
> dropped off).
>
>
>
> Joachim, I’m absolutely agreed that a big company can solve a lot of these
> problems. But some of them have already own languages (you can compare
> measure units in Haskell and in F#, what looks better...).
>
>
>
> When I said about killer app, I mean: devs like Ruby not due to syntax but
> RoR. The same Python: sure, Python syntax is very good, but without Zope,
> Django, TurboGears, SQLAlchemy, Twisted, Tornado, Cheetah, Jinja, etc –
> nobody will use Python. Sure, there are exceptions: Delphi, CBuilder, for
> example. But this is bad karma of Borland 😊 They had a lot of compilers
> (pascal, prolog, c/c++, etc), but... On the other hand after reincarnation
> we have C# 😊  Actually all these are only observations: nobody knows the
> future.
>
>
>
>
>
> /Best regards, Paul
>
>
>
> *From: *Joachim Durchholz <jo at durchholz.org>
> *Sent: *13 июля 2018 г. 21:49
> *To: *haskell-cafe at haskell.org
> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
> yourfavourite Haskell "aha" moment?)
>
>
>
> Am 13.07.2018 um 09:38 schrieb PY:
>
> > 1. Haskell limits itself to lambda-only. Example, instead to add other
>
> > abstractions and to become modern MULTI-paradigm languages,
>
>
>
> "modern"?
>
> That's not an interesting property.
>
> "maintainable", "expressive" - THESE are interesting. Multi-paradigm can
>
> help, but if overdone can hinder it - the earliest multi-paradigm
>
> language I'm aware of was PL/I, and that was a royal mess I hear.
>
>
>
> > So, point #1 is limitation in
>
> > abstraction: monads, transformers, anything - is function. It's not
>
> > good.
>
>
>
> Actually limiting yourself to a single abstraciton tool can be good.
>
> This simplifies semantics and makes it easier to build stuff on top of it.
>
>
>
> Not that I'm saying that this is necessarily the best thing.
>
>
>
> > There were such languages already: Forth, Joy/Cat, APL/J/K... Most of
>
> > them look dead.
>
> Which proves nothing, because many multi-paradigm languages look dead, too.
>
>
>
> > When you try to be elegant, your product (language) died.
>
> Proven by Lisp... er, disproven.
>
>
>
> > This is not my opinion, this is only my observation. People like
>
> > diversity and variety: in food, in programming languages, in relations,
>
> > anywhere :)
>
>
>
> Not in programming languages.
>
> Actually multi-paradigm is usually a bad idea. It needs to be done in an
>
> excellent fashion to create something even remotely usable, while a
>
> single-paradigm language is much easier to do well.
>
> And in practice, bad language design has much nastier consequences than
>
> leaving out some desirable feature.
>
>
>
> > 2. When language has killer app and killer framework, IMHO it has more
>
> > chances. But if it has _killer ideas_ only... So, those ideas will be
>
> > re-implemented in other languages and frameworks but with more simple
>
> > and typical syntax :)
>
>
>
> "Typical" is in the eye of the beholder, so that's another non-argument.
>
>
>
> > It's difficult to compete with product,
>
> > framework, big library, but it's easy to compete with ideas. It's an
>
> > observation too :-)
>
>
>
> Sure, but Haskell has product, framework, big library.
>
> What's missing is commitment by a big company, that's all. Imagine
>
> Google adopting Haskell, committing to building libraries and looking
>
> for Haskell programmers in the streets - all of a sudden, Haskell is
>
> going to be the talk of the day. (Replace "Google" with whatever
>
> big-name company with deep pockets: Facebook, MS, IBM, you name it.)
>
>
>
> > language itself is not argument for me.
>
>
>
> You are arguing an awful lot about missing language features
>
> ("multi-paradigm") to credibly make that statement.
>
>
>
> > Argument for me (I
>
> > am usual developer) are killer apps/frameworks/libraries/ecosystem/etc.
>
> > Currently Haskell has stack only - it's very good, but most languages
>
> > has similar tools (not all have LTS analogue, but big frameworks are the
>
> > same).
>
>
>
> Yeah, a good library ecosystem is very important, and from the reports I
>
> see on this list it's not really good enough.
>
> The other issue is that Haskell's extensions make it more difficult to
>
> have library code interoperate. Though that's a trade-off: The freedom
>
> to add language features vs. full interoperability. Java opted for the
>
> other opposite: 100% code interoperability at the cost of a really
>
> annoying language evolution process, and that gave it a huge library
>
> ecosystem.
>
>
>
> But... I'm not going to make the Haskell developers' decisions. If they
>
> don't feel comfortable with reversing the whole culture and make
>
> interoperability trump everything else, then I'm not going to blame
>
> them. I'm not even going to predict anything about Haskell's future,
>
> because my glass orb is out for repairs and I cannot currently predict
>
> the future.
>
>
>
> Regards,
>
> Jo
>
> _______________________________________________
>
> 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/20180715/6f825e1c/attachment-0001.html>

From brettg at posteo.net  Sun Jul 15 07:59:20 2018
From: brettg at posteo.net (Brett Gilio)
Date: Sun, 15 Jul 2018 02:59:20 -0500
Subject: [Haskell-cafe] Investing in languages (Was: What is
	yourfavouriteHaskell "aha" moment?)
In-Reply-To: <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
 <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
Message-ID: <87sh4lrktj.fsf@posteo.net>


Alexey Raga writes:
> As a person using Haskell commercially, I specifically don't 
> want a
> "batteries included, one way of doing things" solution.

I usually do not send "I agree" messages.

But, I without reservation agree.

-- 
Brett M. Gilio
Free Software Foundation, Member
https://parabola.nu | https://emacs.org

From jo at durchholz.org  Sun Jul 15 09:50:01 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 15 Jul 2018 11:50:01 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What is
 yourfavouriteHaskell "aha" moment?)
In-Reply-To: <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
 <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
Message-ID: <32885136-f27a-f7ca-07d7-df7b41f1d086@durchholz.org>

Am 15.07.2018 um 08:44 schrieb Alexey Raga:
> If you do bits manipulations you want Words, not Ints! Java doesn't have 
> unsigned numbers, so bits manipulations are insanely hard in Java since 
> you _always_ need account to the sign bits. This the _real_ problem.

You don't use bit manipulation in (idiomatic) Java, you use EnumSets 
(use case 1) or one of the various infinite-digits math libraries (use 
case 2).
I have yet to see a third use case, and there's already libraries for 
these, so I do not see a problem.

All of which, of course, just elaborates the point you were making 
around this paragraph: Each language lives in its own niche, and when 
coming from a different niche one usually sees all kinds of problems but 
has yet to encounter the solutions.

Regards,
Jo

From vl81 at kent.ac.uk  Sun Jul 15 12:12:19 2018
From: vl81 at kent.ac.uk (Vilem-Benjamin Liepelt)
Date: Sun, 15 Jul 2018 13:12:19 +0100
Subject: [Haskell-cafe] What is your favourite Haskell "aha" 	moment?
In-Reply-To: <mailman.3.1531569601.14926.haskell-cafe@haskell.org>
References: <mailman.3.1531569601.14926.haskell-cafe@haskell.org>
Message-ID: <EDFC8553-F75E-4BF1-A9B6-0690FBD703BF@kent.ac.uk>

Dear MarLinn,

> Of course you need all that data because there's a ghc in that data, but 
> it should say so on the tin. So please never send a script with this 
> line to a "newbie" without big warnings so they can make an informed 
> decision.

That is a very good point. I just happen to use some particular LTS because I have it cached, so it works instantly for all my scripts. Thank you for reminding me that I shouldn't carelessly just pass this on for others to use without mentioning the caveats you pointed to.

> Also, while I do like the scripting possibilities, interact is possibly 
> the worst way to introduce a newcomer to it because you can't really 
> test it in ghci.


Your concern about testability in GHCi is valid but minor; you can just make the string transformation function a top-level declaration like so:

```
main = interact sumCLI

sumCLI :: String -> String
sumCLI = show @Double . sum . mapMaybe readMaybe . words
```

IMO `interact` is the easiest way for newcomers to write a script that they can actually use, hence why I opted for this instead of `print . sumCLi =<< getContents`.

Lastly, SPJ asked for our "aha" moments—this was mine. He always does a good job at serving information in a way that is digestible for the audience, so you need not worry that any lambs will be led astray.

Best,

Vilem

> On 2018-07-14, at 13:00, <haskell-cafe-request at haskell.org> <haskell-cafe-request at haskell.org> wrote:
> 
> [...]
> 
> Message: 4
> Date: Sat, 14 Jul 2018 13:33:31 +0200
> From: MarLinn <monkleyon at gmail.com>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] What is your favourite Haskell "aha"
> 	moment?
> Message-ID: <c7a00886-f32b-c4ae-617d-450394278b58 at gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> Warning: I'll be overly harsh in this mail because I assume some people 
> that are new to Haskell might browse this thread now and in the future. 
> I don't mean my comments to be considered personal. On the contrary, I 
> think some of us can learn for their own teaching endeavours.
> 
>> #!/usr/bin/env stack
>> -- stack script --resolver lts-10.1 --install-ghc
> 
> Imagine a "newbie" running this script just to see what it does. After 
> 15 minutes they'll be disappointed why your small demo took so long to 
> build. Only /then/ do they realize that, what is it today, about half a 
> gigabyte maybe, of their monthly "high speed" bandwidth and of their 
> precious space on the cheap but decade-old hard drive is gone.
> 
> Of course you need all that data because there's a ghc in that data, but 
> it should say so on the tin. So please never send a script with this 
> line to a "newbie" without big warnings so they can make an informed 
> decision. Maybe they would want to install ghc at their uni to save on 
> that precious bandwidth at home or something similar.
> 
> In fact don't even send scripts with this line to seasoned haskellers. 
> If your code is compatible with the ghc 8.2.1 on my system, why should 
> your script assume I want stack to install 8.2.2 right now?
> 
> Of course this behaviour is ingrained in the DNA of stack – after all it 
> values convenience for the professional user more than convenience for 
> the unprivileged newcomer – but AFAIU it /can/ be persuaded to be more 
> inclusive. So especially here, we should maybe try to do that.
> 
>>   interact
>>   ( show @Double
>>   . sum
>>   . mapMaybe readMaybe
>>   . words
>>   )
> 
> Also, while I do like the scripting possibilities, interact is possibly 
> the worst way to introduce a newcomer to it because you can't really 
> test it in ghci. Apart from all the other shortcomings it has. It is 
> nice in that it hides IO, but…
> 
> Again, not meant as an attack, but since we're talking about giving 
> newcomers a good experience, I thought these two points important.
> 
> Cheers,
> MarLinn
> 


From aquagnu at gmail.com  Sun Jul 15 16:06:58 2018
From: aquagnu at gmail.com (Paul)
Date: Sun, 15 Jul 2018 19:06:58 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What
 isyourfavouriteHaskell "aha" moment?)
In-Reply-To: <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
 <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
Message-ID: <5b4b7121.1c69fb81.7668.0525@mx.google.com>

➢ Eta does. Through a very nice FFI. But so does Haskell. We have nice FFI to use C libs. I maintain a couple of libs that use it extensively, works quite well.

I asked because never tried Eta. So, if you are right, seems no reasons to develop Eta...

➢ Can I have a definition and laws of "monad++"? Otherwise, I don't understand what you are talking about. If it obeys monadic laws it is a monad. But I'll wait for the definition. 

No better definition then original: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions  You see, they are different.

➢ But it is not lazy - one. Remember, laziness is our requirement here. Whatever you propose _must _ work in a context of laziness.

Does it mean because Haskell is lazy (Clean – not) then linear types are impossible in Haskell? If they are possible why we need monads? 

➢ Second, the inability to track side effects in F# is not "simplification" and is not a benefit, but rather a limitation and a disadvantage of the language and its type system.
Why?

Haskell “tracks” effects obviously. But I shown example with State monad already. As I saw, nobody understand that State monad does not solve problem of spaghetti-code style manipulation with global state. Even more, it masks problem. But it was solved in OOP when all changes of state happen in one place under FSM control (with explicit rules of denied transitions: instead of change you have a request to change/a message, which can fail if transition is denied). Haskell HAS mutable structures, side-effects and allows spaghetti-code.  But magical word “monad” allows to forget about problem and the real solution and to lie that no such problem at whole (it automatically solved due to magical safety of Haskell). Sure, you can do it in Haskell too, but Haskell does not force you, but Smalltalk, for example, forces you.

We often repeat this: “side-effects”, “tracks”, “safe”. But what does it actually mean? Can I have side-effects in Haskell? Yes. Can I mix side-effects? Yes. But in more difficult way than in ML or F#, for example. What is the benefit? Actually no any benefit, it’s easy understandable with simple experiment: if I have a big D program and I remove all “pure” keywords, will it become automatically buggy? No. If I stop to use “pure” totally, will it become buggy? No. If I add “print” for debug purpose in some subroutines, will they become buggy? No. If I mix read/write effects in my subroutine, will it make it buggy? No.

IMHO there is some substitution of concepts. Monads roots are not safety, but workaround to have effects in pure lambdas. And after monads introduction, a thesis was appeared: “monads make code more safe”. Motivation of monads was not to track effect (because it’s allegedly more safe), but to inject/allow/introduce effects in language like Haskell. Good example is State monad, again. State monad is needed to support manipulation of state (through argument replacement in chain of lambdas) but it’s totally other thing in comparison with idea to separate state manipulation in one isolated place under control of some FSM with explicit rules of allowed and denied transitions. If I am switching from read monad to RWST monad, will my code be more buggy? Again, no. Monads don’t decrease buggy or global-state-manipulation problems automatically, they are workaround for specific Haskell problem. Other languages don’t need monads. I CAN have monads in Python, Javascript but I don’t need them. My point is: monads are not valuable byself: Ocaml has not any monads and all is fine 😊

But it’s really very philosophical question, I think that monads are over-hyped actually. I stopped seeing the value of monads by themselves.

➢ Third, AFAIK CLR restrictions do not allow implementing things like Functor, Monad, etc. in F# directly because they can't support HKT. So they workaround the problem.

https://fsprojects.github.io/FSharpPlus/abstractions.html (btw, you can see that monad is monoid here 😉)

➢ But again, F# cannot be expressive enough: no HKT, no ability to express constraints, no ability to track effects...

If F# has monads (you call “monads” to computational expressions), then it CAN...
About HKT: yes, that’s true. But may be, it’s not so big problem? May be you can write effective, good and expressive code without them? Otherwise, we should agree that all languages without HKT are not expressive...

➢ Really?  You keep mentioning F#, and I struggle with it right now _because_ of such limitations. There are no meaningful ways abstract over generics, it is impossible to reason about functions' behaviours from their type signatures (because side effects can happen anywhere), it has Option, but you still can get Null, you can't have constraints, etc., etc. It is sooooo muuuuch mooore limited.

IMHO fear of “side effects can happen anywhere” becomes traditional thesis. And what is the problem if I add “print” in some function?! 😊 Again, substitution of concepts, of monad’s motivations. Haskell compiler can not transform code with side-effects in effective way, and I must isolate all side-effects, mark such functions, but this is the problem of Haskell compiler, not mine. Why programmer should help compiler?! You can look at MLTon compiler, or OCaml one. IMHO they are good and work fine with side-effects; programs WITH side-effects under RWST or State or without those monads in ML are equal: if I port 101 ML functions with side-effects to Haskell, then I will add monad and will have 101 functions with the same side-effects, but now under monad. I can propagate my monad anywhere 😊 All my functions can be under RWST or State. Again, this problem should be solved in other way, not by wrapping the same actions in some wrapper-type (monad). A funny consequence of this, now my program become deep nested lambdas. Compiler should try to “flat” some of them, but I am not competent how Haskell good in it. Anyway, performance will be worse than in ML version. But focus here is a mark-with-monad-type, not the avoid side-effects. And it’s needed for compiler, not for me. May be I’m not clean, may be it is heavy to accept to the people hypnotized by magic invocations about monads power, may be I don’t understand something 😊

➢ No, you can't. 

Something like this:   user?.Phone?.Company?.Name??"missing";     ?

(do
   u <- mbUser
   ph <- phoneOf u
   ...) <|> pure “missing”

➢ OCaml exists for 22 years now, doing well and solves problems it has been designed for very well. So _already_ more than twice compare to your prediction.

It’s Ocaml. It follows to the golden middle, to avoid danger corner 😉

➢ fields are not starting with “_” prefix, so I need to create lenses explicitly
➢ No you don't. You don't have to have "_" prefix to generate a lense. You have total control here. 

Hmm, may be I’m not right. I’m using microlenses and call `makeLensesFor`...

➢ Can you define "business value" please? You mention it for a couple of times, so I am puzzled. Otherwise, it reminds me of https://twitter.com/newhoggy/status/999930802589724672
➢ For Haskell programmers, Java solves non-existing problems all the time :) Every single time you see on twitter or here something like "I replaced hundreds of lines of Java code with a single 'traverse'" you get the proof. And it happens so often.

It involves a long talk 😉 Business value - I’ll illustrate it, imagine a code:

.... lift ....   – NO business value in lift! It’s infrastructure code
m <- loadModel “mymodel.bin” – there is business value
checkModel m rules – there is business value too

So, I can mark infrastructure code with red color, business code with green and to calculate ratio. And to talk about “usefulness/effectivity” of language. How many infrastructure noise have the language (Java, btw, IMHO will have bad ratio too). I have a tons of types, JSON to/from instances, - I repeat models which are coded in external 3rd part services. But F# team thinks like me: it’s not enterprise way to do things in such manner and they introduced types providers – it’s only small example. In Haskell I wrote a lot of infrastructure code, different instances, etc, etc. But other languages are more concentrated on business value, on domain, on business logic. I though about DSLs, but DSLs can be antipattern and to lead to other problems...

➢ Haskell code needs help from IDE, types hints, etc. 
➢ Types are written and read by programmers. Java is impossible without IDE.  What is the point here?

Usually it’s difficult to understand for programmers. Most say: Perl looks like sh*t. Just look at these %, $, etc. And they don’t understand simple thesis: language is about humans, about linguistic, not about computation. Language should not be oriented to compiler or to its computational model, how will you like to work with bytes and words only in C++? So, we have “a”, “the” in English, we have “%”, “$” in Perl. And I don’t know exact object “type” but I can imagine its nature, it’s scalar, vector, etc. In Haskell I can skip most signatures and such code is not readable, I need Intero help to check some types. It’s very bad situation. It’s not 100% true for Java because you will have signatures in Java, you can not skip them, right? And if I add operators noise also (when I have not idea what does this ASCII-art do), the code becomes IDE-centric.

➢ Better for whom? Definitely NOT better for me and my team using Haskell commercially. Again, to effectively meet requirements, functional and non-functional, we don't want just a mediocre compromise thing. I gave you an example with parsers already: different parsers have different tradeoffs. It is often a GOOD thing that there are many different libraries doing the same thing differently. 

Hm, if I have several libraries which are  doing similar things (only due to dependencies), then I have: 1) big Haskell installation (1Gb?) 2) slow compilation 3) big binaries, etc. I understand, you have freedom of choice. But let’s look to IT: C++ turned to one library (imported some Boost solutions, etc, etc), the same R7RS, D with its Phobos, Ocaml has batteries from Jane str., Python 😊 IMHO its general trend. Let’s imagine: project with 2, 3 parsers libraries, conduit and pipes, etc, due to dependencies. So, IMHO my point is not so strange or weird 😉 I’m talking about drop off those libraries (parsers, etc), but about creating of one solid library which components will depends only on it. Other alternatives will be somewhere in repos, who want, can use them without any problems. Something like Qt, Boost, Gtk, etc.

Let me be more precise, I’m comfort with Haskell at whole, but 1) I discussed Haskell with other people 2) I read opinion of other people in industry 2) I’m programmer since 97 and I have critical kind of the mind, so all of these allows me also to look from another POV. And I have been see how it’s similar to the fate of other languages which had good elegant ideas, they followed to one concept, abstraction only. This is the way to be marginalized, what happens with a lot of them. Actually, Haskell is already marginal: you can check how many programmers use it in the world, in most statistics it will not exist even. OK, I’m geek, in real life too, but IT industry is not a geek 😊

/Best regards

On Sun, Jul 15, 2018 at 1:28 AM Paul <aquagnu at gmail.com> wrote:
Hello Alex!
 
> A small disclaimer: none of the members of our team has an academic background. We all have different backgrounds: C#, Java, Ruby, Python, C, even Perl if I am not mistaken. Yet we ended up with FP first, and then with Haskell.
> We have switched to Haskell from Scala, which _is_ a multi-paradigm language borrowing bits and pieces from other languages/paradigms and mixing them together. It is an enormously hard work to do it and for that, I very much respect 
 
Oh, my 1st question will be: did you try Eta, Frege? May be I’m wrong but Eta should support Haskell libraries as well as Java ones? They allow you to use libraries from the both world...
 
> As a result, the language becomes overly complicated and less useful.
 
Yes, this is another side. You know, anything has several sides: good and bad...
 
> Your joke about how Haskell has been made misses one point: it was initially designed as a lazy language (at least as far as I know). Many features that Haskell has now are there because of laziness: if you want to be lazy, then you have to be pure, you have to sequence your effects, etc.
 
True. Laziness makes Haskell unique. I think Haskell makes laziness so popular in modern languages although it was known long ago (as data in “infinite streams”, etc). I think, Miranda was lazy, so Haskell is lazy too 😊 And IMHO there was some lazy dialect of ML (may be, I’m not right).
 
> "Let's defer lambda, name it IO and let's call it Monad" -  this bit isn't even funny. Monad isn't IO. IO happens to be a monad (as many things do, List as an example), but monad isn't IO and has nothing to do with IO. A horse is classified as Mammal, but Mammal doesn't mean horse _at all_.
 
Sure. I mean, the need of side-effects (and firstly I/O) led to the monads.
 
> In a context of a lazy language, you need to sequence your effects (including side effects), that's the first point. The second is that instead of disappearing from Haskell, monads (and other concepts) are making their way to other languages. Scala has them, F# has them, even C# has them (however indirectly). Try to take away List Monad from C# developers and they'll kill you ;)
 
Better IMHO to have less infrastructure code. Better is to hide all “machinery” in compiler.
 
My point was that monads are workaround of Haskell problem, this was historically reason of their appearance. And if I have not such limitation in my language I don’t need any monads. What are the monad benefits in ML, for example? They are using in F#, but 1) comp. expressions are not monads but step forward, “monads++” and 2) they play different role in F#: simplifying of the code. And you can avoid them in all languages except Haskell. For example, Prolog can be “pure” and to do I/O without monads, also Clean can as well as F#. Monads have pros, sure, but they are not composable and workaround leads to another workaround – transformers. I’m not unique in my opinion: https://www.youtube.com/watch?v=rvRD_LRaiRs All of this looks like overengineering due to mentioned limitation. No such one in ML, F#. D has keyword “pure”, and didn’t introduce monads. Performance is very important feature of the language, that limitation is the reason #1 why Haskell has bad and unpredictable performance. “do”-block is not the same as “flat” block of C# statements and its performance is not the same. I can achieve Maybe effect with nullable+exceptions or ?-family operators, List with permutations/LINQ, guard with if+break/continue and to do it without sacrificing performance.. ListT/conduits – are just generators/enumerators. Benefit of monads IMHO is small, they are workaround of Haskell problem and are not needed in other languages. Sure, there are monads in Ocaml, Javascript, Python (as experimental libraries), but the reason is hype. Nobody will remember them after 5-10 years... 
 
Actually this is very-very subjective IMHHHHO 😊
 
> Lenses and generic lenses help, so be it. But I don't think that anything prevents Haskell from having it, and I don't think that Haskell as a language needs a dramatic change as you depict to make it happen. Just a feature.
 
When I have legacy code, there are a lot of types which fields are not starting with “_” prefix, so I need to create lenses explicitly... “Infrastructure” code. What is the business value of such code: nothing. For non-Haskell programmer it looks like you try to solve non-existing problem 😊  (very-very provocative point: all Haskell solutions looks very overengineering. The reason is: lambda-abstraction-only. When you try to build something big from little pieces then the process will be very overengineering. Imagine that the pyramids are built of small bricks).
 
> I don't agree that operators are noise. You certainly can write Haskell almost without operators if you wish.
 
Here I’m agree with D. Knuth ideas of literature programming: if code can not be easy read and understand on the hard-copy then used language is not fine. Haskell code needs help from IDE, types hints, etc. And I often meet a case when somebody does not understand what monads are in “do” blocks. Also there are a lot of operators in different libraries and no way to know what some operator means (different libraries, even different versions have own set of operators). 
 
> As for extensions, I think that many more should be just switched on by default.
 
+1
 
> You mean that conversion should happen implicitly? Thank you, but no, thank you. This is a source of problems in many languages, and it is such a great thing that Haskell doesn't coerce types implicitly. 
 
No... Actually, I have not idea what is better. Currently there are a lot of conversions. Some libraries functions expect String, another - Text, also ByteString, lazy/strict, the same with the numbers (word/int/integer). So, conversions happen often.
 
> I don't understand this "no business value" statement. Value for which business? What does it mean "check types, no business value"? 
There are libraries which nothing do in run-time. Only types playing. Only abstractions over types. And somebody says: oh man, see how many libraries has Haskell. But you can compare libraries of Haskell, Java, C#, Javascript, Perl, Python 😊 All libraries of Java, Python... have business value. Real-world functionality. Not abstract play with types. But more important point is a case with installed Agda 😊 or alternative libraries which does the same/similar things. The reason is important: Haskell moves a lot of functionality to libraries which is not good design IMHO. This is the root of the problem. Better is to have one good solid library bundled with GHC itself (“batteries included”) and only specific things will live in libraries and frameworks. Monads and monads transformers are central thing in Haskell. They a located in libraries. There is standard parser combinators in GHC itself, but you will have in the same project another one (or more than 1!). Etc, etc...
 
Also installed GHC... Why is it so big!? IMHO it’s time to clear ecosystem, to reduce it to “batteries” 😊
 
> And then it falls into a famous joke: "The problem with Open Source Software is YOU because YOU are not contributing" :) Meaning that if we want more good libs then we should write more good libs :)
 
Absolutely true 😊
 
On Sat, Jul 14, 2018 at 5:05 PM Paul <aquagnu at gmail.com> wrote:
I understand that my points are disputable, sure, example, multi-pardigm Oz – dead 😊 Any rule has exceptions. But my point was that people don’t like elegant and one-abstraction languages. It’s my observation. For me, Smalltalk was good language (mostly dead, except Pharo, which looks cool). Forth – high-level “stack-around-assembler”, mostly dead (Factor looks abandoned, only 8th looks super cool, but it’s not free). What else? Lisp? OK, there are SBCL, Clojure, Racket... But you don’t find even Clojure in languages trends usually. APL, J – super cool! Seems dead (I don’t know what happens with K). ML, SML? By the way, Haskell role was to kill SML community, sure it is sad to acknowledge it, but it’s 100% true...
 
Haskell try to be minimalistic and IMHO this can lead to death. Joachim, I’m not talking “it’s good/it’s bad”, “multiparadigm is good” or else... I don’t know what is right. It’s my observations only. Looks like it can happen.
 
If we will look to Haskell history then we see strange curve. I’ll try to describe it with humour, so, please, don;t take it seriously 😊 
•       Let’s be pure lambda fanatics!
•       Is it possible to create a big application?
•       Is it possible to compile and optimize it?!
•       Let’s try...
•       Wow, it’s possible!!! (sure, it’s possible, Lisp did it long-long ago).
•       Looks like puzzle, can be used to write a lot of articles (there were articles about combinators, Jay/Cat/Scheme, etc, now there are a lot of Haskell articles – big interesting in academia. But IMHO academia interest to language can kill it too: Clean, Strongtalk, etc)
•       Stop! How to do I/O? Real programming?!!
•       Ohh, if we will wrap it in lambda and defer it to top level (main::IO ()), it will have I/O type (wrapper is hidden in type)
•       Let’s call it... Monad!!
•       Wow, cool! Works! Anybody should use monads! Does not your language have monads? Then we fly to you! (everybody forgot that monads are workaround of Haskell limitation and are not needed in another languages. Also they lead to low-performance code)
•       But how to compose them???!?!
•       We will wrap/unwrap, wrap/unwrap.. Let’s call it... transformers!!! “Monad transformers” – sounds super cool. Your language does not have “lift” operation, right? Ugh...
•       How to access records fields... How... That’s a question. ‘.’ - no! ‘#’ - no! Eureka! We will add several language extensions and voila!
•       To be continued... 😊
 
I love Haskell but I think such curve is absolutely impossible in commercial language. With IT managers 😊 To solve problem in a way when solution leads to another problem which needs new solution again and reason is only to keep lambda-abstraction-only (OK, Vanessa, backpacks also 😉) Can you imagine that all cars will have red color? Or any food will be sweet? It’s not technical question, but psychological and linguistic. Why native languages are not so limited? They even borrow words and forms from another one 😊 
 
Haskell’s core team knows how better then me, and I respect a lot of Haskell users, most of them helped me A LOT (!!!). It’s not opinion even, because I don’t know what is a right way. Let’s call it observation and feeling of the future.
 
I feel: Haskell has 3 cases: 1) to die 2) to change itself 3) to fork to another language
How I see commercial successful Haskell-like language:
•       No monads, no transformers
•       There are dependent types, linear types
•       There are other evaluation models/abstractions (not only lambda)
•       Special syntax for records fields, etc
•       Less operators noise, language extensions (but it’s very disputable)
•       Solve problems with numerous from/to conversions (strings, etc)
•       Solve problems with libraries
 
Last point needs explanation:
•       There is a lot of libraries written to check some type concepts only, no any business value. Also there are a lot of libraries written by students while they are learning Haskell: mostly without any business value/abandoned
•       There is situation when you have alternative libraries in one project due to dependencies (but should be one only, not both!)
•       Strange dependencies: I have installed Agda even! Why???!
 
IMHO problems with libraries and lambda-only-abstraction lead to super slow compilation, big and complex compiler.
So, currently I see (again, it’s my observation only) 2 big “camps”:
1.       Academia, which has own interests, for example, to keep Haskell minimalistic (one-only-abstraction). Trade-off only was to add language extensions but they fragmentizes the language
2.       Practical programmers, which interests are different from 1st “camp”
 
Another my observation is: a lot of peoples tried Haskell and switched to another languages (C#, F#, etc) because they cannot use it for big enterprise projects (Haskell becomes hobby for small experiments or is dropped off).
 
Joachim, I’m absolutely agreed that a big company can solve a lot of these problems. But some of them have already own languages (you can compare measure units in Haskell and in F#, what looks better...).
 
When I said about killer app, I mean: devs like Ruby not due to syntax but RoR. The same Python: sure, Python syntax is very good, but without Zope, Django, TurboGears, SQLAlchemy, Twisted, Tornado, Cheetah, Jinja, etc – nobody will use Python. Sure, there are exceptions: Delphi, CBuilder, for example. But this is bad karma of Borland 😊 They had a lot of compilers (pascal, prolog, c/c++, etc), but... On the other hand after reincarnation we have C# 😊  Actually all these are only observations: nobody knows the future.
 
 
/Best regards, Paul
 
From: Joachim Durchholz
Sent: 13 июля 2018 г. 21:49
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)
 
Am 13.07.2018 um 09:38 schrieb PY:
> 1. Haskell limits itself to lambda-only. Example, instead to add other 
> abstractions and to become modern MULTI-paradigm languages,
 
"modern"?
That's not an interesting property.
"maintainable", "expressive" - THESE are interesting. Multi-paradigm can 
help, but if overdone can hinder it - the earliest multi-paradigm 
language I'm aware of was PL/I, and that was a royal mess I hear.
 
> So, point #1 is limitation in 
> abstraction: monads, transformers, anything - is function. It's not 
> good.
 
Actually limiting yourself to a single abstraciton tool can be good. 
This simplifies semantics and makes it easier to build stuff on top of it.
 
Not that I'm saying that this is necessarily the best thing.
 
> There were such languages already: Forth, Joy/Cat, APL/J/K... Most of
> them look dead.
Which proves nothing, because many multi-paradigm languages look dead, too.
 
> When you try to be elegant, your product (language) died.
Proven by Lisp... er, disproven.
 
> This is not my opinion, this is only my observation. People like 
> diversity and variety: in food, in programming languages, in relations, 
> anywhere :)
 
Not in programming languages.
Actually multi-paradigm is usually a bad idea. It needs to be done in an 
excellent fashion to create something even remotely usable, while a 
single-paradigm language is much easier to do well.
And in practice, bad language design has much nastier consequences than 
leaving out some desirable feature.
 
> 2. When language has killer app and killer framework, IMHO it has more 
> chances. But if it has _killer ideas_ only... So, those ideas will be 
> re-implemented in other languages and frameworks but with more simple 
> and typical syntax :)
 
"Typical" is in the eye of the beholder, so that's another non-argument.
 
> It's difficult to compete with product, 
> framework, big library, but it's easy to compete with ideas. It's an 
> observation too :-)
 
Sure, but Haskell has product, framework, big library.
What's missing is commitment by a big company, that's all. Imagine 
Google adopting Haskell, committing to building libraries and looking 
for Haskell programmers in the streets - all of a sudden, Haskell is 
going to be the talk of the day. (Replace "Google" with whatever 
big-name company with deep pockets: Facebook, MS, IBM, you name it.)
 
> language itself is not argument for me.
 
You are arguing an awful lot about missing language features 
("multi-paradigm") to credibly make that statement.
 
> Argument for me (I 
> am usual developer) are killer apps/frameworks/libraries/ecosystem/etc. 
> Currently Haskell has stack only - it's very good, but most languages 
> has similar tools (not all have LTS analogue, but big frameworks are the 
> same).
 
Yeah, a good library ecosystem is very important, and from the reports I 
see on this list it's not really good enough.
The other issue is that Haskell's extensions make it more difficult to 
have library code interoperate. Though that's a trade-off: The freedom 
to add language features vs. full interoperability. Java opted for the 
other opposite: 100% code interoperability at the cost of a really 
annoying language evolution process, and that gave it a huge library 
ecosystem.
 
But... I'm not going to make the Haskell developers' decisions. If they 
don't feel comfortable with reversing the whole culture and make 
interoperability trump everything else, then I'm not going to blame 
them. I'm not even going to predict anything about Haskell's future, 
because my glass orb is out for repairs and I cannot currently predict 
the future.
 
Regards,
Jo
_______________________________________________
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/20180715/ae866ef9/attachment-0001.html>

From blaze at ruddy.ru  Sun Jul 15 16:24:26 2018
From: blaze at ruddy.ru (Olga Ershova)
Date: Sun, 15 Jul 2018 12:24:26 -0400
Subject: [Haskell-cafe] Investing in languages (Was: What
 isyourfavouriteHaskell "aha" moment?)
In-Reply-To: <5b4b7121.1c69fb81.7668.0525@mx.google.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
 <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
 <5b4b7121.1c69fb81.7668.0525@mx.google.com>
Message-ID: <CALujEfi3etB9iuwG7-L_DLg12VUQ=G0v=Co4tjH8iyO_VURQSA@mail.gmail.com>

If you get large D program and remove all "pure" annotations from it, it
will not become buggy _immediatelly_. But its chance to become buggy after
a few changes will increase dramatically.

Constraints and forced purity in Haskell are tools allowing one to design
safe programs, to let compiler catch your (or junior intern's) hand before
bug is introduced. And I agree with Alexey, lack of ability to express
"never ever this branch of code should change anything outside" is a big
problem in majority of type systems.

On Sun, Jul 15, 2018, 12:07 Paul <aquagnu at gmail.com> wrote:

>
>    - Eta does. Through a very nice FFI. But so does Haskell. We have nice
>    FFI to use C libs. I maintain a couple of libs that use it extensively,
>    works quite well.
>
>
>
> I asked because never tried Eta. So, if you are right, seems no reasons to
> develop Eta...
>
>
>
>    - Can I have a definition and laws of "monad++"? Otherwise, I don't
>    understand what you are talking about. If it obeys monadic laws it is a
>    monad. But I'll wait for the definition.
>
>
>
> No better definition then original:
> https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions
> You see, they are different.
>
>
>
>    - But it is not lazy - one. Remember, laziness is our requirement
>    here. Whatever you propose _must _ work in a context of laziness.
>
>
>
> Does it mean because Haskell is lazy (Clean – not) then linear types are
> impossible in Haskell? If they are possible why we need monads?
>
>
>
>    - Second, the inability to track side effects in F# is not
>    "simplification" and is not a benefit, but rather a limitation and a
>    disadvantage of the language and its type system.
>
> Why?
>
>
>
> Haskell “tracks” effects obviously. But I shown example with State monad
> already. As I saw, nobody understand that State monad does not solve
> problem of spaghetti-code style manipulation with global state. Even more,
> it masks problem. But it was solved in OOP when all changes of state happen
> in *one place* under FSM control (with explicit rules of denied
> transitions: instead of change you have *a request to change*/a message,
> which can fail if transition is denied). Haskell HAS mutable structures,
> side-effects and allows spaghetti-code.  But magical word “monad” allows to
> forget about problem and the real solution and to lie that no such problem
> at whole (it automatically solved due to magical safety of Haskell). Sure,
> you can do it in Haskell too, but Haskell does not force you, but
> Smalltalk, for example, forces you.
>
>
>
> We often repeat this: “side-effects”, “tracks”, “safe”. But what does it
> actually mean? Can I have side-effects in Haskell? Yes. Can I mix
> side-effects? Yes. But in more difficult way than in ML or F#, for example.
> What is the benefit? Actually no any benefit, it’s easy understandable with
> simple experiment: if I have a big D program and I remove all “pure”
> keywords, will it become automatically buggy? No. If I stop to use “pure”
> totally, will it become buggy? No. If I add “print” for debug purpose in
> some subroutines, will they become buggy? No. If I mix read/write effects
> in my subroutine, will it make it buggy? No.
>
>
>
> IMHO there is some substitution of concepts. Monads roots are not safety,
> but workaround to have effects in pure lambdas. And *after* monads
> introduction, a thesis was appeared: “monads make code more safe”.
> Motivation of monads was not to track effect (because it’s allegedly more
> safe), but to inject/allow/introduce effects in language like Haskell. Good
> example is State monad, again. State monad is needed to support
> manipulation of state (through argument replacement in chain of lambdas)
> but it’s totally other thing in comparison with idea to separate state
> manipulation in one isolated place under control of some FSM with explicit
> rules of allowed and denied transitions. If I am switching from read monad
> to RWST monad, will my code be more buggy? Again, no. Monads don’t decrease
> buggy or global-state-manipulation problems automatically, they are
> workaround for specific Haskell problem. Other languages don’t need monads.
> I CAN have monads in Python, Javascript but I don’t need them. My point is:
> monads are not valuable byself: Ocaml has not any monads and all is fine
> 😊
>
>
>
> But it’s really very philosophical question, I think that monads are
> over-hyped actually. I stopped seeing the value of monads by themselves.
>
>
>
>    - Third, AFAIK CLR restrictions do not allow implementing things like
>    Functor, Monad, etc. in F# directly because they can't support HKT. So they
>    workaround the problem.
>
>
>
> https://fsprojects.github.io/FSharpPlus/abstractions.html (btw, you can
> see that monad is monoid here 😉)
>
>
>
>    - But again, F# cannot be expressive enough: no HKT, no ability to
>    express constraints, no ability to track effects...
>
>
>
> If F# has monads (you call “monads” to computational expressions), then it
> CAN...
>
> About HKT: yes, that’s true. But may be, it’s not so big problem? May be
> you can write effective, good and expressive code without them? Otherwise,
> we should agree that all languages without HKT are not expressive...
>
>
>
>    - Really?  You keep mentioning F#, and I struggle with it right now
>    _because_ of such limitations. There are no meaningful ways abstract over
>    generics, it is impossible to reason about functions' behaviours from their
>    type signatures (because side effects can happen anywhere), it has Option,
>    but you still can get Null, you can't have constraints, etc., etc. It is
>    sooooo muuuuch mooore limited.
>
>
>
> IMHO fear of “side effects can happen anywhere” becomes traditional
> thesis. And what is the problem if I add “print” in some function?! 😊
> Again, substitution of concepts, of monad’s motivations. Haskell compiler
> can not transform code with side-effects in effective way, and I must
> isolate all side-effects, mark such functions, but this is the problem of
> Haskell compiler, not mine. Why programmer should help compiler?! You can
> look at MLTon compiler, or OCaml one. IMHO they are good and work fine with
> side-effects; programs WITH side-effects under RWST or State or without
> those monads in ML are equal: if I port 101 ML functions with side-effects
> to Haskell, then I will add monad and will have 101 functions with the same
> side-effects, but now under monad. I can propagate my monad anywhere 😊
> All my functions can be under RWST or State. Again, this problem should be
> solved in other way, not by wrapping the same actions in some wrapper-type
> (monad). A funny consequence of this, now my program become deep nested
> lambdas. Compiler should try to “flat” some of them, but I am not competent
> how Haskell good in it. Anyway, performance will be worse than in ML
> version. But focus here is a mark-with-monad-type, not the avoid
> side-effects. And it’s needed for compiler, not for me. May be I’m not
> clean, may be it is heavy to accept to the people hypnotized by magic
> invocations about monads power, may be I don’t understand something 😊
>
>
>
>    - No, you can't.
>
>
>
> Something like this:   user?.Phone?.Company?.Name??"missing";     ?
>
>
>
> (do
>
>   u <- mbUser
>
>    ph <- phoneOf u
>
>    ...) <|> pure “missing”
>
>
>
>    - OCaml exists for 22 years now, doing well and solves problems it has
>    been designed for very well. So _already_ more than twice compare to your
>    prediction.
>
>
>
> It’s Ocaml. It follows to the golden middle, to avoid danger corner 😉
>
>
>
>    - fields are not starting with “_” prefix, so I need to create lenses
>    explicitly
>
>
>    - No you don't. You don't have to have "_" prefix to generate a lense.
>    You have total control here.
>
>
>
> Hmm, may be I’m not right. I’m using microlenses and call
> `makeLensesFor`...
>
>
>
>    - Can you define "business value" please? You mention it for a couple
>    of times, so I am puzzled. Otherwise, it reminds me of
>    https://twitter.com/newhoggy/status/999930802589724672
>
>
>    - For Haskell programmers, Java solves non-existing problems all the
>    time :) Every single time you see on twitter or here something like "I
>    replaced hundreds of lines of Java code with a single 'traverse'" you get
>    the proof. And it happens so often.
>
>
>
> It involves a long talk 😉 Business value - I’ll illustrate it, imagine a
> code:
>
>
>
> .... lift ....   – *NO business value in lift! It’s infrastructure code*
>
> m <- loadModel “mymodel.bin” – *there is business value*
>
> checkModel m rules – *there is business value too*
>
>
>
> So, I can mark infrastructure code with red color, business code with
> green and to calculate ratio. And to talk about “usefulness/effectivity” of
> language. How many infrastructure noise have the language (Java, btw, IMHO
> will have bad ratio too). I have a tons of types, JSON to/from instances, -
> I repeat models which are coded in external 3rd part services. But F#
> team thinks like me: it’s not enterprise way to do things in such manner
> and they introduced types providers – it’s only small example. In Haskell I
> wrote a lot of infrastructure code, different instances, etc, etc. But
> other languages are more concentrated on business value, on domain, on
> business logic. I though about DSLs, but DSLs can be antipattern and to
> lead to other problems...
>
>
>
>    - Haskell code needs help from IDE, types hints, etc.
>    - Types are written and read by programmers. Java is impossible
>    without IDE.  What is the point here?
>
>
>
> Usually it’s difficult to understand for programmers. Most say: Perl looks
> like sh*t. Just look at these %, $, etc. And they don’t understand simple
> thesis: language is about humans, about linguistic, not about computation.
> Language should not be oriented to compiler or to its computational model,
> how will you like to work with bytes and words only in C++? So, we have
> “a”, “the” in English, we have “%”, “$” in Perl. And I don’t know exact
> object “type” but I can imagine its nature, it’s scalar, vector, etc. In
> Haskell I can skip most signatures and such code is not readable, I need
> Intero help to check some types. It’s very bad situation. It’s not 100%
> true for Java because you will have signatures in Java, you can not skip
> them, right? And if I add operators noise also (when I have not idea what
> does this ASCII-art do), the code becomes IDE-centric.
>
>
>
>    - Better for whom? Definitely NOT better for me and my team using
>    Haskell commercially. Again, to effectively meet requirements, functional
>    and non-functional, we don't want just a mediocre compromise thing. I gave
>    you an example with parsers already: different parsers have different
>    tradeoffs. It is often a GOOD thing that there are many different libraries
>    doing the same thing differently.
>
>
>
> Hm, if I have several libraries which are  doing similar things (only due
> to dependencies), then I have: 1) big Haskell installation (1Gb?) 2) slow
> compilation 3) big binaries, etc. I understand, you have freedom of choice.
> But let’s look to IT: C++ turned to one library (imported some Boost
> solutions, etc, etc), the same R7RS, D with its Phobos, Ocaml has batteries
> from Jane str., Python 😊 IMHO its general trend. Let’s imagine: project
> with 2, 3 parsers libraries, conduit and pipes, etc, due to dependencies.
> So, IMHO my point is not so strange or weird 😉 I’m talking about drop
> off those libraries (parsers, etc), but about creating of one solid library
> which components will depends only on it. Other alternatives will be
> somewhere in repos, who want, can use them without any problems. Something
> like Qt, Boost, Gtk, etc.
>
>
>
> Let me be more precise, I’m comfort with Haskell at whole, but 1) I
> discussed Haskell with other people 2) I read opinion of other people in
> industry 2) I’m programmer since 97 and I have critical kind of the mind,
> so all of these allows me also to look from another POV. And I have been
> see how it’s similar to the fate of other languages which had good elegant
> ideas, they followed to one concept, abstraction only. This is the way to
> be marginalized, what happens with a lot of them. Actually, Haskell is
> already marginal: you can check how many programmers use it in the world,
> in most statistics it will not exist even. OK, I’m geek, in real life too,
> but IT industry is not a geek 😊
>
>
>
> /Best regards
>
>
>
> On Sun, Jul 15, 2018 at 1:28 AM Paul <aquagnu at gmail.com> wrote:
>
> Hello Alex!
>
>
>
> > A small disclaimer: none of the members of our team has an academic
> background. We all have different backgrounds: C#, Java, Ruby, Python, C,
> even Perl if I am not mistaken. Yet we ended up with FP first, and then
> with Haskell.
>
> > We have switched to Haskell from Scala, which _is_ a multi-paradigm
> language borrowing bits and pieces from other languages/paradigms and
> mixing them together. It is an enormously hard work to do it and for that,
> I very much respect
>
>
>
> Oh, my 1st question will be: did you try Eta, Frege? May be I’m wrong but
> Eta should support Haskell libraries as well as Java ones? They allow you
> to use libraries from the both world...
>
>
>
> > As a result, the language becomes overly complicated and less useful.
>
>
>
> Yes, this is another side. You know, anything has several sides: good and
> bad...
>
>
>
> > Your joke about how Haskell has been made misses one point: it was
> initially designed as a lazy language (at least as far as I know). Many
> features that Haskell has now are there because of laziness: if you want to
> be lazy, then you have to be pure, you have to sequence your effects, etc.
>
>
>
> True. Laziness makes Haskell unique. I think Haskell makes laziness so
> popular in modern languages although it was known long ago (as data in
> “infinite streams”, etc). I think, Miranda was lazy, so Haskell is lazy too
> 😊 And IMHO there was some lazy dialect of ML (may be, I’m not right).
>
>
>
> > "Let's defer lambda, name it IO and let's call it Monad" -  this bit
> isn't even funny. Monad isn't IO. IO happens to be a monad (as many things
> do, List as an example), but monad isn't IO and has nothing to do with IO.
> A horse is classified as Mammal, but Mammal doesn't mean horse _at all_.
>
>
>
> Sure. I mean, the need of side-effects (and firstly I/O) led to the monads.
>
>
>
> > In a context of a lazy language, you need to sequence your effects
> (including side effects), that's the first point. The second is that
> instead of disappearing from Haskell, monads (and other concepts) are
> making their way to other languages. Scala has them, F# has them, even C#
> has them (however indirectly). Try to take away List Monad from C#
> developers and they'll kill you ;)
>
>
>
> Better IMHO to have less infrastructure code. Better is to hide all
> “machinery” in compiler.
>
>
>
> My point was that monads are workaround of Haskell problem, this was
> historically reason of their appearance. And if I have not such limitation
> in my language I don’t need any monads. What are the monad benefits in ML,
> for example? They are using in F#, but 1) comp. expressions are not monads
> but step forward, “monads++” and 2) they play different role in F#:
> simplifying of the code. And you *can* avoid them in all languages except
> Haskell. For example, Prolog can be “pure” and to do I/O without monads,
> also Clean can as well as F#. Monads have pros, sure, but they are not
> composable and workaround leads to another workaround – transformers. I’m
> not unique in my opinion: https://www.youtube.com/watch?v=rvRD_LRaiRs All
> of this looks like overengineering due to mentioned limitation. No such one
> in ML, F#. D has keyword “pure”, and didn’t introduce monads. Performance
> is very important feature of the language, that limitation is the reason #1
> why Haskell has bad and unpredictable performance. “do”-block is not the
> same as “flat” block of C# statements and its performance is not the same.
> I can achieve Maybe effect with nullable+exceptions or ?-family operators,
> List with permutations/LINQ, guard with if+break/continue and to do it
> without sacrificing performance.. ListT/conduits – are just
> generators/enumerators. Benefit of monads IMHO is small, they are
> workaround of Haskell problem and are not needed in other languages. Sure,
> there are monads in Ocaml, Javascript, Python (as experimental libraries),
> but the reason is hype. Nobody will remember them after 5-10 years...
>
>
>
> Actually this is very-very subjective IMHHHHO 😊
>
>
>
> > Lenses and generic lenses help, so be it. But I don't think that
> anything prevents Haskell from having it, and I don't think that Haskell as
> a language needs a dramatic change as you depict to make it happen. Just a
> feature.
>
>
>
> When I have legacy code, there are a lot of types which fields are not
> starting with “_” prefix, so I need to create lenses explicitly...
> “Infrastructure” code. What is the business value of such code: nothing.
> For non-Haskell programmer it looks like you try to solve non-existing
> problem 😊  (*very-very provocative point: all Haskell solutions looks
> very overengineering. The reason is: lambda-abstraction-only. When you try
> to build something big from little pieces then the process will be very
> overengineering. Imagine that the pyramids are built of small bricks*).
>
>
>
> > I don't agree that operators are noise. You certainly can write Haskell
> almost without operators if you wish.
>
>
>
> Here I’m agree with D. Knuth ideas of literature programming: if code can
> not be easy read and understand on the hard-copy then used language is not
> fine. Haskell code needs help from IDE, types hints, etc. And I often meet
> a case when somebody does not understand what monads are in “do” blocks.
> Also there are a lot of operators in different libraries and no way to know
> what some operator means (different libraries, even different versions have
> own set of operators).
>
>
>
> > As for extensions, I think that many more should be just switched on by
> default.
>
>
>
> +1
>
>
>
> > You mean that conversion should happen implicitly? Thank you, but no,
> thank you. This is a source of problems in many languages, and it is such a
> great thing that Haskell doesn't coerce types implicitly.
>
>
>
> No... Actually, I have not idea what is better. Currently there are a lot
> of conversions. Some libraries functions expect String, another - Text,
> also ByteString, lazy/strict, the same with the numbers (word/int/integer).
> So, conversions happen often.
>
>
>
> > I don't understand this "no business value" statement. Value for which
> business? What does it mean "check types, no business value"?
>
> There are libraries which nothing do in run-time. Only types playing. Only
> abstractions over types. And somebody says: oh man, see how many libraries
> has Haskell. But you can compare libraries of Haskell, Java, C#,
> Javascript, Perl, Python 😊 All libraries of Java, Python... have
> business value. Real-world functionality. Not abstract play with types. But
> more important point is a case with installed Agda 😊 or alternative
> libraries which does the same/similar things. The reason is important:
> Haskell moves a lot of functionality to libraries which is not good design
> IMHO. This is the root of the problem. Better is to have one good solid
> library bundled with GHC itself (“batteries included”) and only specific
> things will live in libraries and frameworks. Monads and monads
> transformers are central thing in Haskell. They a located in libraries.
> There is standard parser combinators in GHC itself, but you will have in
> the same project another one (or more than 1!). Etc, etc...
>
>
>
> Also installed GHC... Why is it so big!? IMHO it’s time to clear
> ecosystem, to reduce it to “batteries” 😊
>
>
>
> > And then it falls into a famous joke: "The problem with Open Source
> Software is YOU because YOU are not contributing" :) Meaning that if we
> want more good libs then we should write more good libs :)
>
>
>
> Absolutely true 😊
>
>
>
> On Sat, Jul 14, 2018 at 5:05 PM Paul <aquagnu at gmail.com> wrote:
>
> I understand that my points are disputable, sure, example, multi-pardigm
> Oz – dead 😊 Any rule has exceptions. But my point was that people don’t
> like elegant and one-abstraction languages. It’s my observation. For me,
> Smalltalk was good language (mostly dead, except Pharo, which looks cool).
> Forth – high-level “stack-around-assembler”, mostly dead (Factor looks
> abandoned, only 8th looks super cool, but it’s not free). What else?
> Lisp? OK, there are SBCL, Clojure, Racket... But you don’t find even
> Clojure in languages trends usually. APL, J – super cool! Seems dead (I
> don’t know what happens with K). ML, SML? By the way, Haskell role was to
> kill SML community, sure it is sad to acknowledge it, but it’s 100% true...
>
>
>
> Haskell try to be minimalistic and IMHO this can lead to death. Joachim,
> I’m not talking “it’s good/it’s bad”, “multiparadigm is good” or else... I
> don’t know what is right. It’s my observations only. Looks like it can
> happen.
>
>
>
> If we will look to Haskell history then we see strange curve. I’ll try to
> describe it with humour, so, please, don;t take it seriously 😊
>
> ·       Let’s be pure lambda fanatics!
>
> ·       Is it possible to create a big application?
>
> ·       Is it possible to compile and optimize it?!
>
> ·       Let’s try...
>
> ·       Wow, it’s possible!!! (sure, it’s possible, Lisp did it long-long
> ago).
>
> ·       Looks like puzzle, can be used to write a lot of articles (there
> were articles about combinators, Jay/Cat/Scheme, etc, now there are a lot
> of Haskell articles – big interesting in academia. But IMHO academia
> interest to language can kill it too: Clean, Strongtalk, etc)
>
> ·       Stop! How to do I/O? Real programming?!!
>
> ·       Ohh, if we will wrap it in lambda and defer it to top level
> (main::IO ()), it will have I/O type (wrapper is hidden in type)
>
> ·       Let’s call it... Monad!!
>
> ·       Wow, cool! Works! Anybody should use monads! Does not your
> language have monads? Then we fly to you! (everybody forgot that monads are
> workaround of Haskell limitation and are not needed in another languages.
> Also they lead to low-performance code)
>
> ·       But how to compose them???!?!
>
> ·       We will wrap/unwrap, wrap/unwrap.. Let’s call it...
> transformers!!! “Monad transformers” – sounds super cool. Your language
> does not have “lift” operation, right? Ugh...
>
> ·       How to access records fields... How... That’s a question. ‘.’ -
> no! ‘#’ - no! Eureka! We will add several language extensions and voila!
>
> ·       To be continued... 😊
>
>
>
> I love Haskell but I think such curve is absolutely impossible in
> commercial language. With IT managers 😊 To solve problem in a way when
> solution leads to another problem which needs new solution again and reason
> is only to keep lambda-abstraction-only (OK, Vanessa, backpacks also 😉)
> Can you imagine that all cars will have red color? Or any food will be
> sweet? It’s not technical question, but psychological and linguistic. Why
> native languages are not so limited? They even borrow words and forms from
> another one 😊
>
>
>
> Haskell’s core team knows how better then me, and I respect a lot of
> Haskell users, most of them *helped me A LOT* (!!!). It’s not opinion
> even, because I don’t know what is a right way. Let’s call it observation
> and feeling of the future.
>
>
>
> I feel: Haskell has 3 cases: 1) to die 2) to change itself 3) to fork to
> another language
>
> How I see commercial successful Haskell-like language:
>
> ·       No monads, no transformers
>
> ·       There are dependent types, linear types
>
> ·       There are other evaluation models/abstractions (not only lambda)
>
> ·       Special syntax for records fields, etc
>
> ·       Less operators noise, language extensions (but it’s very
> disputable)
>
> ·       Solve problems with numerous from/to conversions (strings, etc)
>
> ·       Solve problems with libraries
>
>
>
> Last point needs explanation:
>
> ·       There is a lot of libraries written to check some type concepts
> only, no any business value. Also there are a lot of libraries written by
> students while they are learning Haskell: mostly without any business
> value/abandoned
>
> ·       There is situation when you have alternative libraries in one
> project due to dependencies (but should be one only, not both!)
>
> ·       Strange dependencies: I have installed Agda even! Why???!
>
>
>
> IMHO problems with libraries and lambda-only-abstraction lead to super
> slow compilation, big and complex compiler.
>
> So, currently I see (again, it’s my observation only) 2 big “camps”:
>
> 1.       Academia, which has own interests, for example, to keep Haskell
> minimalistic (one-only-abstraction). Trade-off only was to add language
> extensions but they fragmentizes the language
>
> 2.       Practical programmers, which interests are different from 1st
> “camp”
>
>
>
> Another my observation is: a lot of peoples tried Haskell and switched to
> another languages (C#, F#, etc) because they cannot use it for big
> enterprise projects (Haskell becomes hobby for small experiments or is
> dropped off).
>
>
>
> Joachim, I’m absolutely agreed that a big company can solve a lot of these
> problems. But some of them have already own languages (you can compare
> measure units in Haskell and in F#, what looks better...).
>
>
>
> When I said about killer app, I mean: devs like Ruby not due to syntax but
> RoR. The same Python: sure, Python syntax is very good, but without Zope,
> Django, TurboGears, SQLAlchemy, Twisted, Tornado, Cheetah, Jinja, etc –
> nobody will use Python. Sure, there are exceptions: Delphi, CBuilder, for
> example. But this is bad karma of Borland 😊 They had a lot of compilers
> (pascal, prolog, c/c++, etc), but... On the other hand after reincarnation
> we have C# 😊  Actually all these are only observations: nobody knows the
> future.
>
>
>
>
>
> /Best regards, Paul
>
>
>
> *From: *Joachim Durchholz <jo at durchholz.org>
> *Sent: *13 июля 2018 г. 21:49
> *To: *haskell-cafe at haskell.org
> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
> yourfavourite Haskell "aha" moment?)
>
>
>
> Am 13.07.2018 um 09:38 schrieb PY:
>
> > 1. Haskell limits itself to lambda-only. Example, instead to add other
>
> > abstractions and to become modern MULTI-paradigm languages,
>
>
>
> "modern"?
>
> That's not an interesting property.
>
> "maintainable", "expressive" - THESE are interesting. Multi-paradigm can
>
> help, but if overdone can hinder it - the earliest multi-paradigm
>
> language I'm aware of was PL/I, and that was a royal mess I hear.
>
>
>
> > So, point #1 is limitation in
>
> > abstraction: monads, transformers, anything - is function. It's not
>
> > good.
>
>
>
> Actually limiting yourself to a single abstraciton tool can be good.
>
> This simplifies semantics and makes it easier to build stuff on top of it.
>
>
>
> Not that I'm saying that this is necessarily the best thing.
>
>
>
> > There were such languages already: Forth, Joy/Cat, APL/J/K... Most of
>
> > them look dead.
>
> Which proves nothing, because many multi-paradigm languages look dead, too.
>
>
>
> > When you try to be elegant, your product (language) died.
>
> Proven by Lisp... er, disproven.
>
>
>
> > This is not my opinion, this is only my observation. People like
>
> > diversity and variety: in food, in programming languages, in relations,
>
> > anywhere :)
>
>
>
> Not in programming languages.
>
> Actually multi-paradigm is usually a bad idea. It needs to be done in an
>
> excellent fashion to create something even remotely usable, while a
>
> single-paradigm language is much easier to do well.
>
> And in practice, bad language design has much nastier consequences than
>
> leaving out some desirable feature.
>
>
>
> > 2. When language has killer app and killer framework, IMHO it has more
>
> > chances. But if it has _killer ideas_ only... So, those ideas will be
>
> > re-implemented in other languages and frameworks but with more simple
>
> > and typical syntax :)
>
>
>
> "Typical" is in the eye of the beholder, so that's another non-argument.
>
>
>
> > It's difficult to compete with product,
>
> > framework, big library, but it's easy to compete with ideas. It's an
>
> > observation too :-)
>
>
>
> Sure, but Haskell has product, framework, big library.
>
> What's missing is commitment by a big company, that's all. Imagine
>
> Google adopting Haskell, committing to building libraries and looking
>
> for Haskell programmers in the streets - all of a sudden, Haskell is
>
> going to be the talk of the day. (Replace "Google" with whatever
>
> big-name company with deep pockets: Facebook, MS, IBM, you name it.)
>
>
>
> > language itself is not argument for me.
>
>
>
> You are arguing an awful lot about missing language features
>
> ("multi-paradigm") to credibly make that statement.
>
>
>
> > Argument for me (I
>
> > am usual developer) are killer apps/frameworks/libraries/ecosystem/etc.
>
> > Currently Haskell has stack only - it's very good, but most languages
>
> > has similar tools (not all have LTS analogue, but big frameworks are the
>
> > same).
>
>
>
> Yeah, a good library ecosystem is very important, and from the reports I
>
> see on this list it's not really good enough.
>
> The other issue is that Haskell's extensions make it more difficult to
>
> have library code interoperate. Though that's a trade-off: The freedom
>
> to add language features vs. full interoperability. Java opted for the
>
> other opposite: 100% code interoperability at the cost of a really
>
> annoying language evolution process, and that gave it a huge library
>
> ecosystem.
>
>
>
> But... I'm not going to make the Haskell developers' decisions. If they
>
> don't feel comfortable with reversing the whole culture and make
>
> interoperability trump everything else, then I'm not going to blame
>
> them. I'm not even going to predict anything about Haskell's future,
>
> because my glass orb is out for repairs and I cannot currently predict
>
> the future.
>
>
>
> Regards,
>
> Jo
>
> _______________________________________________
>
> Haskell-Cafe mailing list
>
> To (un)subscribe, modify options or view archives go to:
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> Only members subscribed via the mailman list are allowed to post.
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180715/9437d717/attachment-0001.html>

From jo at durchholz.org  Sun Jul 15 17:08:34 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 15 Jul 2018 19:08:34 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What
 isyourfavouriteHaskell "aha" moment?)
In-Reply-To: <5b4b7121.1c69fb81.7668.0525@mx.google.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
 <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
 <5b4b7121.1c69fb81.7668.0525@mx.google.com>
Message-ID: <6055d12c-ac58-17fa-6846-61f904f00e5e@durchholz.org>

Am 15.07.2018 um 18:06 schrieb Paul:
>   * But it is not lazy - one. Remember, laziness is our requirement
>     here. Whatever you propose _must _ work in a context of laziness.
> 
> Does it mean because Haskell is lazy (Clean – not) then linear types are 
> impossible in Haskell?

Laziness and linear types are orthogonal.

 > If they are possible why we need monads?

"Monadic" as a term is at the same level as "associative".
A very simple concept that is visible everywhere, and if you can arrange 
your computations in a monadic manner you'll get a certain level of 
sanity. And lo and behold, you can even write useful libraries just 
based on the assumption that you're dealing with monadic structures, 
that's monad transformers (so they're more interesting than associativity).

So monads are interesting and useful (read: important) regardless of 
whether you have laziness or linear types.
Again: orthogonal.

> Haskell “tracks” effects obviously. But I shown example with State monad 
> already. As I saw, nobody understand that State monad does not solve 
> problem of spaghetti-code style manipulation with global state.

Actually that's pretty well-known.
Not just for State for for anything that hides state out of plain sight, 
i.e. somewhere else than in function parameters. I.e. either some struct 
type, or by returning a partially evaluated function that has that data.
People get bitten by those things, and they learn to avoid these 
patterns except where it's safe - just as with spaghetti code, which 
people stopped writing a few years ago (nowadays it's more spaghetti 
data but at least that's analyzable).

So I think if you don't see anybody explicitly mentioning spaghetti 
issues with State that's for some people it's just hiding in plain sight 
and they either aren't consciously aware of it, or find that area so 
self-explaining that they do not think they really need to explain that.

Or you simply misunderstood what people are saying.

> But it was solved in OOP when all changes of state happen in *one
> place* under FSM control
Sorry, but that's not what OO is about.
Also, I do not think that you're using general FSMs, else you'd be 
having transition spaghetti.

> (with explicit rules of denied transitions: instead of change you
> have *a request to change*/a message, which can fail if transition is
> denied).
Which does nothing about keeping transitions under control.
Let me repeat: What you call a "message" is just a standard synchronous 
function call. The one difference is that the caller allows the target 
type to influence what function gets actually called, and while that's 
powerful it's quite far from what people assume if you throw that 
"message" terminology around.
This conflation of terminology has been misleading people since the 
invention of Smalltalk. I wish people would finally stop using that 
terminology, and highlight those things where Smalltalk really deviates 
from other OO languages (#doesNotUnderstand, clean 
everything-is-an-object concepts, Metaclasses Done Right). This message 
send terminology is just a distraction.

> Haskell HAS mutable structures, side-effects and allows
> spaghetti-code.
Nope.
Its functions can model these, and to the point that the Haskell code is 
still spaghetti.
But that's not the point. The point is that Haskell makes it easy to 
write non-spaghetti.

BTW you have similar claims about FSMs. Ordinarily they are spaghetti 
incarnate, but you say they work quite beautifully if done right.
(I'm staying sceptical because your arguments in that direction didn't 
make sense to me, but that might be because I'm lacking background 
information, and filling in these gaps is really too far off-topic to be 
of interest.)

 >  But magical word
> “monad” allows to forget about problem and the real solution and to lie 
> that no such problem at whole (it automatically solved due to magical 
> safety of Haskell). Sure, you can do it in Haskell too, but Haskell does 
> not force you, but Smalltalk, for example, forces you.

WTF? You can do spaghetti in Smalltalk. Easily actually, there are 
plenty of antipatterns for that language.

> We often repeat this: “side-effects”, “tracks”, “safe”. But what does it 
> actually mean? Can I have side-effects in Haskell? Yes. Can I mix 
> side-effects? Yes. But in more difficult way than in ML or F#, for 
> example. What is the benefit?

That it is difficult to accidentally introduce side effects.
Or, rather, the problems of side effects. Formally, no Haskell program 
can have a side effect (unless using UnsafeIO or FFI, but that's not 
what we're talking about here).

 >
  Actually no any benefit,

Really. You *should* listen more. If the overwhelming majority of 
Haskell programmers who're using it in practice tell you that there are 
benefits, you should question your analysis, not their experience. You 
should ask rather than make bold statements that run contrary to 
practical experience.
That way, everybody is going to learn: You about your misjudgements, and 
(maybe) Haskell programmers about the limits of the approach.

The way you're approaching this is just going to give you an antibody 
reaction: Everybody is homing in on you, with the sole intent of 
neutralizing you. (Been there, done that, on both sides of the fence.)

 >
  it’s easy
> understandable with simple experiment: if I have a big D program and I 
> remove all “pure” keywords, will it become automatically buggy? No. If I 
> stop to use “pure” totally, will it become buggy? No.

Sure. It will still be pure.

 >
  If I add “print”
> for debug purpose in some subroutines, will they become buggy? No.

Yes they will. Some tests will fail if they expect specific output. If 
the program has a text-based user interface, it will become unusable.

 >
  If I
> mix read/write effects in my subroutine, will it make it buggy? No.

Yes they will become buggy. You'll get aliasing issues. And these are 
the nastiest thing to debug because they will hit you if and only if the 
program is so large that you don't know all the data flows anymore, and 
your assumptions about what might be an alias start to fall down. Or not 
you but maybe the new coworker who doesn't yet know all the parts of the 
program.
That's exactly why data flow is being pushed to being explicit.

> But it’s really very philosophical question, I think that monads are 
> over-hyped actually. I stopped seeing the value of monads by themselves.

Yeah, a lot of people think that monads are somehow state.
It's just that state usually is pretty monadic. Or, rather, the 
functions that are built for computing a "next state" are by nature 
monadic, so that was the first big application area of monads.
But monads are really much more general than for handling state. It's 
like assuming that associativity is for arithmetic, but there's a whole 
lot of other associative operators in the world, some of them even 
useful (such as string concatenation).

>   * Third, AFAIK CLR restrictions do not allow implementing things like
>     Functor, Monad, etc. in F# directly because they can't support HKT.
>     So they workaround the problem.
> 
> https://fsprojects.github.io/FSharpPlus/abstractions.html(btw, you can 
> see that monad is monoid here 😉)

Nope, monoid is a special case of monad (the case where all input and 
output types are the same).
(BTW monoid is associativity + neutral element. Not 100% sure whether 
monad's "return" qualifies as a neutral element, and my 
monoid-equals-monotyped-monad claim above may fall down if it is not. 
Also, different definitions of monad may add different operators so the 
subconcept relationship may not be straightforward.)

(I'm running out of time and interest so I'll leave the remaining points 
uncommented.)

Regards,
Jo

From olf at aatal-apotheke.de  Sun Jul 15 20:06:08 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sun, 15 Jul 2018 22:06:08 +0200 (CEST)
Subject: [Haskell-cafe] Monads because of I/O?
Message-ID: <alpine.DEB.2.02.1807152131280.3608@tarski.funk>

Paul,

monads were not invented because I/O could not be presented in another way 
in Haskell. Monads are way older than Haskell. It is a concept of category 
theory which was developed in the 1950s. Actually some concepts of algebra 
that are even older turn out to be monads. Take Galois theory for 
example. Once you know the pattern, you find a monad under every stone you 
turn around. It's one of the luckiest things that people like Moggi and 
Wadler realized that monads can be applied to structure programs. And 
don't blame them that monads are not composable - it is simply a 
mathematical fact. Some monads do compose with any other monad, and those 
are the monad transformers.

If you like Prolog's relational programming model so much, then you should 
play with those programs that have "no business value". Because Haskell's 
type inference algorithm, together with multi-parameter type classes and 
maybe type level natural numbers together give rise to Prolog-like 
capabilities. All the work is done by the compiler this way.

What you say about FSM is certainly true to some extent - they are well 
understood, can be generated automatically, and there is decent theory to 
reason about them. That is why this model is used in safety-sensitive 
environments such as aviation. I once applied for a position in 
verification in the automotive industry, and the interview partner told me 
that they struggle mightily with the vast state spaces of the FSMs they 
are checking.
All this speaks in favour of Haskell. The semantics is simple and 
beautiful, because it is a single-paradigm language. And because of that, 
clever people can leverage theorem provers to mathematically prove 
correctness of Haskell code. I don't know of many languages where that is 
possible. (But then, I'm not an expert on verification.)

Olaf

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sun Jul 15 20:10:17 2018
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 15 Jul 2018 21:10:17 +0100
Subject: [Haskell-cafe] Investing in languages (Was: What is your
 favourite Haskell "aha" moment?)
In-Reply-To: <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
References: <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
Message-ID: <20180715201017.i6wlsvgrthdn3ezo@weber>

On Fri, Jul 13, 2018 at 08:49:02PM +0200, Joachim Durchholz wrote:
> The other issue is that Haskell's extensions make it more difficult to have
> library code interoperate.

Do they?  Can you give any examples?

From ben at well-typed.com  Mon Jul 16 01:07:15 2018
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 15 Jul 2018 21:07:15 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.6.1-alpha2 available
Message-ID: <87fu0kng3l.fsf@smart-cactus.org>


The GHC development team is pleased to announce the second alpha release
leading up to GHC 8.6.1. The usual release artifacts are available from

    https://downloads.haskell.org/~ghc/8.6.1-alpha2

This alpha fixes many of the bugs reported in the first alpha and
brings many of the core libraries to their (hopefully) final release
versions.

Unfortunately, the documentation troubles affecting the first alpha
haven't quite been resolved in this release. Consequently you will
again find there is no documentation uploaded. However, let us know if
anything else is amiss. Thanks for your help!

Cheers,

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

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Mon Jul 16 06:44:31 2018
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 16 Jul 2018 07:44:31 +0100
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <5b49a397.1c69fb81.8b33f.320d@mx.google.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
 <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
 <d2392c04-1e6b-f07d-9b85-137504e6ff62@gmail.com>
 <98791dc2-e369-a7ba-315a-9b37e149fa2a@durchholz.org>
 <5b49a397.1c69fb81.8b33f.320d@mx.google.com>
Message-ID: <20180716064431.lidgogwzht6w3c6x@weber>

On Sat, Jul 14, 2018 at 10:17:43AM +0300, Paul wrote:
> > Once the FSM holds more than a dozen states, these advantages evaporate.
>
> This is point only where I can not agree.  I used FSM with hundreds
> states/transitions.  It was automatically generated, I only check them. 
> Also I know that in car automatics FSM are widely used (BMW, Mercedes,
> Audi).  Also it’s using in software for space industry widely.  My IMHO
> is: FSM is most reliable way to do soft without bugs.  Also it’s easy to
> verify them (for example, with transitions’ assertions)

It's interesting to see all this chat about FSMs, when FSMs are essentially
"just" a tail recursive function on a sum type.

From aquagnu at gmail.com  Mon Jul 16 07:44:49 2018
From: aquagnu at gmail.com (PY)
Date: Mon, 16 Jul 2018 10:44:49 +0300
Subject: [Haskell-cafe] Investing in languages (Was: What
 isyourfavouriteHaskell "aha" moment?)
In-Reply-To: <6055d12c-ac58-17fa-6846-61f904f00e5e@durchholz.org>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
 <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
 <5b4b7121.1c69fb81.7668.0525@mx.google.com>
 <6055d12c-ac58-17fa-6846-61f904f00e5e@durchholz.org>
Message-ID: <f67e55d2-e332-56e9-b3f4-4d4f1a31de90@gmail.com>


> So I think if you don't see anybody explicitly mentioning spaghetti 
> issues with State that's for some people it's just hiding in plain 
> sight and they either aren't consciously aware of it, or find that 
> area so self-explaining that they do not think they really need to 
> explain that.
>
IMHO State monad solution is orthogonal to my point. It does not force 
you to isolate state change in one place with explicit control, it only 
marks place where it happens. This info is needed to compiler, not to 
me. For me - no benefits. Benefit to me - to isolate changing, but with 
State I can (and all of us do it!) smear change points throughout the 
code. So, my question is: what exact problem does solve State monad? 
Which problem? Mine or compiler? Haskell pure lambda-only-abstraction 
limitation? OK, if we imagine another Haskell, similar to  F#, will I 
need State monad yet? IMHO - no. My point is: State monad is super, in 
Haskell, and absolutely waste in other languages. I will isolate 
mutability in another manner: more safe, robust and controllable. Recap:
1. State monad allows you to mark change of THIS state, so you can easy 
find where THIS state is changing (tracking changes)
2. Singleton with FSM allows you to *control* change and to isolate all 
change logic in one place

1st allows spaghetti, 2nd - does not. 2nd force you to another model: 
not changes, but change requests, which can return: "not possible". With 
Haskell way the check "possible/not possible" will happen in locations 
where you change state in State monad: anywhere. So, my initial point 
is: State monad is about Haskell abstraction problems, not about 
developer problems.

> Sorry, but that's not what OO is about.
> Also, I do not think that you're using general FSMs, else you'd be 
> having transition spaghetti.
To be precise, then yes, you are right. But such model forces me more, 
then monadic model. When you create singleton "PlayerBehavior", and have 
all setters/getters in this singleton and already check (in one place!) 
changes - next step is to switch from checks to explicit FSM - in the 
same place. Haskell nothing offers for this. You *can* do it, but monads 
don't force you and they are about Haskell problems, not mine. 
Motivation of State monad is not to solve problem but to introduce state 
mutability in Haskell, this is my point. OK, State monad has helpful 
side-effect: allows to track change of concrete THIS state, but I can do 
it with my editor, it's more valuable to Haskell itself, then to me, 
because no problem to mutate state: Haskell allows it, Haskell also does 
not guard you to mutate this state anywhere in the application.

I'm agree with you 100%. My point is related to accents only, my thesis 
is: monads have value, but it's small, it's justified in Haskell with 
its limitation to one abstraction, but I don't need monads in other 
languages, their value in other languages is super-small (if even 
exists). So, motivation of monads introduction (for me, sure, I'm very 
subjective) is to workaround Haskell model, not to make code more safe, 
I'm absolutely sure: monads nothing to do with safety. It's like to use 
aspirin with serious medical problem :)

> Let me repeat: What you call a "message" is just a standard 
> synchronous function call. The one difference is that the caller 
> allows the target type to influence what function gets actually 
> called, and while that's powerful it's quite far from what people 
> assume if you throw that "message" terminology around. 
I mentioned Erlang early: the same - you send message to FSM which will 
be lightweight process. Idea of agents and messages is the same in 
Smalltalk, in QNX, in Erlang, etc, etc... So, "message" does not always 
mean "synchronous call". For example, QNX "optimizes" local messages, so 
they are more lightweight in comparison with remotely messages (which 
are naturally asynchronous). But "message" abstraction is the same and 
is more high-level then synchronous/asynchronous dichotomy. It allows 
you to isolate logic - this is the point. Haskell nothing to do with it: 
you smear logic anywhere. But now you mark it explicitly. And you have 
illusion that your code is more safe.

> But that's not the point. The point is that Haskell makes it easy to 
> write non-spaghetti.

How? In Haskell I propagate data to a lot of functions (as argument or 
as hidden argument - in some monad), but with singleton+FSM - you can 
not do it - data is hidden for you, you can only *call logic*, not 
*access data*. Logic in Haskell is forced to be smeared between a lot of 
functions. You *CAN* avoid it, but Haskell does not force you.

> BTW you have similar claims about FSMs. Ordinarily they are spaghetti 
> incarnate, but you say they work quite beautifully if done right.
> (I'm staying sceptical because your arguments in that direction didn't 
> make sense to me, but that might be because I'm lacking background 
> information, and filling in these gaps is really too far off-topic to 
> be of interest.)

I respect your position. Everybody has different experience, and this is 
basically very good!

> We often repeat this: “side-effects”, “tracks”, “safe”. But what does 
> it actually mean? Can I have side-effects in Haskell? Yes. Can I mix 
> side-effects? Yes. But in more difficult way than in ML or F#, for 
> example. What is the benefit?
>
> That it is difficult to accidentally introduce side effects.
> Or, rather, the problems of side effects. Formally, no Haskell program 
> can have a side effect (unless using UnsafeIO or FFI, but that's not 
> what we're talking about here).

Actually if we look to this from high-level, as to "black box" - we see 
that it's truth. Haskell allows to have them, to mix them but in 
different manner.

> Yes they will. Some tests will fail if they expect specific output. If 
> the program has a text-based user interface, it will become unusable.

And wise-versa: if I will remove "print" from such tests and add "pure" 
- they can fail too. IMHO purity/impurity in your example is related to 
expected behavior and it violation, not to point that "more pure - less 
bugs". Pure function can violate its contract as well as impure.

> Yes they will become buggy. You'll get aliasing issues. And these are 
> the nastiest thing to debug because they will hit you if and only if 
> the program is so large that you don't know all the data flows 
> anymore, and your assumptions about what might be an alias start to 
> fall down. Or not you but maybe the new coworker who doesn't yet know 
> all the parts of the program.
> That's exactly why data flow is being pushed to being explicit.

So, to avoid this I should not mix read/write monads, to avoid RWST. In 
this case they should be removed from the language. And monad 
transformers too. My point is: there is some misunderstanding - I often 
listen "side-effects are related to errors", "we should avoid them", 
"they leads to errors", etc, etc, but IMHO pure/impure is needed to FP 
language compiler, not to me. This is the real motto. Adding of 
side-effects does not lead to bugs automatically. Mostly it does not. 
More correct is to say: distinguish of pure/impure code is better to 
analyze the code, to manipulate with it, to transform it (as programmer 
I can transform F# code *easy because no monads*, in Haskell *compiler* 
can transform code easy *because monads*). More important argument for 
me is example with Free monads. They allows to simulate behavior, to 
check logic without to involve real external actions (side-effects). 
Yes, OK, this is argument. It's not explicitly related to buggy code, 
but it's useful. It remember me homoiconic Lisp code where code can be 
processed as data, as AST.

Actually, I had a big interesting discussion in my company with people 
which does not like FP (the root why I become to ask such questions to 
himself). And I got their arguments. I tried to find solid base of mine. 
But currently I see that I like Haskell solutions itself, and I can not 
show concrete examples where they are needed in real world, without 
Haskell specific limitations. I know that those limitations lead to slow 
compilation, to big and complex compiler, I can not prove that 
side-effects means "lead to error", or (more interesting) that it's bad 
to separate side-effects from each other. F#, ML, Lisps have "do-" block 
and no problem with it. They don't need transformers to mix 2 different 
effects in one do-block. If you can prove that this decision leads to 
bugs and Haskell solution does not: it will be bomb :) I think, will be 
a lot of people in CS which will not agree with you ever.

---
Best regards, Paul


From aquagnu at gmail.com  Mon Jul 16 07:50:47 2018
From: aquagnu at gmail.com (PY)
Date: Mon, 16 Jul 2018 10:50:47 +0300
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <20180716064431.lidgogwzht6w3c6x@weber>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <5B4725E2.2000308@ninebynine.org>
 <ad5be40a-34c9-be4b-6550-efe648e14da2@posteo.net>
 <c87a6f99-1182-2f9a-a49d-99b3bf7ef38a@gmail.com>
 <68915671-977f-a7be-37b4-530e100c62a8@durchholz.org>
 <d2392c04-1e6b-f07d-9b85-137504e6ff62@gmail.com>
 <98791dc2-e369-a7ba-315a-9b37e149fa2a@durchholz.org>
 <5b49a397.1c69fb81.8b33f.320d@mx.google.com>
 <20180716064431.lidgogwzht6w3c6x@weber>
Message-ID: <26635285-a8b9-9a50-a4e0-7b9456a70caf@gmail.com>

16.07.2018 09:44, Tom Ellis wrote:
> On Sat, Jul 14, 2018 at 10:17:43AM +0300, Paul wrote:
>>> Once the FSM holds more than a dozen states, these advantages evaporate.
>> This is point only where I can not agree.  I used FSM with hundreds
>> states/transitions.  It was automatically generated, I only check them.
>> Also I know that in car automatics FSM are widely used (BMW, Mercedes,
>> Audi).  Also it’s using in software for space industry widely.  My IMHO
>> is: FSM is most reliable way to do soft without bugs.  Also it’s easy to
>> verify them (for example, with transitions’ assertions)
> It's interesting to see all this chat about FSMs, when FSMs are essentially
> "just" a tail recursive function on a sum type.
Yes :) But more good is to represent FSM as table or diagram - then you 
can easy find right/wrong transitions/states. Any information can be 
represented in different forms but only some of them are good for human ;)

Btw, there are a lot of visual tools to work with FSMs, to develop them 
and tests as well as to translate them to some language.


> _______________________________________________
> 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 aquagnu at gmail.com  Mon Jul 16 07:56:47 2018
From: aquagnu at gmail.com (PY)
Date: Mon, 16 Jul 2018 10:56:47 +0300
Subject: [Haskell-cafe] Monads because of I/O?
In-Reply-To: <alpine.DEB.2.02.1807152131280.3608@tarski.funk>
References: <alpine.DEB.2.02.1807152131280.3608@tarski.funk>
Message-ID: <63d11200-5584-59ef-1f62-eb692784e517@gmail.com>

Hello, Olaf! It's very good point. I'll read more about it. May be I'm 
wrong, but I don't remember any monads in CT, so my suggestion was that 
they were introduced in pure functional languages research (Hope, 
Haskell), not math itself. May be I'm not right. Thanks a lot!


15.07.2018 23:06, Olaf Klinke wrote:
> Paul,
>
> monads were not invented because I/O could not be presented in another 
> way in Haskell. Monads are way older than Haskell. It is a concept of 
> category theory which was developed in the 1950s. Actually some 
> concepts of algebra that are even older turn out to be monads. Take 
> Galois theory for example. Once you know the pattern, you find a monad 
> under every stone you turn around. It's one of the luckiest things 
> that people like Moggi and Wadler realized that monads can be applied 
> to structure programs. And don't blame them that monads are not 
> composable - it is simply a mathematical fact. Some monads do compose 
> with any other monad, and those are the monad transformers.
>
> If you like Prolog's relational programming model so much, then you 
> should play with those programs that have "no business value". Because 
> Haskell's type inference algorithm, together with multi-parameter type 
> classes and maybe type level natural numbers together give rise to 
> Prolog-like capabilities. All the work is done by the compiler this way.
>
> What you say about FSM is certainly true to some extent - they are 
> well understood, can be generated automatically, and there is decent 
> theory to reason about them. That is why this model is used in 
> safety-sensitive environments such as aviation. I once applied for a 
> position in verification in the automotive industry, and the interview 
> partner told me that they struggle mightily with the vast state spaces 
> of the FSMs they are checking.
> All this speaks in favour of Haskell. The semantics is simple and 
> beautiful, because it is a single-paradigm language. And because of 
> that, clever people can leverage theorem provers to mathematically 
> prove correctness of Haskell code. I don't know of many languages 
> where that is possible. (But then, I'm not an expert on verification.)
>
> Olaf


From serg.foo at gmail.com  Mon Jul 16 08:15:10 2018
From: serg.foo at gmail.com (Sergey Vinokurov)
Date: Mon, 16 Jul 2018 09:15:10 +0100
Subject: [Haskell-cafe] Package takeover: bencoding
Message-ID: <CAKRbHWjorYKV5hKCvMN=vHoJee0mAv8qaq61yiS2ahKHEgNhnA@mail.gmail.com>

I'd like to take over maintainership of the bencoding package [1].

The package was not updated to work with ghc 8.0 and will likely require
more fixes to work with ghc 8.4 and some work to make a Stackage
release. There's a PR open for GHC 8.0, but it's still open for a year
and a half [2]. I've tried to ask the author in the PR thread to make me
a maintainer in January but it still hasn't happened.

Cheers,
Sergey

[1]: http://hackage.haskell.org/package/bencoding
[2]: https://github.com/pxqr/bencoding/pull/7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180716/2b205d9d/attachment.html>

From vlatko.basic at gmail.com  Mon Jul 16 08:18:49 2018
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Mon, 16 Jul 2018 10:18:49 +0200
Subject: [Haskell-cafe] SqlPersistT action in MonadError issue
In-Reply-To: <CA+4qU94_fgEM4O-=-fSVsPD_f8VVSNKdpUhY7E_h_XfcmTxYHg@mail.gmail.com>
References: <31fe16b5-8ecb-5795-7ba5-58d5cb84a2b2@gmail.com>
 <CA+4qU94_fgEM4O-=-fSVsPD_f8VVSNKdpUhY7E_h_XfcmTxYHg@mail.gmail.com>
Message-ID: <cedd8721-f9ab-a82d-4543-3b74eba56a1a@gmail.com>

Hi Matt,

Thanks for taking time and giving so thorough explanation and a suggestion. Much 
appreciated. :-)

I figured out some of this, except for the last, main part. I thought the 
problem was in not being able to instantiate MonadError AppException IO, not 
that ExceptT doesn't have MonadUnliftIO.

I'm refactoring some db code and was just exploring possible short-circuiting 
ways in SqlPersistT with custom exception types, like get404.
Which approach would you suggest for that?



vlatko

> -------- Original Message --------
> Subject: Re: [Haskell-cafe] SqlPersistT action in MonadError issue
> From: Matt <parsonsmatt at gmail.com>
> To: vlatko.basic at gmail.com
> Cc: haskell-cafe <Haskell-cafe at haskell.org>
> Date: 14/07/18 20:09
>
>
> The type of `runPool` is given here: 
> https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#v:runPool 
>
>
> runPool::MonadUnliftIO 
> <https://www.stackage.org/haddock/lts-12.0/conduit-1.3.0.3/Conduit.html#t:MonadUnliftIO>m 
> => c ->PersistConfigBackend 
> <https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#t:PersistConfigBackend>c 
> m a ->PersistConfigPool 
> <https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#t:PersistConfigPool>c 
> -> m a
>
> The return type of `runPool`, then, is `m a`, for some `m` satisfying 
> `MonadUnliftIO`.
>
> The type of `liftIO` is `liftIO :: (MonadIO m) => IO a -> m a`. This means 
> that the first argument to `liftIO` must be an `IO a`.
>
> When we say `liftIO (runPool ...)`, GHC tries to unify the `m a` from 
> `runPool` and the `IO a` from `liftIO`. It is able to do this, as `IO` is an 
> instance of `MonadUnliftIO`. Then, the concrete type of `runPool pgConf f1 
> pgPool` becomes `IO Bool`.
>
> GHC now tries to unify the `m` in `f1 :: (MonadIO m, MonadError AppException 
> m) => SqlPersistT m Bool` with `IO`. It tries to satisfy the constraints: 
> `MonadIO` is easily satisfied, but `MonadError AppException m` triggers the 
> problem you mention.
>
> Because `ExceptT` does not have an instance for `MonadUnliftIO`, we cannot use 
> it with the `m` in `SqlPersistT m Bool` directly. We can, instead, use 
> `mapReaderT` to push the `Either` into the return type, like this:
>
> pushException :: SqlPersistT (ExceptT e m) a -> SqlPersistT m (Either e a)
> pushException = mapReaderT runExceptT
>
>
> Now, we can write:
>
> liftIO $ runPool pgConf (pushException f1) pgPool
>
> This gives us an `IO (Either AppException Bool)`, which, after lifting, gives 
> us `AppM IO (Either AppException Bool)`. You can then use `either throwError 
> pure` to pull the `AppException` into the `ExceptT` again.
>
> ---
>
> I would suggest that you reconsider this approach, however. The `persistent` 
> library uses transactions and exceptions in a way that is *almost always* what 
> you want, but can be surprising, and using `ExceptT` will break this system. 
> Transactions are automatically rolled back on a `MonadCatch`-style exception, 
> but they are not automatically rolled back on an `ExceptT`-style exception. 
> Having a single `AppException` type that represents errors that can occur in 
> database transactions *and* the rest of your application is also going to be a 
> cause for unsafety and errors, as the type cannot possibly be precise enough 
> to provide any safety.
>
>
> Matt Parsons
>
> On Sat, Jul 14, 2018 at 10:22 AM, Vlatko Basic <vlatko.basic at gmail.com 
> <mailto:vlatko.basic at gmail.com>> wrote:
>
>     Hello,
>
>     I'm trying to use SqlPersistT funcs with MonadError, but am failing in
>     writing the runDB correctly.
>
>     I tried several things, but always getting:
>
>         • Couldn't match type ‘IOException’ with ‘AppException’
>             arising from a functional dependency between:
>               constraint ‘MonadError AppException IO’ arising from a use of ‘f1’
>               instance ‘MonadError IOException IO’ at <no location info>
>         • In the second argument of ‘runPool’, namely ‘f1’
>           In the second argument of ‘($)’, namely ‘runPool pgConf f1 pgPool’
>           In a stmt of a 'do' block: liftIO $ runPool pgConf f1 pgPool
>
>     I understand there already is "instance MonadError IOException IO" and
>     fundep says it can be only one for IO.
>
>     How to make it compile?
>
>
>     Best regards,
>
>     vlatko
>
>
>     Here is the minimal reproducible code:
>
>     module Test where
>
>     import Prelude
>     import Control.Exception.Base
>     import Control.Monad.Except
>     import Control.Monad.Trans.Reader
>     import Database.Persist.Postgresql
>
>     data AppException =
>         ExcText String
>       | ExcIO IOException
>       deriving (Show)
>
>     type AppM m = ExceptT AppException (ReaderT App m)
>     data App    = App { pgConf :: PostgresConf, pgPool :: ConnectionPool}
>
>     runDB :: (MonadIO m, MonadError AppException m) => AppM m Bool
>     runDB = do
>       App{..} <- lift ask
>       liftIO $ runPool pgConf *f1* pgPool -- error
>       -- liftIO $ runPool pgConf *f2* pgPool -- OK
>
>
>     f1 :: (MonadIO m, MonadError AppException m) => SqlPersistT m Bool
>     f1 = throwError $ ExcText "exception"
>
>     f2 :: MonadIO m => SqlPersistT m Bool
>     f2 = return True
>
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>     Only members subscribed via the mailman list are allowed to post.
>
>

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

From sivanov at colimite.fr  Mon Jul 16 08:54:47 2018
From: sivanov at colimite.fr (Sergiu Ivanov)
Date: Mon, 16 Jul 2018 10:54:47 +0200
Subject: [Haskell-cafe] Investing in languages (Was: What
	isyourfavouriteHaskell "aha" moment?)
In-Reply-To: <f67e55d2-e332-56e9-b3f4-4d4f1a31de90@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
 <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
 <5b4b7121.1c69fb81.7668.0525@mx.google.com>
 <6055d12c-ac58-17fa-6846-61f904f00e5e@durchholz.org>
 <f67e55d2-e332-56e9-b3f4-4d4f1a31de90@gmail.com>
Message-ID: <87muurv9uw.fsf@colimite.fr>

Hi Paul,

Thus quoth  PY  on Mon Jul 16 2018 at 09:44 (+0200):
> So, motivation of monads introduction (for me, sure, I'm very
> subjective) is to workaround Haskell model,

Sometimes (e.g., when you want to be able to prove correctness) you
actually want to express everything in a small basis of
concepts/operations/tools.  To me, monads are cool precisely because
they allow _explicit_ sequencing of actions in a non-sequential model.

By the way, the lift function you mentioned in a previous E-mail does
have a value for the programmer: it shows at which level of the monad
transformer stack the action takes place (for example).


Thus quoth  PY  on Mon Jul 16 2018 at 09:44 (+0200):
> 1. State monad allows you to mark change of THIS state, so you can easy
> find where THIS state is changing (tracking changes)
> 2. Singleton with FSM allows you to *control* change and to isolate all
> change logic in one place
>
> 1st allows spaghetti, 2nd - does not. 2nd force you to another model:

You seem to like it when your paradigm forces you to do something (just
like I do).  Now, monads force you to program in a certain way.
Furthermore, you may say that FSM are a workaround of the way in which
conventional operative languages manipulate state.

My point is: whether monads are a workaround or a solution depends on
the angle at which you look at the situation.  (I think you say
something similar too.)

-
Sergiu


Thus quoth  PY  on Mon Jul 16 2018 at 09:44 (+0200):
>> So I think if you don't see anybody explicitly mentioning spaghetti
>> issues with State that's for some people it's just hiding in plain
>> sight and they either aren't consciously aware of it, or find that
>> area so self-explaining that they do not think they really need to
>> explain that.
>>
> IMHO State monad solution is orthogonal to my point. It does not force
> you to isolate state change in one place with explicit control, it only
> marks place where it happens. This info is needed to compiler, not to
> me. For me - no benefits. Benefit to me - to isolate changing, but with
> State I can (and all of us do it!) smear change points throughout the
> code. So, my question is: what exact problem does solve State monad?
> Which problem? Mine or compiler? Haskell pure lambda-only-abstraction
> limitation? OK, if we imagine another Haskell, similar to F#, will I
> need State monad yet? IMHO - no. My point is: State monad is super, in
> Haskell, and absolutely waste in other languages. I will isolate
> mutability in another manner: more safe, robust and controllable. Recap:
> 1. State monad allows you to mark change of THIS state, so you can easy
> find where THIS state is changing (tracking changes)
> 2. Singleton with FSM allows you to *control* change and to isolate all
> change logic in one place
>
> 1st allows spaghetti, 2nd - does not. 2nd force you to another model:
> not changes, but change requests, which can return: "not possible". With
> Haskell way the check "possible/not possible" will happen in locations
> where you change state in State monad: anywhere. So, my initial point
> is: State monad is about Haskell abstraction problems, not about
> developer problems.
>
>> Sorry, but that's not what OO is about.
>> Also, I do not think that you're using general FSMs, else you'd be
>> having transition spaghetti.
> To be precise, then yes, you are right. But such model forces me more,
> then monadic model. When you create singleton "PlayerBehavior", and have
> all setters/getters in this singleton and already check (in one place!)
> changes - next step is to switch from checks to explicit FSM - in the
> same place. Haskell nothing offers for this. You *can* do it, but monads
> don't force you and they are about Haskell problems, not mine.
> Motivation of State monad is not to solve problem but to introduce state
> mutability in Haskell, this is my point. OK, State monad has helpful
> side-effect: allows to track change of concrete THIS state, but I can do
> it with my editor, it's more valuable to Haskell itself, then to me,
> because no problem to mutate state: Haskell allows it, Haskell also does
> not guard you to mutate this state anywhere in the application.
>
> I'm agree with you 100%. My point is related to accents only, my thesis
> is: monads have value, but it's small, it's justified in Haskell with
> its limitation to one abstraction, but I don't need monads in other
> languages, their value in other languages is super-small (if even
> exists). So, motivation of monads introduction (for me, sure, I'm very
> subjective) is to workaround Haskell model, not to make code more safe,
> I'm absolutely sure: monads nothing to do with safety. It's like to use
> aspirin with serious medical problem :)
>
>> Let me repeat: What you call a "message" is just a standard
>> synchronous function call. The one difference is that the caller
>> allows the target type to influence what function gets actually
>> called, and while that's powerful it's quite far from what people
>> assume if you throw that "message" terminology around.
> I mentioned Erlang early: the same - you send message to FSM which will
> be lightweight process. Idea of agents and messages is the same in
> Smalltalk, in QNX, in Erlang, etc, etc... So, "message" does not always
> mean "synchronous call". For example, QNX "optimizes" local messages, so
> they are more lightweight in comparison with remotely messages (which
> are naturally asynchronous). But "message" abstraction is the same and
> is more high-level then synchronous/asynchronous dichotomy. It allows
> you to isolate logic - this is the point. Haskell nothing to do with it:
> you smear logic anywhere. But now you mark it explicitly. And you have
> illusion that your code is more safe.
>
>> But that's not the point. The point is that Haskell makes it easy to
>> write non-spaghetti.
>
> How? In Haskell I propagate data to a lot of functions (as argument or
> as hidden argument - in some monad), but with singleton+FSM - you can
> not do it - data is hidden for you, you can only *call logic*, not
> *access data*. Logic in Haskell is forced to be smeared between a lot of
> functions. You *CAN* avoid it, but Haskell does not force you.
>
>> BTW you have similar claims about FSMs. Ordinarily they are spaghetti
>> incarnate, but you say they work quite beautifully if done right.
>> (I'm staying sceptical because your arguments in that direction didn't
>> make sense to me, but that might be because I'm lacking background
>> information, and filling in these gaps is really too far off-topic to
>> be of interest.)
>
> I respect your position. Everybody has different experience, and this is
> basically very good!
>
>> We often repeat this: “side-effects”, “tracks”, “safe”. But what does
>> it actually mean? Can I have side-effects in Haskell? Yes. Can I mix
>> side-effects? Yes. But in more difficult way than in ML or F#, for
>> example. What is the benefit?
>>
>> That it is difficult to accidentally introduce side effects.
>> Or, rather, the problems of side effects. Formally, no Haskell program
>> can have a side effect (unless using UnsafeIO or FFI, but that's not
>> what we're talking about here).
>
> Actually if we look to this from high-level, as to "black box" - we see
> that it's truth. Haskell allows to have them, to mix them but in
> different manner.
>
>> Yes they will. Some tests will fail if they expect specific output. If
>> the program has a text-based user interface, it will become unusable.
>
> And wise-versa: if I will remove "print" from such tests and add "pure"
> - they can fail too. IMHO purity/impurity in your example is related to
> expected behavior and it violation, not to point that "more pure - less
> bugs". Pure function can violate its contract as well as impure.
>
>> Yes they will become buggy. You'll get aliasing issues. And these are
>> the nastiest thing to debug because they will hit you if and only if
>> the program is so large that you don't know all the data flows
>> anymore, and your assumptions about what might be an alias start to
>> fall down. Or not you but maybe the new coworker who doesn't yet know
>> all the parts of the program.
>> That's exactly why data flow is being pushed to being explicit.
>
> So, to avoid this I should not mix read/write monads, to avoid RWST. In
> this case they should be removed from the language. And monad
> transformers too. My point is: there is some misunderstanding - I often
> listen "side-effects are related to errors", "we should avoid them",
> "they leads to errors", etc, etc, but IMHO pure/impure is needed to FP
> language compiler, not to me. This is the real motto. Adding of
> side-effects does not lead to bugs automatically. Mostly it does not.
> More correct is to say: distinguish of pure/impure code is better to
> analyze the code, to manipulate with it, to transform it (as programmer
> I can transform F# code *easy because no monads*, in Haskell *compiler*
> can transform code easy *because monads*). More important argument for
> me is example with Free monads. They allows to simulate behavior, to
> check logic without to involve real external actions (side-effects).
> Yes, OK, this is argument. It's not explicitly related to buggy code,
> but it's useful. It remember me homoiconic Lisp code where code can be
> processed as data, as AST.
>
> Actually, I had a big interesting discussion in my company with people
> which does not like FP (the root why I become to ask such questions to
> himself). And I got their arguments. I tried to find solid base of mine.
> But currently I see that I like Haskell solutions itself, and I can not
> show concrete examples where they are needed in real world, without
> Haskell specific limitations. I know that those limitations lead to slow
> compilation, to big and complex compiler, I can not prove that
> side-effects means "lead to error", or (more interesting) that it's bad
> to separate side-effects from each other. F#, ML, Lisps have "do-" block
> and no problem with it. They don't need transformers to mix 2 different
> effects in one do-block. If you can prove that this decision leads to
> bugs and Haskell solution does not: it will be bomb :) I think, will be
> a lot of people in CS which will not agree with you ever.
>
> ---
> Best regards, Paul
>
> _______________________________________________
> 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 --------------
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/20180716/dbec6b7d/attachment.sig>

From massimo.zaniboni at gmail.com  Mon Jul 16 09:58:29 2018
From: massimo.zaniboni at gmail.com (Massimo Zaniboni)
Date: Mon, 16 Jul 2018 11:58:29 +0200
Subject: [Haskell-cafe] BlockedIndefinitelyOnMVar
In-Reply-To: <2113c72d-1693-283e-f43b-72253e7127d0@gmail.com>
References: <709d0f25-ba71-fa4e-6d88-1514752f493b@gmail.com>
 <2113c72d-1693-283e-f43b-72253e7127d0@gmail.com>
Message-ID: <35a2e261-c121-19f3-4e39-1f5830d21b02@gmail.com>

Il 13/07/2018 17:29, Massimo Zaniboni ha scritto:

> ```
>    () <$ (waitAny [p, c])
> ```

waitAny was not the correct solution, because it waits completition of 
only one thread, and not all threads.

So I defined ``waitAll``. It returns also the most informative 
exception. In particular synchronous exceptions are favoured respect 
asynchronous exceptions, because synchronous exceptions are generated 
from the processing code, and not from other threads or the run-time system.

I updated the repo with the code: 
https://github.com/massimo-zaniboni/blocked-on-mvar


From alexey.raga at gmail.com  Mon Jul 16 11:24:25 2018
From: alexey.raga at gmail.com (Alexey Raga)
Date: Mon, 16 Jul 2018 21:24:25 +1000
Subject: [Haskell-cafe] Investing in languages (Was: What
 isyourfavouriteHaskell "aha" moment?)
In-Reply-To: <f67e55d2-e332-56e9-b3f4-4d4f1a31de90@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <d5f6bde5-390b-29d6-c0e6-3cf3a7514a4c@gmail.com>
 <d8de7928-7df1-9fff-32a1-42aef4973049@posteo.net>
 <4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io>
 <720b4f16-6969-42e4-b548-5dd3ced8c58d@gmail.com>
 <e7f16c13-4624-2fad-587e-038c8b9e98a3@posteo.net>
 <4d174e73-91bf-6496-4b33-3865962b40ba@gmail.com>
 <5dd2d476-36e9-d6aa-ef64-35746518bcd5@durchholz.org>
 <5b49a09d.1c69fb81.2feff.f4c2@mx.google.com>
 <CACf4mn-ALzbDHUFLFHRsFqgjGXDVbG4yModELmdzj9DAoX4SAQ@mail.gmail.com>
 <5b4a1698.1c69fb81.c496f.6cab@mx.google.com>
 <CACf4mn-+wYLpJXwTzJWJULECfd=sgUEW+RNKHzKZ4ie26CJ_9Q@mail.gmail.com>
 <5b4b7121.1c69fb81.7668.0525@mx.google.com>
 <6055d12c-ac58-17fa-6846-61f904f00e5e@durchholz.org>
 <f67e55d2-e332-56e9-b3f4-4d4f1a31de90@gmail.com>
Message-ID: <CACf4mn9S4xgy3NxZyP89tUV0-uqEFNz-wQBwvrrk18ozDPOfOA@mail.gmail.com>

I actually lost interest, because you are kind of trying to tell me that
because of your lack of _familiarity_ with monads, _my_ benefits do not
count. I cannot agree with this statement and with this approach.

But since there were questions, I'll answer and do some small clarification.

> I asked because never tried Eta. So, if you are right, seems no reasons
to develop Eta...
I am not sure why you are bringing Eta as an example to this discussion
just to point later that you have no experience with it.
The point of Eta is to run Haskell on JVM. Haskell as of GHC, and not some
hypothetical hybrid language (that would be Scala). If you want a decent
language, and you must run on JVM then you use Eta. If you don't need to
run on JVM - you don't use Eta.

> No better definition then original:
https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions
You see, they are different.
Now it is your turn to read this link. The second sentence on that link
says:
"They can be used to provide a convenient syntax for *monads*, a functional
programming feature that can be used to manage data, control, and side
effects in functional programs."
The emphasis on _monads_ isn't mine, it is original. The computation
expressions are _monadic_ (when they obey laws, but that link doesn't say
anything about laws, unfortunately).

> Something like this:   user?.Phone?.Company?.Name??"missing";     ?
Still no.

> It does not force you to isolate state change in one place with explicit
control, it only
marks place where it happens.

processAttack :: (MonadState s m, HasBpsCounters s) => Attack -> m Result

No benefits for you, tons of benefits for me: I guarantee that this
function can only be called if there is access to some BPS counters. I
guarantee that this function, and whatever if uses inside itself, can never
touch or even look at anything else in my state. I can guarantee that it
doesn't cause any other effects like it doesn't call something which calls
something which prints to console or writes to DB. And that if during code
evolution/refactoring someone does something like that, then it won't
compile.

> If I add “print” for debug purpose in some subroutines, will they become
buggy? No.
Then you add this code inside a transaction and voila - yes, you do have a
bug.
In fact, my colleague who used to work at Nasdaq, had a story about exactly
this: Once upon a time there was a beautiful code that lived in a
transaction. Then someone accidentally introduced a side effect to one of
the functions. This function was called from something within that
transaction. The bug was noticed after some time when it has done some
damage.
In Haskell, you can't do IO in STM, so that wouldn't be possible.

> Haskell also does not guard you to mutate this state anywhere in the
application.
I think my example above proves otherwise: in Haskell, I can granularly
control who can update which part of the state, which makes your statement
invalid.

> monads have value, but it's small ... their value in other languages is
super-small
Again, a VERY bold statement I have to disagree with, once again.
F# workflows are monadic, C# LINQ is precisely modelled by E. Meijer as a
list monad. They add great value.

With this, I rest my case, thanks for the discussion.

Regards,
Alexey.

On Mon, Jul 16, 2018 at 5:45 PM PY <aquagnu at gmail.com> wrote:

>
> > So I think if you don't see anybody explicitly mentioning spaghetti
> > issues with State that's for some people it's just hiding in plain
> > sight and they either aren't consciously aware of it, or find that
> > area so self-explaining that they do not think they really need to
> > explain that.
> >
> IMHO State monad solution is orthogonal to my point. It does not force
> you to isolate state change in one place with explicit control, it only
> marks place where it happens. This info is needed to compiler, not to
> me. For me - no benefits. Benefit to me - to isolate changing, but with
> State I can (and all of us do it!) smear change points throughout the
> code. So, my question is: what exact problem does solve State monad?
> Which problem? Mine or compiler? Haskell pure lambda-only-abstraction
> limitation? OK, if we imagine another Haskell, similar to  F#, will I
> need State monad yet? IMHO - no. My point is: State monad is super, in
> Haskell, and absolutely waste in other languages. I will isolate
> mutability in another manner: more safe, robust and controllable. Recap:
> 1. State monad allows you to mark change of THIS state, so you can easy
> find where THIS state is changing (tracking changes)
> 2. Singleton with FSM allows you to *control* change and to isolate all
> change logic in one place
>
> 1st allows spaghetti, 2nd - does not. 2nd force you to another model:
> not changes, but change requests, which can return: "not possible". With
> Haskell way the check "possible/not possible" will happen in locations
> where you change state in State monad: anywhere. So, my initial point
> is: State monad is about Haskell abstraction problems, not about
> developer problems.
>
> > Sorry, but that's not what OO is about.
> > Also, I do not think that you're using general FSMs, else you'd be
> > having transition spaghetti.
> To be precise, then yes, you are right. But such model forces me more,
> then monadic model. When you create singleton "PlayerBehavior", and have
> all setters/getters in this singleton and already check (in one place!)
> changes - next step is to switch from checks to explicit FSM - in the
> same place. Haskell nothing offers for this. You *can* do it, but monads
> don't force you and they are about Haskell problems, not mine.
> Motivation of State monad is not to solve problem but to introduce state
> mutability in Haskell, this is my point. OK, State monad has helpful
> side-effect: allows to track change of concrete THIS state, but I can do
> it with my editor, it's more valuable to Haskell itself, then to me,
> because no problem to mutate state: Haskell allows it, Haskell also does
> not guard you to mutate this state anywhere in the application.
>
> I'm agree with you 100%. My point is related to accents only, my thesis
> is: monads have value, but it's small, it's justified in Haskell with
> its limitation to one abstraction, but I don't need monads in other
> languages, their value in other languages is super-small (if even
> exists). So, motivation of monads introduction (for me, sure, I'm very
> subjective) is to workaround Haskell model, not to make code more safe,
> I'm absolutely sure: monads nothing to do with safety. It's like to use
> aspirin with serious medical problem :)
>
> > Let me repeat: What you call a "message" is just a standard
> > synchronous function call. The one difference is that the caller
> > allows the target type to influence what function gets actually
> > called, and while that's powerful it's quite far from what people
> > assume if you throw that "message" terminology around.
> I mentioned Erlang early: the same - you send message to FSM which will
> be lightweight process. Idea of agents and messages is the same in
> Smalltalk, in QNX, in Erlang, etc, etc... So, "message" does not always
> mean "synchronous call". For example, QNX "optimizes" local messages, so
> they are more lightweight in comparison with remotely messages (which
> are naturally asynchronous). But "message" abstraction is the same and
> is more high-level then synchronous/asynchronous dichotomy. It allows
> you to isolate logic - this is the point. Haskell nothing to do with it:
> you smear logic anywhere. But now you mark it explicitly. And you have
> illusion that your code is more safe.
>
> > But that's not the point. The point is that Haskell makes it easy to
> > write non-spaghetti.
>
> How? In Haskell I propagate data to a lot of functions (as argument or
> as hidden argument - in some monad), but with singleton+FSM - you can
> not do it - data is hidden for you, you can only *call logic*, not
> *access data*. Logic in Haskell is forced to be smeared between a lot of
> functions. You *CAN* avoid it, but Haskell does not force you.
>
> > BTW you have similar claims about FSMs. Ordinarily they are spaghetti
> > incarnate, but you say they work quite beautifully if done right.
> > (I'm staying sceptical because your arguments in that direction didn't
> > make sense to me, but that might be because I'm lacking background
> > information, and filling in these gaps is really too far off-topic to
> > be of interest.)
>
> I respect your position. Everybody has different experience, and this is
> basically very good!
>
> > We often repeat this: “side-effects”, “tracks”, “safe”. But what does
> > it actually mean? Can I have side-effects in Haskell? Yes. Can I mix
> > side-effects? Yes. But in more difficult way than in ML or F#, for
> > example. What is the benefit?
> >
> > That it is difficult to accidentally introduce side effects.
> > Or, rather, the problems of side effects. Formally, no Haskell program
> > can have a side effect (unless using UnsafeIO or FFI, but that's not
> > what we're talking about here).
>
> Actually if we look to this from high-level, as to "black box" - we see
> that it's truth. Haskell allows to have them, to mix them but in
> different manner.
>
> > Yes they will. Some tests will fail if they expect specific output. If
> > the program has a text-based user interface, it will become unusable.
>
> And wise-versa: if I will remove "print" from such tests and add "pure"
> - they can fail too. IMHO purity/impurity in your example is related to
> expected behavior and it violation, not to point that "more pure - less
> bugs". Pure function can violate its contract as well as impure.
>
> > Yes they will become buggy. You'll get aliasing issues. And these are
> > the nastiest thing to debug because they will hit you if and only if
> > the program is so large that you don't know all the data flows
> > anymore, and your assumptions about what might be an alias start to
> > fall down. Or not you but maybe the new coworker who doesn't yet know
> > all the parts of the program.
> > That's exactly why data flow is being pushed to being explicit.
>
> So, to avoid this I should not mix read/write monads, to avoid RWST. In
> this case they should be removed from the language. And monad
> transformers too. My point is: there is some misunderstanding - I often
> listen "side-effects are related to errors", "we should avoid them",
> "they leads to errors", etc, etc, but IMHO pure/impure is needed to FP
> language compiler, not to me. This is the real motto. Adding of
> side-effects does not lead to bugs automatically. Mostly it does not.
> More correct is to say: distinguish of pure/impure code is better to
> analyze the code, to manipulate with it, to transform it (as programmer
> I can transform F# code *easy because no monads*, in Haskell *compiler*
> can transform code easy *because monads*). More important argument for
> me is example with Free monads. They allows to simulate behavior, to
> check logic without to involve real external actions (side-effects).
> Yes, OK, this is argument. It's not explicitly related to buggy code,
> but it's useful. It remember me homoiconic Lisp code where code can be
> processed as data, as AST.
>
> Actually, I had a big interesting discussion in my company with people
> which does not like FP (the root why I become to ask such questions to
> himself). And I got their arguments. I tried to find solid base of mine.
> But currently I see that I like Haskell solutions itself, and I can not
> show concrete examples where they are needed in real world, without
> Haskell specific limitations. I know that those limitations lead to slow
> compilation, to big and complex compiler, I can not prove that
> side-effects means "lead to error", or (more interesting) that it's bad
> to separate side-effects from each other. F#, ML, Lisps have "do-" block
> and no problem with it. They don't need transformers to mix 2 different
> effects in one do-block. If you can prove that this decision leads to
> bugs and Haskell solution does not: it will be bomb :) I think, will be
> a lot of people in CS which will not agree with you ever.
>
> ---
> Best regards, Paul
>
> _______________________________________________
> 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/20180716/4ea90bb2/attachment-0001.html>

From vanessa.mchale at iohk.io  Mon Jul 16 12:13:51 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Mon, 16 Jul 2018 07:13:51 -0500
Subject: [Haskell-cafe] Monads because of I/O?
In-Reply-To: <63d11200-5584-59ef-1f62-eb692784e517@gmail.com>
References: <alpine.DEB.2.02.1807152131280.3608@tarski.funk>
 <63d11200-5584-59ef-1f62-eb692784e517@gmail.com>
Message-ID: <2a6883b7-53e6-4b40-2b9b-9773f90511ed@iohk.io>

https://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf

On 07/16/2018 02:56 AM, PY wrote:
> Hello, Olaf! It's very good point. I'll read more about it. May be I'm
> wrong, but I don't remember any monads in CT, so my suggestion was
> that they were introduced in pure functional languages research (Hope,
> Haskell), not math itself. May be I'm not right. Thanks a lot!
>
>
> 15.07.2018 23:06, Olaf Klinke wrote:
>> Paul,
>>
>> monads were not invented because I/O could not be presented in
>> another way in Haskell. Monads are way older than Haskell. It is a
>> concept of category theory which was developed in the 1950s. Actually
>> some concepts of algebra that are even older turn out to be monads.
>> Take Galois theory for example. Once you know the pattern, you find a
>> monad under every stone you turn around. It's one of the luckiest
>> things that people like Moggi and Wadler realized that monads can be
>> applied to structure programs. And don't blame them that monads are
>> not composable - it is simply a mathematical fact. Some monads do
>> compose with any other monad, and those are the monad transformers.
>>
>> If you like Prolog's relational programming model so much, then you
>> should play with those programs that have "no business value".
>> Because Haskell's type inference algorithm, together with
>> multi-parameter type classes and maybe type level natural numbers
>> together give rise to Prolog-like capabilities. All the work is done
>> by the compiler this way.
>>
>> What you say about FSM is certainly true to some extent - they are
>> well understood, can be generated automatically, and there is decent
>> theory to reason about them. That is why this model is used in
>> safety-sensitive environments such as aviation. I once applied for a
>> position in verification in the automotive industry, and the
>> interview partner told me that they struggle mightily with the vast
>> state spaces of the FSMs they are checking.
>> All this speaks in favour of Haskell. The semantics is simple and
>> beautiful, because it is a single-paradigm language. And because of
>> that, clever people can leverage theorem provers to mathematically
>> prove correctness of Haskell code. I don't know of many languages
>> where that is possible. (But then, I'm not an expert on verification.)
>>
>> Olaf
>
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180716/5e23af11/attachment.sig>

From parsonsmatt at gmail.com  Mon Jul 16 15:25:41 2018
From: parsonsmatt at gmail.com (Matt)
Date: Mon, 16 Jul 2018 09:25:41 -0600
Subject: [Haskell-cafe] SqlPersistT action in MonadError issue
In-Reply-To: <cedd8721-f9ab-a82d-4543-3b74eba56a1a@gmail.com>
References: <31fe16b5-8ecb-5795-7ba5-58d5cb84a2b2@gmail.com>
 <CA+4qU94_fgEM4O-=-fSVsPD_f8VVSNKdpUhY7E_h_XfcmTxYHg@mail.gmail.com>
 <cedd8721-f9ab-a82d-4543-3b74eba56a1a@gmail.com>
Message-ID: <CA+4qU96=rYojis3=PM5bEtWaW+mxGzE4eX6+Mo5-g-=GdfH21w@mail.gmail.com>

Hi Vlatko,

It depends on what you want to happen. The easiest way is to use the
runtime exception system and `try` to catch the type of exception you want
to handle:

tryApp :: (MonadCatch m) => m a -> m (Either AppException a)
tryApp = try

runDB :: (MonadIO m, MonadCatch m) => SqlPersistT m a -> AppM m (Either
AppException a)
runDB query = do
  App{..} <- ask
  liftIO $ tryApp $ runPool pgConf query pgPool

f1 :: (MonadThrow m) => SqlPersistT m Bool
f1 = throwM (ExcTest "Exception!")

runF1 :: (MonadIO m, MonadCatch m) => AppM m (Either AppException Bool)
runF1 = runDB f1

This approach preserves the transaction rollback feature of `persistent`.
If you do not want to have that feature, then you can put `ExceptT` on the
outside, like `ExceptT AppException (SqlPersistT m) a`, and this will give
you short-circuiting (via the outer ExceptT layer).


Matt Parsons

On Mon, Jul 16, 2018 at 2:18 AM, Vlatko Basic <vlatko.basic at gmail.com>
wrote:

> Hi Matt,
>
> Thanks for taking time and giving so thorough explanation and a
> suggestion. Much appreciated. :-)
>
> I figured out some of this, except for the last, main part. I thought the
> problem was in not being able to instantiate MonadError AppException IO,
> not that ExceptT doesn't have MonadUnliftIO.
>
> I'm refactoring some db code and was just exploring possible
> short-circuiting ways in SqlPersistT with custom exception types, like
> get404.
> Which approach would you suggest for that?
>
>
>
> vlatko
>
>
> -------- Original Message --------
> Subject: Re: [Haskell-cafe] SqlPersistT action in MonadError issue
> From: Matt <parsonsmatt at gmail.com> <parsonsmatt at gmail.com>
> To: vlatko.basic at gmail.com
> Cc: haskell-cafe <Haskell-cafe at haskell.org> <Haskell-cafe at haskell.org>
> Date: 14/07/18 20:09
>
>
> The type of `runPool` is given here: https://www.stackage.
> org/haddock/lts-12.0/persistent-2.8.2/Database-
> Persist-Class.html#v:runPool
>
>     runPool :: MonadUnliftIO
> <https://www.stackage.org/haddock/lts-12.0/conduit-1.3.0.3/Conduit.html#t:MonadUnliftIO>
>  m => c -> PersistConfigBackend
> <https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#t:PersistConfigBackend>
>  c m a -> PersistConfigPool
> <https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#t:PersistConfigPool>
>  c -> m a
>
> The return type of `runPool`, then, is `m a`, for some `m` satisfying
> `MonadUnliftIO`.
>
> The type of `liftIO` is `liftIO :: (MonadIO m) => IO a -> m a`. This means
> that the first argument to `liftIO` must be an `IO a`.
>
> When we say `liftIO (runPool ...)`, GHC tries to unify the `m a` from
> `runPool` and the `IO a` from `liftIO`. It is able to do this, as `IO` is
> an instance of `MonadUnliftIO`. Then, the concrete type of `runPool pgConf
> f1 pgPool` becomes `IO Bool`.
>
> GHC now tries to unify the `m` in `f1 :: (MonadIO m, MonadError
> AppException m) => SqlPersistT m Bool` with `IO`. It tries to satisfy the
> constraints: `MonadIO` is easily satisfied, but `MonadError AppException m`
> triggers the problem you mention.
>
> Because `ExceptT` does not have an instance for `MonadUnliftIO`, we cannot
> use it with the `m` in `SqlPersistT m Bool` directly. We can, instead, use
> `mapReaderT` to push the `Either` into the return type, like this:
>
> pushException :: SqlPersistT (ExceptT e m) a -> SqlPersistT m (Either e a)
> pushException = mapReaderT runExceptT
>
>
> Now, we can write:
>
> liftIO $ runPool pgConf (pushException f1) pgPool
>
> This gives us an `IO (Either AppException Bool)`, which, after lifting,
> gives us `AppM IO (Either AppException Bool)`. You can then use `either
> throwError pure` to pull the `AppException` into the `ExceptT` again.
>
> ---
>
> I would suggest that you reconsider this approach, however. The
> `persistent` library uses transactions and exceptions in a way that is
> *almost always* what you want, but can be surprising, and using `ExceptT`
> will break this system. Transactions are automatically rolled back on a
> `MonadCatch`-style exception, but they are not automatically rolled back on
> an `ExceptT`-style exception. Having a single `AppException` type that
> represents errors that can occur in database transactions *and* the rest of
> your application is also going to be a cause for unsafety and errors, as
> the type cannot possibly be precise enough to provide any safety.
>
>
> Matt Parsons
>
> On Sat, Jul 14, 2018 at 10:22 AM, Vlatko Basic <vlatko.basic at gmail.com>
> wrote:
>
>> Hello,
>>
>> I'm trying to use SqlPersistT funcs with MonadError, but am failing in
>> writing the runDB correctly.
>>
>> I tried several things, but always getting:
>>
>>     • Couldn't match type ‘IOException’ with ‘AppException’
>>         arising from a functional dependency between:
>>           constraint ‘MonadError AppException IO’ arising from a use of
>> ‘f1’
>>           instance ‘MonadError IOException IO’ at <no location info>
>>     • In the second argument of ‘runPool’, namely ‘f1’
>>       In the second argument of ‘($)’, namely ‘runPool pgConf f1 pgPool’
>>       In a stmt of a 'do' block: liftIO $ runPool pgConf f1 pgPool
>> I understand there already is "instance MonadError IOException IO" and
>> fundep says it can be only one for IO.
>>
>> How to make it compile?
>>
>> Best regards,
>>
>> vlatko
>>
>>
>>
>> Here is the minimal reproducible code:
>> module Test where
>>
>> import Prelude
>> import Control.Exception.Base
>> import Control.Monad.Except
>> import Control.Monad.Trans.Reader
>> import Database.Persist.Postgresql
>>
>> data AppException =
>>     ExcText String
>>   | ExcIO IOException
>>   deriving (Show)
>>
>> type AppM m = ExceptT AppException (ReaderT App m)
>> data App    = App { pgConf :: PostgresConf, pgPool :: ConnectionPool}
>>
>> runDB :: (MonadIO m, MonadError AppException m) => AppM m Bool
>> runDB = do
>>   App{..} <- lift ask
>>   liftIO $ runPool pgConf *f1* pgPool    -- error
>>   -- liftIO $ runPool pgConf *f2* pgPool  -- OK
>>
>>
>> f1 :: (MonadIO m, MonadError AppException m) => SqlPersistT m Bool
>> f1 = throwError $ ExcText "exception"
>>
>> f2 :: MonadIO m => SqlPersistT m Bool
>> f2 = return True
>>
>>
>> _______________________________________________
>> 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/20180716/93baeb31/attachment.html>

From amindfv at gmail.com  Mon Jul 16 17:37:36 2018
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 16 Jul 2018 13:37:36 -0400
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <D4131C5F-52CB-41A0-95E8-F3E4A34CFABF@gmail.com>

After a chat with a genomics Ph.D student, a couple of small ideas (and I'd also like to +1 Takenobu's suggestions):

  - Purity and laziness allowing the separation of producer and consumer for an arbitrary data model. For example, if you've got a function "legalNextMoves :: ChessBoard -> [ChessBoard]", you can easily construct an efficient tree of all possible chess games, "allGames :: Tree ChessBoard" and write different consumer functions to traverse the tree separately -- and walking the infinite tree is as simple as pattern-matching.

  - Large-scale refactoring with types: this is a huge selling point for Haskell in general, including at my job. The ability to have a codebase which defines

data Shape
   = Circle Double
   | Square Double

area :: Shape -> Double
area = \case
   Circle r -> pi * r ^ 2
   Square w -> w ^ 2

...and simply change the type to...

data Shape
   = Circle Double
   | Square Double
   | Rectangle Double Double

...and have GHC tell us with certainty every place where we've forgotten about the Rectangle case is a fantastic, fantastic benefit of Haskell in large codebases.

Tom


> El 11 jul 2018, a las 08:10, Simon Peyton Jones via Haskell-Cafe <haskell-cafe at haskell.org> escribió:
> 
> Friends
> 
> In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger Institute about Haskell.   They do lots of programming, but they aren’t computer scientists.
> 
> I can tell them plenty about Haskell, but I’m ill-equipped to answer the main question in their minds: why should I even care about Haskell?  I’m too much of a biased witness.
> 
> 
> So I thought I’d ask you for help.  War stories perhaps – how using Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d love to illustrate with copious examples of beautiful code.
> 
> Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about?   Something that gave you an “aha” moment, or that feeling of joy when you truly make sense of something for the first time.
> The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn’t going to do it for them.  I need examples that I can present in 5 minutes, without needing a long setup.
> 
> To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C.  It’s so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc.  But it also makes much less good use of memory, and is likely to run slower.  I think I can do that in 5 minutes.
> 
> Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors.   Maybe 8 minutes.
> 
> But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done.
> 
> Pointers to your favourite blog posts would be another avenue.  (I love the Haskell Weekly News.)
> 
> Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience.
> 
> Thank you!  Perhaps your responses on this thread (if any) may be helpful to more than just me.
> 
> Simon
> 
> _______________________________________________
> 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/20180716/a021e550/attachment.html>

From samth at cs.indiana.edu  Mon Jul 16 19:07:39 2018
From: samth at cs.indiana.edu (Sam Tobin-Hochstadt)
Date: Mon, 16 Jul 2018 15:07:39 -0400
Subject: [Haskell-cafe] DSLDI 2018: First Call for Talk Proposals
Message-ID: <CAK=HD+bbye8F5UwRXu4Z2EaoLP=VrH-2eAds8xK37+Mv+ALSJQ@mail.gmail.com>

*********************************************************************
FIRST CALL FOR TALK PROPOSALS

DSLDI 2018

Sixth Workshop on
Domain-Specific Language Design and Implementation

November 6th, 2018
Boston, USA
Co-located with SPLASH

http://2018.splashcon.org/track/dsldi-2018-talks
https://twitter.com/wsdsldi
*********************************************************************

Deadline for talk proposals: 17th of August, 2018

Well-designed and implemented domain-specific languages (DSLs) can
achieve both usability and performance benefits over general-purpose
programming languages. By raising the level of abstraction and
exploiting domain knowledge, DSLs can make programming more
accessible, increase programmer productivity, and support
domain-specific optimizations.

## Workshop Goal

Domain-Specific Language Design and Implementation (DSLDI) is a
workshop intended to bring together researchers and practitioners
interested in discussing how DSLs should be designed, implemented,
supported by tools, and applied in realistic contexts. The focus of
the workshop is on all aspects of this process, from soliciting domain
knowledge from experts, through the design and implementation of the
language, to evaluating whether and how a DSL is successful. More
generally, we are interested in continuing to build a community that
can drive forward the development of modern DSLs.

## Workshop Format

DSLDI is a single-day workshop and will consist of an invited speaker
followed by moderated audience discussions structured around a series
of short talks. The role of the talks is to facilitate interesting and
substantive discussion. Therefore, we welcome and encourage talks that
express strong opinions, describe open problems, propose new research
directions, and report on early research in progress.

Proposed talks should be on topics within DSLDI’s area of interest,
which include but are not limited to:

* solicitation and representation of domain knowledge
* DSL design principles and processes
* DSL implementation techniques and language workbenches
* domain-specific optimizations
* human factors of DSLs
* tool support for DSL users
* community and educational support for DSL users
* applications of DSLs to existing and emerging domains
* studies of usability, performance, or other benefits of DSLs
* experience reports of DSLs deployed in practice

## Call for Talk Proposals

We solicit talk proposals in the form of short abstracts (max. 2
pages). A good talk proposal describes an interesting position, open
problem, demonstration, or early achievement. The submissions will be
reviewed on relevance and clarity, and used to plan the mostly
interactive sessions of the workshop day. Publication of accepted
abstracts and slides on the website is voluntary.

* Deadline for talk proposals: August 17th, 2018
* Notification: September 17th, 2018
* Workshop: November 6th, 2018
* Submission website: https://dsldi18.hotcrp.com/

## Workshop Organization

Co-chairs:

* Sam Tobin-Hochstadt (samth at indiana.edu), Indiana University
* Lindsey Kuper (lindsey at composition.al), University of California, Santa Cruz

Follow us on Twitter at https://twitter.com/wsdsldi

Program committee:

* Eric Van Wyk (University of Minnesota)
* Katherine Ye (Carnegie Mellon University)
* Nate Foster (Cornell University)
* Spencer Florence (Northwestern University)
* Phitchaya Mangpo Phothilimthana (University of California, Berkeley)
* Jeremy Gibbons (University of Oxford)
* Edwin Brady (University of St. Andrews)

From brucker at spamfence.net  Mon Jul 16 19:26:32 2018
From: brucker at spamfence.net (Achim D. Brucker)
Date: Mon, 16 Jul 2018 22:26:32 +0300
Subject: [Haskell-cafe] Deadline Extension: Workshop in OCL and Textual
	Modeling (OCL 2018)
Message-ID: <20180716192632.k5nb5w66gso34s7c@kandagawa.home.brucker.ch>

(Apologies for duplicates)



  **********************************************************
  **  Deadline Extension: new deadline 24th of July 2018   *
  **********************************************************

                        CALL FOR PAPERS
       18th International Workshop on OCL and Textual Modeling

                       Co-located with 
       MODELS 2018: ACM/IEEE 21th International Conference on Model
              Driven Engineering Languages and System,
            October 14, 2018, Copenhagen, Denmark
                     http://oclworkshop.github.io


Modeling started out with UML and its precursors as a graphical notation.
Such visual representations enable direct intuitive capturing of reality,
but they have weaknesses: for example, detailed visual representations bear
the risk of becoming overcrowded faster than textual models and some of
the visual features lack the level of precision required to create complete
and unambiguous specifications. These weaknesses of graphical notations
encouraged the development of text-based modeling languages that either
integrate with or replace graphical notations for modeling. Typical examples
of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual
modeling languages have their roots in formal language paradigms like logic,
programming and databases.

The goal of this workshop is to create a forum where researchers and practitioners
interested in building models using OCL or other kinds of textual
languages can directly interact, report advances, share results, identify tools
for language development, and discuss appropriate standards. In particular,
the workshop will encourage discussions for achieving synergy from different
modeling language concepts and modeling language use. The close interaction
will enable researchers and practitioners to identify common interests
and options for potential cooperation.

## Topics of interest

Topics of interest include (but are not limited to):

- Mappings between textual modeling languages and other languages/formalisms
- Mathematical models and/or formal semantics for textual modeling languages
- Algorithms, evaluation strategies and optimizations in the context
  of textual modeling languages for:
  - validation, verification, and testing,
  - model transformation and code generation,
  - meta-modeling and DSLs, and
  - query and constraint specifications
- Alternative graphical/textual notations for textual modeling languages
- Evolution, transformation and simplification of textual modeling
  expressions
- Libraries, templates and patterns for textual modeling languages
- Tools that support textual modeling languages (e.g., verification of
  OCL formulae, runtime monitoring of invariants)
- Model-driven security using textual modeling languages 
- Complexity results for textual modeling languages
- Quality models and benchmarks for comparing and evaluating
  textual modeling tools and algorithms
- Successful applications of textual modeling languages
- Case studies on industrial applications of textual modeling languages
- Experience reports:
  - usage of textual modeling languages and tools in complex domains,
  - usability of textual modeling languages and tools for end-users
- Empirical studies about the benefits and drawbacks of textual modeling
  languages
- Innovative textual modeling tools
- Comparison, evaluation and integration of modeling languages
- Correlation between modeling languages and modeling tasks

We particularly encourage submissions describing applications and case studies 
of textual modeling as well as test suites and benchmark collections for evaluating 
textual modeling tools.

## Venue
This workshop will be organized as a part of MODELS 2018 Conference in 
Copenhagen, Denmark. Similar to its predecessors, the workshop addresses both 
people from academia and industry. The aim is to provide a forum for addressing 
integration of OCL and other textual modeling languages, as well as tools for 
textual modeling, and for disseminating good practice and discussing the new
requirements for textual modeling.


## Workshop Format

The workshop will include short (about 15 min) presentations, parallel
sessions of working groups, and sum-up discussions.

## Submissions

Two types of papers will be considered:

* Short contributions (between 5 and 7 pages) describing new ideas, innovative 
  tools or position papers.
* Full papers (between 10 and 14 pages).

in LNCS format. Submissions should be uploaded to
[EasyChair](https://easychair.org/conferences/?conf=ocl2018).
The program committee will review the submissions (minimum 2 reviews per
paper, usually 3 reviews) and select papers according to their
relevance and interest for discussions that will take place at the
workshop. Accepted papers will be published online, as part of the
MODELS workshop proceedings, in [CEUR](http://www.ceur-ws.org).

## Important Dates

- Submission of papers:      July  24, 2018 (extended)
- Notification:              August 17, 2018
- Workshop date:             October 14, 2018 



-- 
Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield
               https://www.brucker.ch | https://logicalhacking.com/blog
                           @adbrucker | @logicalhacking 

From johannes.waldmann at htwk-leipzig.de  Mon Jul 16 19:28:07 2018
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 16 Jul 2018 21:28:07 +0200
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
Message-ID: <1c6a08ca-900a-8451-daf3-d0855c902487@htwk-leipzig.de>

>  - Large-scale refactoring with types:
> this is a huge selling point for Haskell in general

I fully agree with the general idea, but the specific example

> data Shape
>   = Circle Double
>   | Square Double
>   | Rectangle Double Double   -- ^ added

is not convincing (well, to programmers
that know about static typing) Think of a Java program

interface Shape { .. }
class Circle implement Shape { ... }

When you add   class Rectangle {  } ,
then  Shape foo = new Rectangle ()  would be an error,

until you put   class Rectangle implements Shape {  }
then the compiler tells you what methods are missing.


I think the extra value of types in Haskell
(for everything, including refactoring)
is that they tend to express more of the program's properties
(w.r.t. statically typed imperative programs).

Examples:

the distinction between  a  and  IO a,
between  IO a  and   STM a.

In  Data.Set, function  "fromList"  has an  Ord  constraint,
but  "toList"  does not. Does  "singleton"  need the constraint?
I used this as an exam question just last week.


- J.W.

From olf at aatal-apotheke.de  Mon Jul 16 19:48:05 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Mon, 16 Jul 2018 21:48:05 +0200 (CEST)
Subject: [Haskell-cafe] Monads vs. monoids
Message-ID: <alpine.DEB.2.02.1807162108220.3850@tarski.funk>

Joachim Durchholz wrote:
>Nope, monoid is a special case of monad (the case where all input and
>output types are the same).
>(BTW monoid is associativity + neutral element. Not 100% sure whether
>monad's "return" qualifies as a neutral element, and my
>monoid-equals-monotyped-monad claim above may fall down if it is not.

For every monad M, the type M () is a monoid, with
mempty = return ()
x <> y = x >> y
Does every monoid arise this way? Yes: Since base-4.9 there is the monad 
instance
Monoid a => Monad ((,) a)
and of course a and (a,()) are isomorphic (disregarding bottoms).

Also, there is the famous tongue-in-cheek saying "monads are just monoids 
in the category of endofunctors" which is explained in numerous blog posts 
and Youtube videos.

The monoid M () above has funny properties. Specialize M = [] and obtain 
the monoid of natural numbers under multiplication. Since (>>) has the 
more general type
Monad m => m a -> m b -> m b
We have a monoid action of M () on any type M b. In case of lists, it 
multiplies elements: [(),()] >> xs doubles the number of every element of 
the list xs.

Olaf


From mail at joachim-breitner.de  Mon Jul 16 23:29:28 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 16 Jul 2018 19:29:28 -0400
Subject: [Haskell-cafe] Final Call for Talks -- Haskell Implementors'
	Workshop
Message-ID: <77ede8a4f375a26cb04a87bd73bc06a840a27c77.camel@joachim-breitner.de>

                        Call for Contributions
               ACM SIGPLAN Haskell Implementors’ Workshop

            https://icfp18.sigplan.org/track/hiw-2018-papers

                     Co-located with ICFP 2018
                      St. Louis, Missouri, US
              https://conf.researchr.org/home/icfp-2018

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

Proposal Deadline:  Friday, 20 July, 2018
Notification:       Friday, 3 August, 2018
Workshop:           Sunday, 23 September, 2018

Keynote speaker
---------------

This year, the Haskell Implementors’ Workshop is proud to present
Rahul Muttineni as the keynote speaker. Rahul brough the joys of
Haskell to the realm of Java by creating the Eta programming language.

   Title: Let's Go Mainstream with Eta!

   Eta is a fork of GHC that focuses on three core principles: user
   experience, performance, and safety. We'll discuss how we used these
   principles to guide the re-implementation of the GHC runtime and
   code generator on the JVM. Moreover, will also cover the inner
   workings of the FFI and the typechecker support we added for
   subtyping to make it smooth to interact with Java libraries.
   Finally, we'll round out with a look at where Eta is headed and how
   Eta and GHC can collaborate in the future.


About the Haskell Implementors’ Workshop
----------------------------------------

The 10th Haskell Implementors’ Workshop is to be held alongside ICFP
2018 this year in St. Louis. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings. The workshop will be informal and interactive, with open
spaces in the timetable and room for ad-hoc discussion, demos and
lightning talks.

Scope and Target Audience
-------------------------

It is important to distinguish the Haskell Implementors’ Workshop from
the Haskell Symposium which is also co-located with ICFP 2018. The
Haskell Symposium is for the publication of Haskell-related research.
In contrast, the Haskell Implementors’ Workshop will have no
proceedings – although we will aim to make talk videos, slides and
presented data available with the consent of the speakers.

The Implementors’ Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related
tool, or even propose future lines of Haskell development. Members of
the wider Haskell community encouraged to attend the workshop – we
need your feedback to keep the Haskell ecosystem thriving. Students
working with Haskell are specially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we’ve missed, so by all means submit a proposal even
if it doesn’t fit exactly into one of these buckets:

 *  Compilation techniques
 *  Language features and extensions
 *  Type system implementation
 *  Concurrency and parallelism: language design and implementation
 *  Performance, optimisation and benchmarking
 *  Virtual machines and run-time systems
 *  Libraries and tools for development or deployment

Talks
-----

We invite proposals from potential speakers for talks and
demonstrations. We are aiming for 20-minute talks with 5 minutes for
questions and changeovers. We want to hear from people writing
compilers, tools, or libraries, people with cool ideas for directions
in which we should take the platform, proposals for new features to be
implemented, and half-baked crazy ideas. Please submit a talk title
and abstract of no more than 300 words.

Submissions can be made via HotCRP at
                    https://icfp-hiw18.hotcrp.com/
until July 20th (anywhere on earth).

We will also have lightning talks session. These have been very well
received in recent years, and we aim to increase the time available to
them. Lightning talks be ~7mins and are scheduled on the day of the
workshop. Suggested topics for lightning talks are to present a single
idea, a work-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.

Program Committee
-----------------

 * Edwin Brady (University of St. Andrews, UK)
 * Joachim Breitner – chair (University of Pennsylvania)
 * Ben Gamari (Well-Typed LLP)
 * Michael Hanus (Kiel University)
 * Roman Leshchinsky (Facebook)
 * Niki Vazou (University of Maryland)

Contact
-------

 * Joachim Breitner <joachim at cis.upenn.edu>


-- 
Joachim Breitner
Post-Doctoral researcher
http://cis.upenn.edu/~joachim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180716/99a19e5c/attachment.sig>

From trebla at vex.net  Tue Jul 17 02:49:41 2018
From: trebla at vex.net (Albert Y. C. Lai)
Date: Mon, 16 Jul 2018 22:49:41 -0400
Subject: [Haskell-cafe] if-then without -else?
In-Reply-To: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
References: <2dee8ceb-24bb-de65-1dbd-a26c194f7159@htwk-leipzig.de>
Message-ID: <c4ffc485-6356-624c-9081-375ddb88f1a5@vex.net>

On 2018-07-09 01:20 PM, Johannes Waldmann wrote:
> a student in my class detected
> this inconsistency in the design of Haskell:
> 
>> Why require that each "if-then" has an "else"
>> while still allowing incomplete sets of patterns?
>> We could define "if p then a"
>> by translating to "case p of { True -> a }"
> 
> I think that "but then we'd have the dangling-else problem"
> is not a good answer because this is really about semantics,
> not surface syntax.

Anthony Clayden is right that if-then-else has the benefit of giving an 
unambiguous grammar.

if-then can be made unambiguous if you throw in delimiting, e.g., 
if-then-fi, if-then-begin-end.

Suppose you like to support if-then (and have your disambiguation story) 
on the ground that case-of-True is already supported, and you don't mind 
the partiality, then why stop there?

Why is if-else getting no love from you?  Afterall, case-of-False is 
already supported, too.

 >:)

From jo at durchholz.org  Tue Jul 17 07:30:04 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 17 Jul 2018 09:30:04 +0200
Subject: [Haskell-cafe] Monads vs. monoids
In-Reply-To: <alpine.DEB.2.02.1807162108220.3850@tarski.funk>
References: <alpine.DEB.2.02.1807162108220.3850@tarski.funk>
Message-ID: <8a5960ce-bbad-47b5-2490-143f013fa92f@durchholz.org>

Am 16.07.2018 um 21:48 schrieb Olaf Klinke:
> Joachim Durchholz wrote:
>> Nope, monoid is a special case of monad (the case where all input and
>> output types are the same).
>> (BTW monoid is associativity + neutral element. Not 100% sure whether
>> monad's "return" qualifies as a neutral element, and my
>> monoid-equals-monotyped-monad claim above may fall down if it is not.
> 
> For every monad M, the type M () is a monoid,

That doesn't make M a monoid, just its type.
Besides, type-level monoids aren't relevant to data-level properties.

> Does every monoid arise this way? Yes: Since base-4.9 there is the monad 
> instance
> Monoid a => Monad ((,) a)
> and of course a and (a,()) are isomorphic (disregarding bottoms).

An isomorphism does not make it the same, just easily mappable.

This is pretty near to hair-splitting, I know.
However, from a software design perspective, it's important to keep 
things separate even if they are easily mappable: temperatures are just 
floats, it's an incredibly easy mapping - but the code becomes clearer 
and more maintainable if you keep the Temperature type separate from the 
Float type. You may even want to forbid multiplying Temperatures (but 
you want the ability to multiply with a number, and temperature 
quotients can be useful, too).
Not 100% sure how much of this is really applicable.

> Also, there is the famous tongue-in-cheek saying "monads are just 
> monoids in the category of endofunctors"

Tongue-in-check does not make it real.
And being a monoid in a category does not make it a monoid directly.

There's also a final argument: If monad and monoid are really the same, 
why do mathematicians still keep the separate terminology?

Regards,
Jo

From jerzy.karczmarczuk at unicaen.fr  Tue Jul 17 08:55:30 2018
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 17 Jul 2018 10:55:30 +0200
Subject: [Haskell-cafe] Monads vs. monoids
In-Reply-To: <8a5960ce-bbad-47b5-2490-143f013fa92f@durchholz.org>
References: <alpine.DEB.2.02.1807162108220.3850@tarski.funk>
 <8a5960ce-bbad-47b5-2490-143f013fa92f@durchholz.org>
Message-ID: <e7d7ce14-31a4-a19d-e0f1-bb9385ccf391@unicaen.fr>

Le 17/07/2018 à 09:30, Joachim Durchholz a écrit :
> being a monoid in a category does not make it a monoid directly. 

???
Could you please explain what do you mean by this?

>  There's also a final argument: If monad and monoid are really the 
> same, why do mathematicians still keep the separate terminology?

I am sure that you see yourself that this is a non-argument. Mathematics 
is a human activity, not a formal, distilled language.

On math.stackexchange.com there is a discussion about "monoid" term 
history. One user says: Oxford English Dictionary traces monoid in this 
sense back to Chevalley's Fundamental Concept of Algebra published in 
1956. Arthur Mattuck's review of the book in 1957 suggests that this use 
may be new...

Others trace the term to MacLane, or to something which appeared in 
1954. So, it was a term which lived separately from monads.

==
Mathematicians don't quarrel often on terminological issues, unless they 
have nothing more interesting to do.

In the Barr & Wells book monads figure once, just to tell the readers 
that the term "have also been used in place of “triple”" (Even without 
the attribution: "Kleisli"...). (And they mention "triads", "fundamental 
constructions", etc.).

In abstract algebra some people say "magma", others:  "grupoid" , and ---

There is also the inverse phenomenon, the existence of distinct enities 
with the same name. In Differential geometry, the "pullback" is used 
differently than in Categories.

--- the literature will warn you that grupoid in Category Theory means 
something different. (Former: a structure with a single binary op; here: 
a group with partial function replacing the binop).

Wikipedia will tell you:   "In non-standard analysis, a monad (also 
called halo) is the set of points infinitesimally close to a given 
point."   Anybody here heard about this?...

etc. etc. ...
Thanks.

Jerzy Karczmarczuk
/Caen, France/



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus


From athas at sigkill.dk  Tue Jul 17 13:00:25 2018
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 17 Jul 2018 15:00:25 +0200
Subject: [Haskell-cafe] Proper rounding of floating-point values
Message-ID: <87r2k2ow46.fsf@sigkill.dk>

Much to my surprise, there does not seem to be a function in base (let
alone the Prelude) that rounds floating point numbers correctly in the
presence of NaNs and infinities.  For example:

  > round (0/0 :: Double) :: Int
  0
  > round (0/0 :: Double) :: Integer
-269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824
  > round (1/0 :: Double) :: Int
  0
  > round (1/0 :: Double) :: Integer
  179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216

This is because the 'round' function must return an instance of
Integral, which Double is not.  In the presence of NaNs and infinities,
this does not fly.  In my own code, I ended up just using the FFI to
call out to C, which is simple enough:

  foreign import ccall "round" c_round :: Double -> Double
  foreign import ccall "roundf" c_roundf :: Float -> Float

However, it does disturb me a bit that I cannot find a standard way to
do this fairly common operation.

(GHC's implementation does seem to avoid many other common pitfalls[0],
probably because it does use C's round() under the covers.)

[0]: https://www.cockroachlabs.com/blog/rounding-implementations-in-go/

-- 
\  Troels
/\ Henriksen

From olf at aatal-apotheke.de  Tue Jul 17 20:23:43 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Tue, 17 Jul 2018 22:23:43 +0200 (CEST)
Subject: [Haskell-cafe] Monads vs. monoids
Message-ID: <alpine.DEB.2.02.1807172221240.3741@tarski.funk>

>Am 16.07.2018 um 21:48 schrieb Olaf Klinke:
>> Joachim Durchholz wrote:
>>> Nope, monoid is a special case of monad (the case where all input and
>>> output types are the same).
>>> (BTW monoid is associativity + neutral element. Not 100% sure whether
>>> monad's "return" qualifies as a neutral element, and my
>>> monoid-equals-monotyped-monad claim above may fall down if it is not.
>>
>> For every monad M, the type M () is a monoid,
>
>That doesn't make M a monoid, just its type.
>Besides, type-level monoids aren't relevant to data-level properties.

I'm sorry, I misunderstood your question, then. Of course monads are not 
monoids.
You could say that every monad harbors a monoid, and that every monoid 
arises this way. But of course the whole and the part are not the same.

>
>> Does every monoid arise this way? Yes: Since base-4.9 there is the 
>> monad instance
>> Monoid a => Monad ((,) a)
>> and of course a and (a,()) are isomorphic (disregarding bottoms).
>
>An isomorphism does not make it the same, just easily mappable.
>
>This is pretty near to hair-splitting, I know.
>However, from a software design perspective, it's important to keep
>things separate even if they are easily mappable: temperatures are just
>floats, it's an incredibly easy mapping - but the code becomes clearer
>and more maintainable if you keep the Temperature type separate from the
>Float type. You may even want to forbid multiplying Temperatures (but
>you want the ability to multiply with a number, and temperature
>quotients can be useful, too).

I totally agree. As a domain theorist I am aware that a and (a,()) are not 
isomorphic because neither is () the terminal object of Hask nor is (,) 
the categorical product. But in terms of total elements, there is a monoid 
isomorphism between the two.

>Not 100% sure how much of this is really applicable.
>
>> Also, there is the famous tongue-in-cheek saying "monads are just
>> monoids in the category of endofunctors"
>
>Tongue-in-check does not make it real.
>And being a monoid in a category does not make it a monoid directly.

That depends on the definition of "monoid". If a monoid is a set with 
certain structure, then a monad is not a monoid. If a monoid is a monoid 
object in some monoidal category, then a monad is a monoid. Maybe we can 
agree on this distinction?
monoid = monoid object in Set
monoid object = any monoid object in monoidal closed category.
>
>There's also a final argument: If monad and monoid are really the same,
>why do mathematicians still keep the separate terminology?

Because they are different, as we hopefully agree.

Olaf



From jo at durchholz.org  Tue Jul 17 20:36:46 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 17 Jul 2018 22:36:46 +0200
Subject: [Haskell-cafe] Monads vs. monoids
In-Reply-To: <alpine.DEB.2.02.1807172221240.3741@tarski.funk>
References: <alpine.DEB.2.02.1807172221240.3741@tarski.funk>
Message-ID: <2cca8874-11a4-a201-d766-281447b2787b@durchholz.org>

Am 17.07.2018 um 22:23 schrieb Olaf Klinke:
> You could say that every monad harbors a monoid, and that every monoid 
> arises this way. But of course the whole and the part are not the same.

Agreed.

> That depends on the definition of "monoid". If a monoid is a set with 
> certain structure, then a monad is not a monoid.

That's the perspective from which I'm looking at abstract data types: A 
set of values, a set of operations, a set of axioms over the operations 
and values.
Well, that's the textbook definition, there's a lot of data structures 
that have multiple value sets but still are related through axioms. I 
just don't know an example of such a structure that it could make it 
into the textbooks :-)

 From that perspective, monads and monoids are distinct.
Even fundamentally so: Monad axioms have more type parameters than 
monoid axioms, so they cannot be made isomorphic by clever transformations.

>> There's also a final argument: If monad and monoid are really the same,
>> why do mathematicians still keep the separate terminology?
> 
> Because they are different, as we hopefully agree.

We do :-)

Regards,
Jo

From profunctor at pm.me  Wed Jul 18 09:21:55 2018
From: profunctor at pm.me (Marcin Szamotulski)
Date: Wed, 18 Jul 2018 05:21:55 -0400
Subject: [Haskell-cafe] Monads vs. monoids
In-Reply-To: <2cca8874-11a4-a201-d766-281447b2787b@durchholz.org>
References: <alpine.DEB.2.02.1807172221240.3741@tarski.funk>
 <2cca8874-11a4-a201-d766-281447b2787b@durchholz.org>
Message-ID: <5O48-BuLzTKymcFGkglDIwMCC3DNutWti1uaqfzny-NNRBYGw0_Fyuv8v7Od1t1i8fovFRfZTmjrLQlcQz3XhMN0FEMv-2yblhAQrAnK198=@pm.me>

There is more to this picture.  If you have a set G then lists of elements of G is the free monoid.  You get a list only because the category of sets is monoidal with the monoidal product the cartesian product.   The same construction can be carried to free monads, but in a different category: the monoidal category of endofunctors, where the monoidal product is functor composition, so you'll end up with a recursive thing build in much of the same way.  I recently wrote a blog posts about it: https://marcinszamotulski.me/posts/free-monads.html - if you're not afraid of some mathematics (universal algebra and just a bit of category theory).

Free construction carries all the structure of monoids or monads: having free monoid / monad you can get back `mempty` and `mappend` (or `return` and `join` / `>>=`) for any other monoid / monad.

Best regards,
Marcin


​Sent with ProtonMail Secure Email.​

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On July 17, 2018 10:36 PM, Joachim Durchholz <jo at durchholz.org> wrote:

> Am 17.07.2018 um 22:23 schrieb Olaf Klinke:
> 
> > You could say that every monad harbors a monoid, and that every monoid
> > 
> > arises this way. But of course the whole and the part are not the same.
> 
> Agreed.
> 
> > That depends on the definition of "monoid". If a monoid is a set with
> > 
> > certain structure, then a monad is not a monoid.
> 
> That's the perspective from which I'm looking at abstract data types: A
> 
> set of values, a set of operations, a set of axioms over the operations
> 
> and values.
> 
> Well, that's the textbook definition, there's a lot of data structures
> 
> that have multiple value sets but still are related through axioms. I
> 
> just don't know an example of such a structure that it could make it
> 
> into the textbooks :-)
> 
> From that perspective, monads and monoids are distinct.
> 
> Even fundamentally so: Monad axioms have more type parameters than
> 
> monoid axioms, so they cannot be made isomorphic by clever transformations.
> 
> > > There's also a final argument: If monad and monoid are really the same,
> > > 
> > > why do mathematicians still keep the separate terminology?
> > 
> > Because they are different, as we hopefully agree.
> 
> We do :-)
> 
> Regards,
> 
> Jo
> 
> 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 vlatko.basic at gmail.com  Wed Jul 18 10:41:43 2018
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Wed, 18 Jul 2018 12:41:43 +0200
Subject: [Haskell-cafe] SqlPersistT action in MonadError issue
In-Reply-To: <CA+4qU96=rYojis3=PM5bEtWaW+mxGzE4eX6+Mo5-g-=GdfH21w@mail.gmail.com>
References: <31fe16b5-8ecb-5795-7ba5-58d5cb84a2b2@gmail.com>
 <CA+4qU94_fgEM4O-=-fSVsPD_f8VVSNKdpUhY7E_h_XfcmTxYHg@mail.gmail.com>
 <cedd8721-f9ab-a82d-4543-3b74eba56a1a@gmail.com>
 <CA+4qU96=rYojis3=PM5bEtWaW+mxGzE4eX6+Mo5-g-=GdfH21w@mail.gmail.com>
Message-ID: <59b34c53-f082-f270-553b-e4b4750f00d8@gmail.com>

Thank you Matt



> -------- Original Message --------
> Subject: Re: [Haskell-cafe] SqlPersistT action in MonadError issue
> From: Matt <parsonsmatt at gmail.com>
> To: Vlatko Bašić <vlatko.basic at gmail.com>
> Cc: haskell-cafe <Haskell-cafe at haskell.org>
> Date: 16/07/18 17:25
>
>
> Hi Vlatko,
>
> It depends on what you want to happen. The easiest way is to use the runtime 
> exception system and `try` to catch the type of exception you want to handle:
>
> tryApp :: (MonadCatch m) => m a -> m (Either AppException a)
> tryApp = try
>
> runDB :: (MonadIO m, MonadCatch m) => SqlPersistT m a -> AppM m (Either 
> AppException a)
> runDB query = do
>   App{..} <- ask
>   liftIO $ tryApp $ runPool pgConf query pgPool
>
> f1 :: (MonadThrow m) => SqlPersistT m Bool
> f1 = throwM (ExcTest "Exception!")
>
> runF1 :: (MonadIO m, MonadCatch m) => AppM m (Either AppException Bool)
> runF1 = runDB f1
>
> This approach preserves the transaction rollback feature of `persistent`. If 
> you do not want to have that feature, then you can put `ExceptT` on the 
> outside, like `ExceptT AppException (SqlPersistT m) a`, and this will give you 
> short-circuiting (via the outer ExceptT layer).
>
>
> Matt Parsons
>
> On Mon, Jul 16, 2018 at 2:18 AM, Vlatko Basic <vlatko.basic at gmail.com 
> <mailto:vlatko.basic at gmail.com>> wrote:
>
>     Hi Matt,
>
>     Thanks for taking time and giving so thorough explanation and a
>     suggestion. Much appreciated. :-)
>
>     I figured out some of this, except for the last, main part. I thought the
>     problem was in not being able to instantiate MonadError AppException IO,
>     not that ExceptT doesn't have MonadUnliftIO.
>
>     I'm refactoring some db code and was just exploring possible
>     short-circuiting ways in SqlPersistT with custom exception types, like
>     get404.
>     Which approach would you suggest for that?
>
>
>
>     vlatko
>
>
>>     -------- Original Message --------
>>     Subject: Re: [Haskell-cafe] SqlPersistT action in MonadError issue
>>     From: Matt <parsonsmatt at gmail.com> <mailto:parsonsmatt at gmail.com>
>>     To: vlatko.basic at gmail.com <mailto:vlatko.basic at gmail.com>
>>     Cc: haskell-cafe <Haskell-cafe at haskell.org> <mailto:Haskell-cafe at haskell.org>
>>     Date: 14/07/18 20:09
>>
>>
>>     The type of `runPool` is given here:
>>     https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#v:runPool
>>     <https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#v:runPool>
>>
>>
>>     runPool::MonadUnliftIO
>>     <https://www.stackage.org/haddock/lts-12.0/conduit-1.3.0.3/Conduit.html#t:MonadUnliftIO>m
>>     => c ->PersistConfigBackend
>>     <https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#t:PersistConfigBackend>c
>>     m a ->PersistConfigPool
>>     <https://www.stackage.org/haddock/lts-12.0/persistent-2.8.2/Database-Persist-Class.html#t:PersistConfigPool>c
>>     -> m a
>>
>>     The return type of `runPool`, then, is `m a`, for some `m` satisfying
>>     `MonadUnliftIO`.
>>
>>     The type of `liftIO` is `liftIO :: (MonadIO m) => IO a -> m a`. This
>>     means that the first argument to `liftIO` must be an `IO a`.
>>
>>     When we say `liftIO (runPool ...)`, GHC tries to unify the `m a` from
>>     `runPool` and the `IO a` from `liftIO`. It is able to do this, as `IO` is
>>     an instance of `MonadUnliftIO`. Then, the concrete type of `runPool
>>     pgConf f1 pgPool` becomes `IO Bool`.
>>
>>     GHC now tries to unify the `m` in `f1 :: (MonadIO m, MonadError
>>     AppException m) => SqlPersistT m Bool` with `IO`. It tries to satisfy the
>>     constraints: `MonadIO` is easily satisfied, but `MonadError AppException
>>     m` triggers the problem you mention.
>>
>>     Because `ExceptT` does not have an instance for `MonadUnliftIO`, we
>>     cannot use it with the `m` in `SqlPersistT m Bool` directly. We can,
>>     instead, use `mapReaderT` to push the `Either` into the return type, like
>>     this:
>>
>>     pushException :: SqlPersistT (ExceptT e m) a -> SqlPersistT m (Either e a)
>>     pushException = mapReaderT runExceptT
>>
>>
>>     Now, we can write:
>>
>>     liftIO $ runPool pgConf (pushException f1) pgPool
>>
>>     This gives us an `IO (Either AppException Bool)`, which, after lifting,
>>     gives us `AppM IO (Either AppException Bool)`. You can then use `either
>>     throwError pure` to pull the `AppException` into the `ExceptT` again.
>>
>>     ---
>>
>>     I would suggest that you reconsider this approach, however. The
>>     `persistent` library uses transactions and exceptions in a way that is
>>     *almost always* what you want, but can be surprising, and using `ExceptT`
>>     will break this system. Transactions are automatically rolled back on a
>>     `MonadCatch`-style exception, but they are not automatically rolled back
>>     on an `ExceptT`-style exception. Having a single `AppException` type that
>>     represents errors that can occur in database transactions *and* the rest
>>     of your application is also going to be a cause for unsafety and errors,
>>     as the type cannot possibly be precise enough to provide any safety.
>>
>>
>>     Matt Parsons
>>
>>     On Sat, Jul 14, 2018 at 10:22 AM, Vlatko Basic <vlatko.basic at gmail.com
>>     <mailto:vlatko.basic at gmail.com>> wrote:
>>
>>         Hello,
>>
>>         I'm trying to use SqlPersistT funcs with MonadError, but am failing
>>         in writing the runDB correctly.
>>
>>         I tried several things, but always getting:
>>
>>             • Couldn't match type ‘IOException’ with ‘AppException’
>>                 arising from a functional dependency between:
>>                   constraint ‘MonadError AppException IO’ arising from a use
>>         of ‘f1’
>>                   instance ‘MonadError IOException IO’ at <no location info>
>>             • In the second argument of ‘runPool’, namely ‘f1’
>>               In the second argument of ‘($)’, namely ‘runPool pgConf f1 pgPool’
>>               In a stmt of a 'do' block: liftIO $ runPool pgConf f1 pgPool
>>
>>         I understand there already is "instance MonadError IOException IO"
>>         and fundep says it can be only one for IO.
>>
>>         How to make it compile?
>>
>>
>>         Best regards,
>>
>>         vlatko
>>
>>
>>         Here is the minimal reproducible code:
>>
>>         module Test where
>>
>>         import Prelude
>>         import Control.Exception.Base
>>         import Control.Monad.Except
>>         import Control.Monad.Trans.Reader
>>         import Database.Persist.Postgresql
>>
>>         data AppException =
>>             ExcText String
>>           | ExcIO IOException
>>           deriving (Show)
>>
>>         type AppM m = ExceptT AppException (ReaderT App m)
>>         data App    = App { pgConf :: PostgresConf, pgPool :: ConnectionPool}
>>
>>         runDB :: (MonadIO m, MonadError AppException m) => AppM m Bool
>>         runDB = do
>>           App{..} <- lift ask
>>           liftIO $ runPool pgConf *f1* pgPool    -- error
>>           -- liftIO $ runPool pgConf *f2* pgPool  -- OK
>>
>>
>>         f1 :: (MonadIO m, MonadError AppException m) => SqlPersistT m Bool
>>         f1 = throwError $ ExcText "exception"
>>
>>         f2 :: MonadIO m => SqlPersistT m Bool
>>         f2 = return True
>>
>>
>>         _______________________________________________
>>         Haskell-Cafe mailing list
>>         To (un)subscribe, modify options or view archives go to:
>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>>         Only members subscribed via the mailman list are allowed to post.
>>
>>
>
>

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

From rmason at mun.ca  Wed Jul 18 12:12:44 2018
From: rmason at mun.ca (Roger Mason)
Date: Wed, 18 Jul 2018 09:42:44 -0230
Subject: [Haskell-cafe] cannot upgrade stack
Message-ID: <y658t68214z.fsf@mun.ca>

Hello,

I'm attempting to upgrade stack on a FreeBSD 11.1 system but it fails:

stack upgrade
Current Stack version: 1.5.1, available download version: 1.7.1
Newer version detected, downloading
Querying for archive location for platform: freebsd-i386-static
Querying for archive location for platform: freebsd-i386
Exception occured when trying to perform binary upgrade:
Unable to find binary Stack archive for platforms: freebsd-i386-static freebsd-i386
Falling back to source upgrade
Selected mirror https://s3.amazonaws.com/hackage.fpcomplete.com/                                 
Downloading timestamp                                                                            
No updates to your package list were found                                                       
Updating package index Hackage (mirrored at https://s3.amazonaws.com/hackage.fpcomplete.com/) ...Could not parse '/tmp/stack-upgrade2294/stack-1.7.1/stack.yaml':
Aeson exception:
Error in $['extra-deps'][0]: failed to parse field 'extra-deps': (Invalid package identifier: "rio-0.1.1.0 at rev:0","rio-0.1.1.0 at rev:0")
See http://docs.haskellstack.org/en/stable/yaml_configuration/

If it matters, I'm using ghc-8.0.2_3.

Thanks for any help,
Roger

From michael at snoyman.com  Wed Jul 18 12:26:12 2018
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 18 Jul 2018 15:26:12 +0300
Subject: [Haskell-cafe] cannot upgrade stack
In-Reply-To: <y658t68214z.fsf@mun.ca>
References: <y658t68214z.fsf@mun.ca>
Message-ID: <CAKT9ecNaQaCzSrKLGSiq6X9tqE5VM0ayN2PxommH=WsLqaL_tA@mail.gmail.com>

The problem here is that:

* You're on an OS that doesn't have prebuilt binaries (FreeBSD 32-bit)
* The version you're using (1.5.1) isn't compatible with the newer syntax
used in the stack.yaml file for 1.7.1[1]

I'll need to upgrade in two steps: first upgrade to 1.6.1, then to 1.7.1
using that Stack. Something like this should work:

$ git clone https://github.com/commercialhaskell/stack --branch v1.6.1
$ cd stack
$ stack install
# make sure you're using the new stack 1.6.1 binary
$ stack upgrade
# or
$ git checkout v1.7.1
$ stack install

HTH,
Michael

[1] Even if you removed that new syntax, you'll end up running into the
cassava flag bug, so no shortcuts here

On Wed, Jul 18, 2018 at 3:13 PM Roger Mason <rmason at mun.ca> wrote:

> Hello,
>
> I'm attempting to upgrade stack on a FreeBSD 11.1 system but it fails:
>
> stack upgrade
> Current Stack version: 1.5.1, available download version: 1.7.1
> Newer version detected, downloading
> Querying for archive location for platform: freebsd-i386-static
> Querying for archive location for platform: freebsd-i386
> Exception occured when trying to perform binary upgrade:
> Unable to find binary Stack archive for platforms: freebsd-i386-static
> freebsd-i386
> Falling back to source upgrade
> Selected mirror https://s3.amazonaws.com/hackage.fpcomplete.com/
>
> Downloading timestamp
>
> No updates to your package list were found
>
> Updating package index Hackage (mirrored at
> https://s3.amazonaws.com/hackage.fpcomplete.com/) ...Could not parse
> '/tmp/stack-upgrade2294/stack-1.7.1/stack.yaml':
> Aeson exception:
> Error in $['extra-deps'][0]: failed to parse field 'extra-deps': (Invalid
> package identifier: "rio-0.1.1.0 at rev:0","rio-0.1.1.0 at rev:0")
> See http://docs.haskellstack.org/en/stable/yaml_configuration/
>
> If it matters, I'm using ghc-8.0.2_3.
>
> Thanks for any help,
> Roger
> _______________________________________________
> 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/20180718/ccf9240c/attachment.html>

From rmason at mun.ca  Wed Jul 18 14:06:53 2018
From: rmason at mun.ca (Roger Mason)
Date: Wed, 18 Jul 2018 11:36:53 -0230
Subject: [Haskell-cafe] cannot upgrade stack
In-Reply-To: <CAKT9ecNaQaCzSrKLGSiq6X9tqE5VM0ayN2PxommH=WsLqaL_tA@mail.gmail.com>
References: <y658t68214z.fsf@mun.ca>
 <CAKT9ecNaQaCzSrKLGSiq6X9tqE5VM0ayN2PxommH=WsLqaL_tA@mail.gmail.com>
Message-ID: <y657els1vuq.fsf@mun.ca>

Hello,

Michael Snoyman <michael at snoyman.com> writes:

> The problem here is that:
>
> * You're on an OS that doesn't have prebuilt binaries (FreeBSD 32-bit)
> * The version you're using (1.5.1) isn't compatible with the newer syntax
> used in the stack.yaml file for 1.7.1[1]
>
> I'll need to upgrade in two steps: first upgrade to 1.6.1, then to 1.7.1
> using that Stack. Something like this should work:
>
> $ git clone https://github.com/commercialhaskell/stack --branch v1.6.1
> $ cd stack
> $ stack install
> # make sure you're using the new stack 1.6.1 binary

Everything works to here.
stack --version
Version 1.6.1, Git revision f25811329bbc40b0c21053a8160c56f923e1201b (5435 commits) i386 hpack-0.20.0

> $ stack upgrade

stack upgrade
zsh: bus error (core dumped)  stack upgrade

> # or
> $ git checkout v1.7.1
> $ stack install

Hoping for a miracle:

stack install
Downloading lts-11.6 build plan ...zsh: bus error (core dumped)  stack
install

oops!  No miracle.

Thanks for helping.

Roger

From 6yearold at gmail.com  Wed Jul 18 18:22:33 2018
From: 6yearold at gmail.com (Gleb Popov)
Date: Wed, 18 Jul 2018 21:22:33 +0300
Subject: [Haskell-cafe] cannot upgrade stack
In-Reply-To: <y657els1vuq.fsf@mun.ca>
References: <y658t68214z.fsf@mun.ca>
 <CAKT9ecNaQaCzSrKLGSiq6X9tqE5VM0ayN2PxommH=WsLqaL_tA@mail.gmail.com>
 <y657els1vuq.fsf@mun.ca>
Message-ID: <CALH631muW+pB=B7Z1DToZRdUO7W+RnySaauWMT6Vi3hAmk93ew@mail.gmail.com>

On Wed, Jul 18, 2018 at 5:06 PM, Roger Mason <rmason at mun.ca> wrote:

> Hello,
>
> Michael Snoyman <michael at snoyman.com> writes:
>
> > The problem here is that:
> >
> > * You're on an OS that doesn't have prebuilt binaries (FreeBSD 32-bit)
> > * The version you're using (1.5.1) isn't compatible with the newer syntax
> > used in the stack.yaml file for 1.7.1[1]
> >
> > I'll need to upgrade in two steps: first upgrade to 1.6.1, then to 1.7.1
> > using that Stack. Something like this should work:
> >
> > $ git clone https://github.com/commercialhaskell/stack --branch v1.6.1
> > $ cd stack
> > $ stack install
> > # make sure you're using the new stack 1.6.1 binary
>
> Everything works to here.
> stack --version
> Version 1.6.1, Git revision f25811329bbc40b0c21053a8160c56f923e1201b
> (5435 commits) i386 hpack-0.20.0
>
> > $ stack upgrade
>
> stack upgrade
> zsh: bus error (core dumped)  stack upgrade
>
> > # or
> > $ git checkout v1.7.1
> > $ stack install
>
> Hoping for a miracle:
>
> stack install
> Downloading lts-11.6 build plan ...zsh: bus error (core dumped)  stack
> install
>
> oops!  No miracle.
>
> Thanks for helping.
>

Why don't you use FreeBSD ports/packages to install stack?


> Roger
> _______________________________________________
> 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/20180718/f534f116/attachment.html>

From clintonmead at gmail.com  Thu Jul 19 03:19:13 2018
From: clintonmead at gmail.com (Clinton Mead)
Date: Thu, 19 Jul 2018 13:19:13 +1000
Subject: [Haskell-cafe] Backpack vs plain old classes and instances
Message-ID: <CAFDVgwE8G1=i+sCtsCdjS9XgYG3+kOvWiHXLjOF6786XBfR1Vg@mail.gmail.com>

Hi All

I read though Edward Z. Yang's blog post
<http://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/> about Backpack
but I can't understand what it does above and beyond classes and instances.

It seems to me we could just replace a "signature" with a "class" and a
"unit" with an "instance" and achieve the same thing.

Of course there are issues with orphans instances if we don't own either
the class or the associated data, but it would seem to me that "orphan
units" are no less problematic than "orphan instances".

Edward Kmett's unpacked-containers
<https://www.reddit.com/r/haskell/comments/8a5w1n/new_package_unpackedcontainers/>
gets
some speed improvements using Backpack, but is Backpack just optimisation
thing, or are there ways you can organise code with Backpack  that you
couldn't do without just classes and instances? For example, does Backpack
solve the issue of packages requiring huge dependency lists to implement
instances that most of their users will not use?

Thanks,
Clinton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180719/8e1d9bef/attachment.html>

From vanessa.mchale at iohk.io  Thu Jul 19 03:44:16 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Wed, 18 Jul 2018 22:44:16 -0500
Subject: [Haskell-cafe] Backpack vs plain old classes and instances
In-Reply-To: <CAFDVgwE8G1=i+sCtsCdjS9XgYG3+kOvWiHXLjOF6786XBfR1Vg@mail.gmail.com>
References: <CAFDVgwE8G1=i+sCtsCdjS9XgYG3+kOvWiHXLjOF6786XBfR1Vg@mail.gmail.com>
Message-ID: <e8c4a889-7c0d-a74e-bc16-bb489ac27cd2@iohk.io>

A module signature can contain data types, and the units can contain the
concrete data types. This allows e.g. a common interface for all string
packages: https://github.com/haskell-backpack/backpack-str

As you can see (particularly here:
https://github.com/haskell-backpack/backpack-str/blob/master/str-sig/Str.hsig#L237),
one can let the *type* vary in a way that typeclasses do not allow.

On 07/18/2018 10:19 PM, Clinton Mead wrote:
> Hi All
>
> I read though Edward Z. Yang's blog post
> <http://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/> about
> Backpack but I can't understand what it does above and beyond classes
> and instances.
>
> It seems to me we could just replace a "signature" with a "class" and
> a "unit" with an "instance" and achieve the same thing. 
>
> Of course there are issues with orphans instances if we don't own
> either the class or the associated data, but it would seem to me that
> "orphan units" are no less problematic than "orphan instances". 
>
> Edward Kmett's unpacked-containers
> <https://www.reddit.com/r/haskell/comments/8a5w1n/new_package_unpackedcontainers/> gets
> some speed improvements using Backpack, but is Backpack just
> optimisation thing, or are there ways you can organise code with
> Backpack  that you couldn't do without just classes and instances? For
> example, does Backpack solve the issue of packages requiring huge
> dependency lists to implement instances that most of their users will
> not use?
>
> Thanks,
> Clinton
>
>
> _______________________________________________
> 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/20180718/0b722f0f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180718/0b722f0f/attachment.sig>

From clintonmead at gmail.com  Thu Jul 19 05:12:36 2018
From: clintonmead at gmail.com (Clinton Mead)
Date: Thu, 19 Jul 2018 15:12:36 +1000
Subject: [Haskell-cafe] Backpack vs plain old classes and instances
In-Reply-To: <e8c4a889-7c0d-a74e-bc16-bb489ac27cd2@iohk.io>
References: <CAFDVgwE8G1=i+sCtsCdjS9XgYG3+kOvWiHXLjOF6786XBfR1Vg@mail.gmail.com>
 <e8c4a889-7c0d-a74e-bc16-bb489ac27cd2@iohk.io>
Message-ID: <CAFDVgwEobDu2LBnhWD5ohYEG=67ySa-o9NMtfYcZiFxOb5jj=A@mail.gmail.com>

Hi Vanessa

Sorry, I still can't understand what backpack is doing beyond classes and
instances.

map-classes
<http://hackage.haskell.org/package/map-classes-0.1.0.0/docs/Control-Class-Impl-Map.html>
gives
a common interface for key-value maps (i.e. arrays, maps, hashmaps, etc),
just using classes and interfaces. Indeed this seems to be what classes
were designed to do, for example, the IArray class gives a common interface
over int index immutable arrays.

I'm missing something obviously. How can the type "vary" in a way type
classes does not allow? Couldn't the code you referenced just be a three
parameter type class?

Thanks,
Clinton

On Thu, Jul 19, 2018 at 1:44 PM, Vanessa McHale <vanessa.mchale at iohk.io>
wrote:

> A module signature can contain data types, and the units can contain the
> concrete data types. This allows e.g. a common interface for all string
> packages: https://github.com/haskell-backpack/backpack-str
>
> As you can see (particularly here: https://github.com/haskell-
> backpack/backpack-str/blob/master/str-sig/Str.hsig#L237), one can let the
> *type* vary in a way that typeclasses do not allow.
>
>
> On 07/18/2018 10:19 PM, Clinton Mead wrote:
>
> Hi All
>
> I read though Edward Z. Yang's blog post
> <http://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/> about
> Backpack but I can't understand what it does above and beyond classes and
> instances.
>
> It seems to me we could just replace a "signature" with a "class" and a
> "unit" with an "instance" and achieve the same thing.
>
> Of course there are issues with orphans instances if we don't own either
> the class or the associated data, but it would seem to me that "orphan
> units" are no less problematic than "orphan instances".
>
> Edward Kmett's unpacked-containers
> <https://www.reddit.com/r/haskell/comments/8a5w1n/new_package_unpackedcontainers/>
>  gets some speed improvements using Backpack, but is Backpack just
> optimisation thing, or are there ways you can organise code with Backpack
> that you couldn't do without just classes and instances? For example, does
> Backpack solve the issue of packages requiring huge dependency lists to
> implement instances that most of their users will not use?
>
> Thanks,
> Clinton
>
>
> _______________________________________________
> 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/20180719/2816fa68/attachment.html>

From michael at snoyman.com  Thu Jul 19 05:15:20 2018
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 19 Jul 2018 08:15:20 +0300
Subject: [Haskell-cafe] cannot upgrade stack
In-Reply-To: <y657els1vuq.fsf@mun.ca>
References: <y658t68214z.fsf@mun.ca>
 <CAKT9ecNaQaCzSrKLGSiq6X9tqE5VM0ayN2PxommH=WsLqaL_tA@mail.gmail.com>
 <y657els1vuq.fsf@mun.ca>
Message-ID: <CAKT9ecMFeZtrEcLewmSwq_Thy6hohYEsUTRTsbPU-9Pm-H6xFw@mail.gmail.com>

Sorry, I'm not sure what's going on there. Are you able to build other
executables with Stack 1.5.1 that run successfully?

On Wed, Jul 18, 2018 at 5:06 PM Roger Mason <rmason at mun.ca> wrote:

> Hello,
>
> Michael Snoyman <michael at snoyman.com> writes:
>
> > The problem here is that:
> >
> > * You're on an OS that doesn't have prebuilt binaries (FreeBSD 32-bit)
> > * The version you're using (1.5.1) isn't compatible with the newer syntax
> > used in the stack.yaml file for 1.7.1[1]
> >
> > I'll need to upgrade in two steps: first upgrade to 1.6.1, then to 1.7.1
> > using that Stack. Something like this should work:
> >
> > $ git clone https://github.com/commercialhaskell/stack --branch v1.6.1
> > $ cd stack
> > $ stack install
> > # make sure you're using the new stack 1.6.1 binary
>
> Everything works to here.
> stack --version
> Version 1.6.1, Git revision f25811329bbc40b0c21053a8160c56f923e1201b (5435
> commits) i386 hpack-0.20.0
>
> > $ stack upgrade
>
> stack upgrade
> zsh: bus error (core dumped)  stack upgrade
>
> > # or
> > $ git checkout v1.7.1
> > $ stack install
>
> Hoping for a miracle:
>
> stack install
> Downloading lts-11.6 build plan ...zsh: bus error (core dumped)  stack
> install
>
> oops!  No miracle.
>
> Thanks for helping.
>
> Roger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180719/1fa81a46/attachment.html>

From silvio.frischi at gmail.com  Thu Jul 19 06:20:00 2018
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Thu, 19 Jul 2018 08:20:00 +0200
Subject: [Haskell-cafe] Backpack vs plain old classes and instances
In-Reply-To: <CAFDVgwEobDu2LBnhWD5ohYEG=67ySa-o9NMtfYcZiFxOb5jj=A@mail.gmail.com>
References: <CAFDVgwE8G1=i+sCtsCdjS9XgYG3+kOvWiHXLjOF6786XBfR1Vg@mail.gmail.com>
 <e8c4a889-7c0d-a74e-bc16-bb489ac27cd2@iohk.io>
 <CAFDVgwEobDu2LBnhWD5ohYEG=67ySa-o9NMtfYcZiFxOb5jj=A@mail.gmail.com>
Message-ID: <b60bcc6a-f413-788a-3b28-6ed6be7aeb8d@gmail.com>

Hi

It seems similar to the modules system of ML. As I understand it, the
main difference to Haskell type classes is that you have to specify
instances explicitly in in this system. This means you get more control
at the expense of more code.

Have a look at this example on stackoverflow.

https://stackoverflow.com/a/36927542/1117884

Cheers

Silvio


From whosekiteneverfly at gmail.com  Thu Jul 19 06:29:25 2018
From: whosekiteneverfly at gmail.com (Yuji Yamamoto)
Date: Thu, 19 Jul 2018 15:29:25 +0900
Subject: [Haskell-cafe] Access violation when stack haddock haskell-src-exts
	since LTS 12.0
Message-ID: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>

I always get an " Access violation in generated code when reading
0x28900000" error when
executing

> stack haddock haskell-src-exts

since LTS 12.0.

I'm not sure to which project I should submit a bug report.
GHC? Haddock? Or Stack?
And how can I make a smaller case  to reproduce the same error?

I  attached a log when executing with --verbose --cabal-verbose for your
info.

-- 
山本悠滋
twitter: @igrep
GitHub: https://github.com/igrep
GitLab: https://gitlab.com/igrep
Facebook: http://www.facebook.com/igrep
Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180719/0345d78c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stack-haddock-error.log
Type: application/octet-stream
Size: 27858 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180719/0345d78c/attachment.obj>

From clintonmead at gmail.com  Thu Jul 19 07:46:52 2018
From: clintonmead at gmail.com (Clinton Mead)
Date: Thu, 19 Jul 2018 17:46:52 +1000
Subject: [Haskell-cafe] Backpack vs plain old classes and instances
In-Reply-To: <b60bcc6a-f413-788a-3b28-6ed6be7aeb8d@gmail.com>
References: <CAFDVgwE8G1=i+sCtsCdjS9XgYG3+kOvWiHXLjOF6786XBfR1Vg@mail.gmail.com>
 <e8c4a889-7c0d-a74e-bc16-bb489ac27cd2@iohk.io>
 <CAFDVgwEobDu2LBnhWD5ohYEG=67ySa-o9NMtfYcZiFxOb5jj=A@mail.gmail.com>
 <b60bcc6a-f413-788a-3b28-6ed6be7aeb8d@gmail.com>
Message-ID: <CAFDVgwE15xa6iSrSh=-9n==Dy2+K9K0WobBim7t8j-_+OgUs1A@mail.gmail.com>

Hi Silvio

That makes a lot of sense thanks for the reply!

Thanks,
Clinton

On Thu, Jul 19, 2018 at 4:20 PM, Silvio Frischknecht <
silvio.frischi at gmail.com> wrote:

> Hi
>
> It seems similar to the modules system of ML. As I understand it, the
> main difference to Haskell type classes is that you have to specify
> instances explicitly in in this system. This means you get more control
> at the expense of more code.
>
> Have a look at this example on stackoverflow.
>
> https://stackoverflow.com/a/36927542/1117884
>
> Cheers
>
> Silvio
>
> _______________________________________________
> 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/20180719/4e79a5f8/attachment-0001.html>

From rmason at mun.ca  Thu Jul 19 09:11:44 2018
From: rmason at mun.ca (Roger Mason)
Date: Thu, 19 Jul 2018 06:41:44 -0230
Subject: [Haskell-cafe] cannot upgrade stack
In-Reply-To: <CAKT9ecMFeZtrEcLewmSwq_Thy6hohYEsUTRTsbPU-9Pm-H6xFw@mail.gmail.com>
References: <y658t68214z.fsf@mun.ca>
 <CAKT9ecNaQaCzSrKLGSiq6X9tqE5VM0ayN2PxommH=WsLqaL_tA@mail.gmail.com>
 <y657els1vuq.fsf@mun.ca>
 <CAKT9ecMFeZtrEcLewmSwq_Thy6hohYEsUTRTsbPU-9Pm-H6xFw@mail.gmail.com>
Message-ID: <y65a7qnvbcf.fsf@mun.ca>

Hello,

Michael Snoyman <michael at snoyman.com> writes:

> Sorry, I'm not sure what's going on there. Are you able to build other
> executables with Stack 1.5.1 that run successfully?
>

I have not tried.

However, it looks like 1.7.1 is now in the freeBSD ports tree, as of an
update I made yesterday.  I will give that a try.

Many thanks again for your help.

Roger

From rmason at mun.ca  Thu Jul 19 09:14:14 2018
From: rmason at mun.ca (Roger Mason)
Date: Thu, 19 Jul 2018 06:44:14 -0230
Subject: [Haskell-cafe] cannot upgrade stack
In-Reply-To: <CALH631muW+pB=B7Z1DToZRdUO7W+RnySaauWMT6Vi3hAmk93ew@mail.gmail.com>
References: <y658t68214z.fsf@mun.ca>
 <CAKT9ecNaQaCzSrKLGSiq6X9tqE5VM0ayN2PxommH=WsLqaL_tA@mail.gmail.com>
 <y657els1vuq.fsf@mun.ca>
 <CALH631muW+pB=B7Z1DToZRdUO7W+RnySaauWMT6Vi3hAmk93ew@mail.gmail.com>
Message-ID: <y658t67vb89.fsf@mun.ca>

Hello,

Gleb Popov <6yearold at gmail.com> writes:

> Why don't you use FreeBSD ports/packages to install stack?

Well, I only just saw yesterday that Stack 1.7.1 is now in the ports
tree, following an update.  The version I built before that (1.5.1) was
too old.

Thanks for the suggestion!

Roger

From vanessa.mchale at iohk.io  Thu Jul 19 10:37:22 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Thu, 19 Jul 2018 05:37:22 -0500
Subject: [Haskell-cafe] Access violation when stack haddock
 haskell-src-exts since LTS 12.0
In-Reply-To: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
References: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
Message-ID: <c83aa5d4-eda1-f682-eb91-44eaa0ac25f8@iohk.io>

What happens when you run `cabal new-haddock`? That will give you more
information about whether it's a bug in haddock or in stack.


On 07/19/2018 01:29 AM, Yuji Yamamoto wrote:
> I always get an " Access violation in generated code when reading
> 0x28900000" error when
> executing
>
> > stack haddock haskell-src-exts
>
> since LTS 12.0.
>
> I'm not sure to which project I should submit a bug report.
> GHC? Haddock? Or Stack?
> And how can I make a smaller case  to reproduce the same error?
>
> I  attached a log when executing with --verbose --cabal-verbose for
> your info.
>
> -- 
> 山本悠滋
> twitter: @igrep
> GitHub: https://github.com/igrep
> GitLab: https://gitlab.com/igrep
> Facebook: http://www.facebook.com/igrep
> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>
>
> _______________________________________________
> 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/20180719/78dd97db/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180719/78dd97db/attachment.sig>

From michael at snoyman.com  Thu Jul 19 13:35:21 2018
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 19 Jul 2018 16:35:21 +0300
Subject: [Haskell-cafe] Access violation when stack haddock
 haskell-src-exts since LTS 12.0
In-Reply-To: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
References: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
Message-ID: <CAKT9ecO3Q4NqXXzkyEE3XaK6UMfx+XKF7zKXkFnEVxHSgqq9Aw@mail.gmail.com>

Given that the haddock.exe executable itself is crashing, it seems highly
unlikely to be a bug in either Stack or Cabal. I can think of three
possibilities here:

* There's a bug in Haddock itself, such as an FFI call or some embedded C
code
* There's a bug in GHC which is generating invalid code
* The GHC bindist itself has included a corrupted haddock.exe

I agree with Vanessa: trying to reproduce this with another build tool
(`cabal haddock` or `cabal new-haddock`) would be a good next step,
followed by a bug report against (most likely) GHC.

On Thu, Jul 19, 2018 at 9:29 AM Yuji Yamamoto <whosekiteneverfly at gmail.com>
wrote:

> I always get an " Access violation in generated code when reading
> 0x28900000" error when
> executing
>
> > stack haddock haskell-src-exts
>
> since LTS 12.0.
>
> I'm not sure to which project I should submit a bug report.
> GHC? Haddock? Or Stack?
> And how can I make a smaller case  to reproduce the same error?
>
> I  attached a log when executing with --verbose --cabal-verbose for your
> info.
>
> --
> 山本悠滋
> twitter: @igrep
> GitHub: https://github.com/igrep
> GitLab: https://gitlab.com/igrep
> Facebook: http://www.facebook.com/igrep
> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
> _______________________________________________
> 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/20180719/02ed82cd/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Jul 19 14:14:03 2018
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 19 Jul 2018 15:14:03 +0100
Subject: [Haskell-cafe] Defining operators via sections
Message-ID: <20180719141403.2kd4ygkhnckqscvp@weber>

I can define operators directly or through their parenthesised name:

> let x .+ y = x + y
> let (.+) x y = (+) x y
> let (.+) x = (+) x
> let (.+) = (.+)

but I can't define them via sections:

> let (x .+) = (x +)
<interactive>:11:6: Parse error in pattern: x .+
> let (.+ y) = (+ y)
<interactive>:12:6: Parse error in pattern: .+ y

It seems natural to write, for example

    instance Monad Maybe where
      ...
      (>>= f) = \case
        Nothing -> Nothing
        Just a  -> f a

Is there any particular reason this is not possible?  Thanks,

Tom

From profunctor at pm.me  Thu Jul 19 18:16:24 2018
From: profunctor at pm.me (Marcin Szamotulski)
Date: Thu, 19 Jul 2018 14:16:24 -0400
Subject: [Haskell-cafe] Monads because of I/O?
In-Reply-To: <63d11200-5584-59ef-1f62-eb692784e517@gmail.com>
References: <alpine.DEB.2.02.1807152131280.3608@tarski.funk>
 <63d11200-5584-59ef-1f62-eb692784e517@gmail.com>
Message-ID: <RyEeEMKqDy4iIbUsl1B38OpdwsRo525qE7SRzGW5iLYgD7VNmWBv8vA9sG5P0_Ahfn5oqz-6iCYwQLQI3leovITwnJp8r_uIKbIFaH3zT2A=@pm.me>

Nicely written.  To add to this monad transformers are ... monads them selves! e.g. `StateT s` is left adjoint functor from the category of monads to the category of monads which satisfy the `MonadState s m` constraint, the right adjoin is a forgetful functor. 

The essential parts of the proof are here: https://github.com/coot/free-algebras/blob/master/src/Control/Algebra/Free.hs#L273

Cheers,
Marcin

@me_coot on twitter


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On July 16, 2018 9:56 AM, PY <aquagnu at gmail.com> wrote:

> Hello, Olaf! It's very good point. I'll read more about it. May be I'm
> 
> wrong, but I don't remember any monads in CT, so my suggestion was that
> 
> they were introduced in pure functional languages research (Hope,
> 
> Haskell), not math itself. May be I'm not right. Thanks a lot!
> 
> 15.07.2018 23:06, Olaf Klinke wrote:
> 
> > Paul,
> > 
> > monads were not invented because I/O could not be presented in another
> > 
> > way in Haskell. Monads are way older than Haskell. It is a concept of
> > 
> > category theory which was developed in the 1950s. Actually some
> > 
> > concepts of algebra that are even older turn out to be monads. Take
> > 
> > Galois theory for example. Once you know the pattern, you find a monad
> > 
> > under every stone you turn around. It's one of the luckiest things
> > 
> > that people like Moggi and Wadler realized that monads can be applied
> > 
> > to structure programs. And don't blame them that monads are not
> > 
> > composable - it is simply a mathematical fact. Some monads do compose
> > 
> > with any other monad, and those are the monad transformers.
> > 
> > If you like Prolog's relational programming model so much, then you
> > 
> > should play with those programs that have "no business value". Because
> > 
> > Haskell's type inference algorithm, together with multi-parameter type
> > 
> > classes and maybe type level natural numbers together give rise to
> > 
> > Prolog-like capabilities. All the work is done by the compiler this way.
> > 
> > What you say about FSM is certainly true to some extent - they are
> > 
> > well understood, can be generated automatically, and there is decent
> > 
> > theory to reason about them. That is why this model is used in
> > 
> > safety-sensitive environments such as aviation. I once applied for a
> > 
> > position in verification in the automotive industry, and the interview
> > 
> > partner told me that they struggle mightily with the vast state spaces
> > 
> > of the FSMs they are checking.
> > 
> > All this speaks in favour of Haskell. The semantics is simple and
> > 
> > beautiful, because it is a single-paradigm language. And because of
> > 
> > that, clever people can leverage theorem provers to mathematically
> > 
> > prove correctness of Haskell code. I don't know of many languages
> > 
> > where that is possible. (But then, I'm not an expert on verification.)
> > 
> > Olaf
> 
> 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 whosekiteneverfly at gmail.com  Fri Jul 20 08:29:18 2018
From: whosekiteneverfly at gmail.com (Yuji Yamamoto)
Date: Fri, 20 Jul 2018 17:29:18 +0900
Subject: [Haskell-cafe] Access violation when stack haddock
 haskell-src-exts since LTS 12.0
In-Reply-To: <CAKT9ecO3Q4NqXXzkyEE3XaK6UMfx+XKF7zKXkFnEVxHSgqq9Aw@mail.gmail.com>
References: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
 <CAKT9ecO3Q4NqXXzkyEE3XaK6UMfx+XKF7zKXkFnEVxHSgqq9Aw@mail.gmail.com>
Message-ID: <CA+6J5GEz59DGMbqxiz2nOkz-pCvzuNqS=PzrCWqdBnU8w8=dNg@mail.gmail.com>

Thank you Michael and Vanessa!

Here're what I've tried and their results:

A. `cabal new-haddock` in a project depending on haskell-src-exts as you
suggested.
    Resulted in another, non-related error..:
    > cabal new-haddock
--with-ghc='C:\Users\yuji-yamamoto\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3\bin\ghc.exe'
    Resolving dependencies...
    Build profile: -w ghc-8.4.3 -O1
    In order, the following will be built (use -v for more details):
     - happy-1.19.9 (exe:happy) (requires build)
     - haskell-src-exts-1.20.2 (lib) (requires build)
     - proceedings-bot-0.1.0.0 (lib) (first run)
    Configuring happy-1.19.9 (all, legacy fallback)...
    cabal.exe: Failed to build happy-1.19.9 (which is required by
    proceedings-bot-0.1.0.0). The failure occurred during the configure
step. The
    exception was:
    output of

C:\Users\yuji-yamamoto\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3\bin\ghc.exe:
    hGetContents: invalid argument (invalid byte sequence)

B. Running a command extracted a log from `stack haddock --verbose
haskell-src-exts`.
    Resulted in the same error

>  C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.2.0.1_ghc-8.4.3.exe
--builddir=.stack-work\dist\7d103d30 haddock --html --hoogle
--haddock-option=--hyperlinked-source --verbose
    ...
    Access violation in generated code when reading 0x36f00000

     Attempting to reconstruct a stack trace...

       Frame        Code address
     * 0x440daf0    0xe63d37
C:\Users\yuji-yamamoto\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3\bin\haddock.exe+0xa63d37
     * 0x440daf8    0x7e1100049f40
C:\Users\yuji-yamamoto\p\cmder_mini\vendor\conemu-maximus5\ConEmu\ConEmuHk64.dll+0x49f40

C. Plus I found `stack haddock` after `stack unpack haskell-src-exts-1.20.2
&& cd  haskell-src-exts-1.20.2
     Sounds weird...

I'm happy if getting some more advice to make smaller case.

Thanks,



2018年7月19日(木) 22:35 Michael Snoyman <michael at snoyman.com>:

> Given that the haddock.exe executable itself is crashing, it seems highly
> unlikely to be a bug in either Stack or Cabal. I can think of three
> possibilities here:
>
> * There's a bug in Haddock itself, such as an FFI call or some embedded C
> code
> * There's a bug in GHC which is generating invalid code
> * The GHC bindist itself has included a corrupted haddock.exe
>
> I agree with Vanessa: trying to reproduce this with another build tool
> (`cabal haddock` or `cabal new-haddock`) would be a good next step,
> followed by a bug report against (most likely) GHC.
>
> On Thu, Jul 19, 2018 at 9:29 AM Yuji Yamamoto <whosekiteneverfly at gmail.com>
> wrote:
>
>> I always get an " Access violation in generated code when reading
>> 0x28900000" error when
>> executing
>>
>> > stack haddock haskell-src-exts
>>
>> since LTS 12.0.
>>
>> I'm not sure to which project I should submit a bug report.
>> GHC? Haddock? Or Stack?
>> And how can I make a smaller case  to reproduce the same error?
>>
>> I  attached a log when executing with --verbose --cabal-verbose for your
>> info.
>>
>> --
>> 山本悠滋
>> twitter: @igrep
>> GitHub: https://github.com/igrep
>> GitLab: https://gitlab.com/igrep
>> Facebook: http://www.facebook.com/igrep
>> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>> _______________________________________________
>> 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.
>
>

-- 
山本悠滋
twitter: @igrep
GitHub: https://github.com/igrep
GitLab: https://gitlab.com/igrep
Facebook: http://www.facebook.com/igrep
Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180720/d619243f/attachment.html>

From profunctor at pm.me  Fri Jul 20 14:13:39 2018
From: profunctor at pm.me (Marcin Szamotulski)
Date: Fri, 20 Jul 2018 10:13:39 -0400
Subject: [Haskell-cafe] Monad laws (Was: Investing in languages (Was:
	What is your favourite Haskell "aha" moment?))
In-Reply-To: <D35CA55A-1409-4D7F-957D-A3E62649E84F@gmail.com>
References: <AM0PR83MB03082E77516AA35BC5955792AD5A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAM7nXecyeqiAB6ytDeZ7Xo19qjJzOj0dKS9pPMVFg0USVJuhzg@mail.gmail.com>
 <dee68717-958d-8ba5-d863-6a044c93e0a8@chreekat.net>
 <CAM7nXef3fvOTqW7dJ0HUy6fPxuN3dNhfgGJ3_UE1MSQyZtx-7w@mail.gmail.com>
 <67d56295-4c9a-5b15-d9a9-21b2ae2f4f63@durchholz.org>
 <20180712064235.ytbzqdbr5pjofqwn@weber>
 <D35CA55A-1409-4D7F-957D-A3E62649E84F@gmail.com>
Message-ID: <ojlsRvoBEMh9cub4CMCdZgFO_FYpgTKxLT_Gr7utrDIOIdaXExZWdLS6hlC_6lZt_HNoTeDOVkP-tnHplU8QfzPJMBQFzUkRKnNreiuozpM=@pm.me>

Hi,

And if you draw the diagrams corresponding to the monad laws for join and return they have exactly the same shape as monoid laws (left and righ unitality and associativity), just the Cartesian product is exchanged for functor composition. It's a nice exercise on it's own to observe this fact so I will leave it here.

Regards,
Marcin

Sent from ProtonMail mobile

-------- Original Message --------
On 12 Jul 2018, 09:06, Alexis King wrote:

>> On Jul 12, 2018, at 01:42, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>>
>>> the monad laws are too hard to read.
>>
>> FWIW the monad laws are not hard to *read* if written in this form
>>
>> return >=> f = f
>> f >=> return = f
>> (f >=> g) >=> h = f >=> (g >=> h)
>>
>> (Whether they're easy to *understand* in that form is another matter.)
>
> Here is another formulation of the monad laws that is less frequently discussed than either of the ones using bind or Kleisli composition:
>
> (1) join . return = id
> (2) join . fmap return = id
> (3) join . join = join . map join
>
> These laws map less obviously to the common ones, but I think they are easier to understand (not least because `join` is closer to the “essence” of what a monad is than >>=). (1) and (2) describe the intuitive notion that adding a layer and squashing it should be the identity function, whether you add the new layer on the outside or on the inside. Likewise, (3) states that if you have three layers and squash them all together, it doesn’t matter whether you squash the inner two or outer two together first.
>
> (Credit goes to HTNW on Stack Overflow for explaining this to me. https://stackoverflow.com/a/45829556/465378)
>
> _______________________________________________
> 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/20180720/42e9aa9b/attachment.html>

From igouy2 at yahoo.com  Fri Jul 20 17:39:19 2018
From: igouy2 at yahoo.com (Isaac Gouy)
Date: Fri, 20 Jul 2018 17:39:19 +0000 (UTC)
Subject: [Haskell-cafe] fyi 10 benchmarks game programs broken
References: <470795843.7925122.1532108359610.ref@mail.yahoo.com>
Message-ID: <470795843.7925122.1532108359610@mail.yahoo.com>

https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/ghc.html

Several of those programs fail to compile:
    Variable not in scope: rdeepseq

For example: 

 https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/fannkuchredux-ghc-5.html#log



best wishes, Isaac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180720/a841ca88/attachment.html>

From astrohavoc at gmail.com  Fri Jul 20 19:42:34 2018
From: astrohavoc at gmail.com (Shao Cheng)
Date: Sat, 21 Jul 2018 03:42:34 +0800
Subject: [Haskell-cafe] Access violation when stack haddock
 haskell-src-exts since LTS 12.0
In-Reply-To: <CA+6J5GEz59DGMbqxiz2nOkz-pCvzuNqS=PzrCWqdBnU8w8=dNg@mail.gmail.com>
References: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
 <CAKT9ecO3Q4NqXXzkyEE3XaK6UMfx+XKF7zKXkFnEVxHSgqq9Aw@mail.gmail.com>
 <CA+6J5GEz59DGMbqxiz2nOkz-pCvzuNqS=PzrCWqdBnU8w8=dNg@mail.gmail.com>
Message-ID: <CAGegzNDkfrspbjgrMr6ZXTqF7d8TdORcRW7JqbniSwyYsCoySw@mail.gmail.com>

Hi Yamamoto-san,

I've encountered the same problem before, and there's a haddock issue
tracking this problem: https://github.com/haskell/haddock/issues/837. A
simple fix is building latest version of haddock and replacing the haddock
binary for ghc-8.4.3.

On Fri, Jul 20, 2018 at 4:29 PM, Yuji Yamamoto <whosekiteneverfly at gmail.com>
wrote:

> Thank you Michael and Vanessa!
>
> Here're what I've tried and their results:
>
> A. `cabal new-haddock` in a project depending on haskell-src-exts as you
> suggested.
>     Resulted in another, non-related error..:
>     > cabal new-haddock --with-ghc='C:\Users\yuji-yamamoto\AppData\Local\
> Programs\stack\x86_64-windows\ghc-8.4.3\bin\ghc.exe'
>     Resolving dependencies...
>     Build profile: -w ghc-8.4.3 -O1
>     In order, the following will be built (use -v for more details):
>      - happy-1.19.9 (exe:happy) (requires build)
>      - haskell-src-exts-1.20.2 (lib) (requires build)
>      - proceedings-bot-0.1.0.0 (lib) (first run)
>     Configuring happy-1.19.9 (all, legacy fallback)...
>     cabal.exe: Failed to build happy-1.19.9 (which is required by
>     proceedings-bot-0.1.0.0). The failure occurred during the configure
> step. The
>     exception was:
>     output of
>     C:\Users\yuji-yamamoto\AppData\Local\Programs\stack\
> x86_64-windows\ghc-8.4.3\bin\ghc.exe:
>     hGetContents: invalid argument (invalid byte sequence)
>
> B. Running a command extracted a log from `stack haddock --verbose
> haskell-src-exts`.
>     Resulted in the same error
>     >  C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.2.0.1_ghc-8.4.3.exe
> --builddir=.stack-work\dist\7d103d30 haddock --html --hoogle
> --haddock-option=--hyperlinked-source --verbose
>     ...
>     Access violation in generated code when reading 0x36f00000
>
>      Attempting to reconstruct a stack trace...
>
>        Frame        Code address
>      * 0x440daf0    0xe63d37 C:\Users\yuji-yamamoto\
> AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3\bin\
> haddock.exe+0xa63d37
>      * 0x440daf8    0x7e1100049f40 C:\Users\yuji-yamamoto\p\
> cmder_mini\vendor\conemu-maximus5\ConEmu\ConEmuHk64.dll+0x49f40
>
> C. Plus I found `stack haddock` after `stack unpack
> haskell-src-exts-1.20.2 && cd  haskell-src-exts-1.20.2
>      Sounds weird...
>
> I'm happy if getting some more advice to make smaller case.
>
> Thanks,
>
>
>
> 2018年7月19日(木) 22:35 Michael Snoyman <michael at snoyman.com>:
>
>> Given that the haddock.exe executable itself is crashing, it seems highly
>> unlikely to be a bug in either Stack or Cabal. I can think of three
>> possibilities here:
>>
>> * There's a bug in Haddock itself, such as an FFI call or some embedded C
>> code
>> * There's a bug in GHC which is generating invalid code
>> * The GHC bindist itself has included a corrupted haddock.exe
>>
>> I agree with Vanessa: trying to reproduce this with another build tool
>> (`cabal haddock` or `cabal new-haddock`) would be a good next step,
>> followed by a bug report against (most likely) GHC.
>>
>> On Thu, Jul 19, 2018 at 9:29 AM Yuji Yamamoto <
>> whosekiteneverfly at gmail.com> wrote:
>>
>>> I always get an " Access violation in generated code when reading
>>> 0x28900000" error when
>>> executing
>>>
>>> > stack haddock haskell-src-exts
>>>
>>> since LTS 12.0.
>>>
>>> I'm not sure to which project I should submit a bug report.
>>> GHC? Haddock? Or Stack?
>>> And how can I make a smaller case  to reproduce the same error?
>>>
>>> I  attached a log when executing with --verbose --cabal-verbose for your
>>> info.
>>>
>>> --
>>> 山本悠滋
>>> twitter: @igrep
>>> GitHub: https://github.com/igrep
>>> GitLab: https://gitlab.com/igrep
>>> Facebook: http://www.facebook.com/igrep
>>> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>>> _______________________________________________
>>> 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.
>>
>>
>
> --
> 山本悠滋
> twitter: @igrep
> GitHub: https://github.com/igrep
> GitLab: https://gitlab.com/igrep
> Facebook: http://www.facebook.com/igrep
> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>
> _______________________________________________
> 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/20180721/b763e339/attachment.html>

From vaibhavsagar at gmail.com  Sun Jul 22 09:48:39 2018
From: vaibhavsagar at gmail.com (Vaibhav Sagar)
Date: Sun, 22 Jul 2018 17:48:39 +0800
Subject: [Haskell-cafe] What is your favourite Haskell "aha" moment?
In-Reply-To: <1c6a08ca-900a-8451-daf3-d0855c902487@htwk-leipzig.de>
References: <1c6a08ca-900a-8451-daf3-d0855c902487@htwk-leipzig.de>
Message-ID: <81d24d78-816c-c221-603e-0ba0c0f49fc0@gmail.com>

I'm late to this discussion, but one aspect of Haskell that really 
impressed me was the idea of *typed holes*, which I think revolutionise 
the act of programming. I tried to communicate my love for them to 
people who mostly don't know Haskell here: 
https://www.youtube.com/watch?v=0oo8wIi2qBE


On 17/07/18 03:28, Johannes Waldmann wrote:
>>   - Large-scale refactoring with types:
>> this is a huge selling point for Haskell in general
> I fully agree with the general idea, but the specific example
>
>> data Shape
>>    = Circle Double
>>    | Square Double
>>    | Rectangle Double Double   -- ^ added
> is not convincing (well, to programmers
> that know about static typing) Think of a Java program
>
> interface Shape { .. }
> class Circle implement Shape { ... }
>
> When you add   class Rectangle {  } ,
> then  Shape foo = new Rectangle ()  would be an error,
>
> until you put   class Rectangle implements Shape {  }
> then the compiler tells you what methods are missing.
>
>
> I think the extra value of types in Haskell
> (for everything, including refactoring)
> is that they tend to express more of the program's properties
> (w.r.t. statically typed imperative programs).
>
> Examples:
>
> the distinction between  a  and  IO a,
> between  IO a  and   STM a.
>
> In  Data.Set, function  "fromList"  has an  Ord  constraint,
> but  "toList"  does not. Does  "singleton"  need the constraint?
> I used this as an exam question just last week.
>
>
> - J.W.
> _______________________________________________
> 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 marc at lamarciana.com  Sun Jul 22 15:27:09 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Sun, 22 Jul 2018 17:27:09 +0200 (CEST)
Subject: [Haskell-cafe] Design of an extensible system
Message-ID: <alpine.LNX.2.21.1807221723310.9946@localhost>

Hi there,

I'm currently programming my first non toy project in Haskell. I come from Ruby
background, where everything is possible no matter how much entropy the
universe gains after you finish your work, so I'm still not sure how to do
certain things without this side-effect :)

I'll try to be concise. My idea is that the project would consist of several
different Haskell packages. The central one, call it Core, would define a
certain data type (with info about certain URLs). Other packages would define
each one an strategy to do something with that data type (processing the URL
info). Each strategy would have its own dependencies, and as a user probably
won't need all of the strategies, I would like to keep them in separated
packages so she or he has no need to download the unneeded stuff.

The problem is that Core should act as the central dashboard, whether through a
CLI or even a web frontend. For example, in the CLI case, I would like to be
able to install Core package along with package StrategyA and package StrategyB
and then do something like the following:

``` 
bash> core --action=fetch --strategy=A
bash> core --action=fetch --strategy=B
```

Two generic ideas come to my mind but I don't know how to translate them
to Haskell:

- Infer module name from the `--strategy` argument and call it dynamically.
   However, as far as I know, in Haskell modules are not first class citizens,
   so no way I can dynamically call them. I have read something to achieve this
   through Template Haskell or through outdaded
   [plugins](http://hackage.haskell.org/package/plugins) package, but I'm not
   sure whether the need is the same and anyway it seems quite unnatural to
   Haskell (I would not like to go against it, but to learn to do thing in its
   way).

- Define from Core some kind of global list where strategy packages can
   register a map between CLI argument value and a defined instance of the core
   data type. But, again, how to do global things in Haskell (and I would prefer
   not to need external tools like RDBMS, filesystem or whatever)? And, anyway,
   surely I don't want to do this because concurrency and everything...

Any idea?

Thanks in advance!

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

From allbery.b at gmail.com  Sun Jul 22 17:50:17 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 22 Jul 2018 13:50:17 -0400
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <alpine.LNX.2.21.1807221723310.9946@localhost>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
Message-ID: <CAKFCL4XKm8G0Y01JGq7vPJhZtjY1gJz8zf0TyOUZVDurG0JfUw@mail.gmail.com>

plugins is outdated because the functionality is now in ghc-api and exposed
in more convenient ways by the hint package. (Some parts of it were always
in ghc-api; plugins provided the parts it originally didn't, notably safe
unloading of modules.) That said, dynamic loading is something of a bad fit
for Haskell; often, the easiest way to do this is to build a new program
including the module and run it in place of the original. See for example
how xmonad configuration works. The dyre package also provides a form of
this.

Another way to do this is to use programs instead of modules, and the Core
driver provides the UI and plumbs the programs together with sockets or
other IPC mechanisms. This is slower in general. (Either way requires some
form of serialization and marshaling of data, so you will have that
overhead regardless.)


On Sun, Jul 22, 2018 at 11:27 AM Marc Busqué <marc at lamarciana.com> wrote:

> Hi there,
>
> I'm currently programming my first non toy project in Haskell. I come from
> Ruby
> background, where everything is possible no matter how much entropy the
> universe gains after you finish your work, so I'm still not sure how to do
> certain things without this side-effect :)
>
> I'll try to be concise. My idea is that the project would consist of
> several
> different Haskell packages. The central one, call it Core, would define a
> certain data type (with info about certain URLs). Other packages would
> define
> each one an strategy to do something with that data type (processing the
> URL
> info). Each strategy would have its own dependencies, and as a user
> probably
> won't need all of the strategies, I would like to keep them in separated
> packages so she or he has no need to download the unneeded stuff.
>
> The problem is that Core should act as the central dashboard, whether
> through a
> CLI or even a web frontend. For example, in the CLI case, I would like to
> be
> able to install Core package along with package StrategyA and package
> StrategyB
> and then do something like the following:
>
> ```
> bash> core --action=fetch --strategy=A
> bash> core --action=fetch --strategy=B
> ```
>
> Two generic ideas come to my mind but I don't know how to translate them
> to Haskell:
>
> - Infer module name from the `--strategy` argument and call it dynamically.
>    However, as far as I know, in Haskell modules are not first class
> citizens,
>    so no way I can dynamically call them. I have read something to achieve
> this
>    through Template Haskell or through outdaded
>    [plugins](http://hackage.haskell.org/package/plugins) package, but I'm
> not
>    sure whether the need is the same and anyway it seems quite unnatural to
>    Haskell (I would not like to go against it, but to learn to do thing in
> its
>    way).
>
> - Define from Core some kind of global list where strategy packages can
>    register a map between CLI argument value and a defined instance of the
> core
>    data type. But, again, how to do global things in Haskell (and I would
> prefer
>    not to need external tools like RDBMS, filesystem or whatever)? And,
> anyway,
>    surely I don't want to do this because concurrency and everything...
>
> Any idea?
>
> Thanks in advance!
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180722/cb194622/attachment.html>

From lonetiger at gmail.com  Sun Jul 22 22:32:49 2018
From: lonetiger at gmail.com (Phyx)
Date: Sun, 22 Jul 2018 23:32:49 +0100
Subject: [Haskell-cafe] GHC, cabal and nightlies via Chocolatey
Message-ID: <CABHktDVove1bFdYtFyXKr+ALdzEDamuhni66bNhPeAK0kTxVTg@mail.gmail.com>

Hi All,

For those that use a cabal based workflow on Windows or are interested in
doing Windows testing for their packages using AppVeyor I've written up
some instructions on how to do this using Chocolatey
https://hub.zhox.com/posts/chocolatey-introduction/.

The standard packages are pulled directly from Haskell.org

As a trial I'm also making my own Windows Nightlies for GHC and Cabal
available via my NuGet package stream.

Details available on the post.

Thanks,
Tamar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180722/60708846/attachment.html>

From whosekiteneverfly at gmail.com  Mon Jul 23 03:49:13 2018
From: whosekiteneverfly at gmail.com (Yuji Yamamoto)
Date: Mon, 23 Jul 2018 12:49:13 +0900
Subject: [Haskell-cafe] Access violation when stack haddock
 haskell-src-exts since LTS 12.0
In-Reply-To: <CAGegzNDkfrspbjgrMr6ZXTqF7d8TdORcRW7JqbniSwyYsCoySw@mail.gmail.com>
References: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
 <CAKT9ecO3Q4NqXXzkyEE3XaK6UMfx+XKF7zKXkFnEVxHSgqq9Aw@mail.gmail.com>
 <CA+6J5GEz59DGMbqxiz2nOkz-pCvzuNqS=PzrCWqdBnU8w8=dNg@mail.gmail.com>
 <CAGegzNDkfrspbjgrMr6ZXTqF7d8TdORcRW7JqbniSwyYsCoySw@mail.gmail.com>
Message-ID: <CA+6J5GH2X9pm528=ee1OYmXemR4f0xTV1zuCzVKrY8JNM7AeBA@mail.gmail.com>

Thank you very much!

I confirmed the replaced haddock executable can successfully generate the
docs!

2018年7月21日(土) 4:42 Shao Cheng <astrohavoc at gmail.com>:

> Hi Yamamoto-san,
>
> I've encountered the same problem before, and there's a haddock issue
> tracking this problem: https://github.com/haskell/haddock/issues/837. A
> simple fix is building latest version of haddock and replacing the haddock
> binary for ghc-8.4.3.
>
> On Fri, Jul 20, 2018 at 4:29 PM, Yuji Yamamoto <
> whosekiteneverfly at gmail.com> wrote:
>
>> Thank you Michael and Vanessa!
>>
>> Here're what I've tried and their results:
>>
>> A. `cabal new-haddock` in a project depending on haskell-src-exts as you
>> suggested.
>>     Resulted in another, non-related error..:
>>     > cabal new-haddock
>> --with-ghc='C:\Users\yuji-yamamoto\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3\bin\ghc.exe'
>>     Resolving dependencies...
>>     Build profile: -w ghc-8.4.3 -O1
>>     In order, the following will be built (use -v for more details):
>>      - happy-1.19.9 (exe:happy) (requires build)
>>      - haskell-src-exts-1.20.2 (lib) (requires build)
>>      - proceedings-bot-0.1.0.0 (lib) (first run)
>>     Configuring happy-1.19.9 (all, legacy fallback)...
>>     cabal.exe: Failed to build happy-1.19.9 (which is required by
>>     proceedings-bot-0.1.0.0). The failure occurred during the configure
>> step. The
>>     exception was:
>>     output of
>>
>> C:\Users\yuji-yamamoto\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3\bin\ghc.exe:
>>     hGetContents: invalid argument (invalid byte sequence)
>>
>> B. Running a command extracted a log from `stack haddock --verbose
>> haskell-src-exts`.
>>     Resulted in the same error
>>
>> >  C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.2.0.1_ghc-8.4.3.exe
>> --builddir=.stack-work\dist\7d103d30 haddock --html --hoogle
>> --haddock-option=--hyperlinked-source --verbose
>>     ...
>>     Access violation in generated code when reading 0x36f00000
>>
>>      Attempting to reconstruct a stack trace...
>>
>>        Frame        Code address
>>      * 0x440daf0    0xe63d37
>> C:\Users\yuji-yamamoto\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3\bin\haddock.exe+0xa63d37
>>      * 0x440daf8    0x7e1100049f40
>> C:\Users\yuji-yamamoto\p\cmder_mini\vendor\conemu-maximus5\ConEmu\ConEmuHk64.dll+0x49f40
>>
>> C. Plus I found `stack haddock` after `stack unpack
>> haskell-src-exts-1.20.2 && cd  haskell-src-exts-1.20.2
>>      Sounds weird...
>>
>> I'm happy if getting some more advice to make smaller case.
>>
>> Thanks,
>>
>>
>>
>> 2018年7月19日(木) 22:35 Michael Snoyman <michael at snoyman.com>:
>>
>>> Given that the haddock.exe executable itself is crashing, it seems
>>> highly unlikely to be a bug in either Stack or Cabal. I can think of three
>>> possibilities here:
>>>
>>> * There's a bug in Haddock itself, such as an FFI call or some embedded
>>> C code
>>> * There's a bug in GHC which is generating invalid code
>>> * The GHC bindist itself has included a corrupted haddock.exe
>>>
>>> I agree with Vanessa: trying to reproduce this with another build tool
>>> (`cabal haddock` or `cabal new-haddock`) would be a good next step,
>>> followed by a bug report against (most likely) GHC.
>>>
>>> On Thu, Jul 19, 2018 at 9:29 AM Yuji Yamamoto <
>>> whosekiteneverfly at gmail.com> wrote:
>>>
>>>> I always get an " Access violation in generated code when reading
>>>> 0x28900000" error when
>>>> executing
>>>>
>>>> > stack haddock haskell-src-exts
>>>>
>>>> since LTS 12.0.
>>>>
>>>> I'm not sure to which project I should submit a bug report.
>>>> GHC? Haddock? Or Stack?
>>>> And how can I make a smaller case  to reproduce the same error?
>>>>
>>>> I  attached a log when executing with --verbose --cabal-verbose for
>>>> your info.
>>>>
>>>> --
>>>> 山本悠滋
>>>> twitter: @igrep
>>>> GitHub: https://github.com/igrep
>>>> GitLab: https://gitlab.com/igrep
>>>> Facebook: http://www.facebook.com/igrep
>>>> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>>>> _______________________________________________
>>>> 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.
>>>
>>>
>>
>> --
>> 山本悠滋
>> twitter: @igrep
>> GitHub: https://github.com/igrep
>> GitLab: https://gitlab.com/igrep
>> Facebook: http://www.facebook.com/igrep
>> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>>
>> _______________________________________________
>> 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.
>>
>
>

-- 
山本悠滋
twitter: @igrep
GitHub: https://github.com/igrep
GitLab: https://gitlab.com/igrep
Facebook: http://www.facebook.com/igrep
Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/679d4f64/attachment.html>

From conal at conal.net  Mon Jul 23 04:29:17 2018
From: conal at conal.net (Conal Elliott)
Date: Sun, 22 Jul 2018 21:29:17 -0700
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
Message-ID: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>

Suppose `g :: forall z. (A,z) -> (B,z)`. Is it necessarily the case that `g
= first f` for some `f :: A -> B` (where `first f (a,b) = (f a, b)`),
perhaps as a free theorem for the type of `g`?

Note that `(A,)` and `(B,)` are functors and that `g` is a natural
transformation, so `g . fmap h == fmap h . g` for any `h :: u -> v`.
Equivalently, `g . second h == second h . g` (where `second h (a,b) = (a, h
b)`).

Thanks,  -- Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180722/169496fa/attachment.html>

From svenpanne at gmail.com  Mon Jul 23 06:27:26 2018
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 23 Jul 2018 08:27:26 +0200
Subject: [Haskell-cafe] Access violation when stack haddock
 haskell-src-exts since LTS 12.0
In-Reply-To: <CA+6J5GH2X9pm528=ee1OYmXemR4f0xTV1zuCzVKrY8JNM7AeBA@mail.gmail.com>
References: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
 <CAKT9ecO3Q4NqXXzkyEE3XaK6UMfx+XKF7zKXkFnEVxHSgqq9Aw@mail.gmail.com>
 <CA+6J5GEz59DGMbqxiz2nOkz-pCvzuNqS=PzrCWqdBnU8w8=dNg@mail.gmail.com>
 <CAGegzNDkfrspbjgrMr6ZXTqF7d8TdORcRW7JqbniSwyYsCoySw@mail.gmail.com>
 <CA+6J5GH2X9pm528=ee1OYmXemR4f0xTV1zuCzVKrY8JNM7AeBA@mail.gmail.com>
Message-ID: <CANBN=msjrNqjFb4wGC6GS6cuPb9XcyicRF=Sewny3W2srOGw2g@mail.gmail.com>

Am Mo., 23. Juli 2018 um 05:49 Uhr schrieb Yuji Yamamoto <
whosekiteneverfly at gmail.com>:

> Thank you very much!
>
> I confirmed the replaced haddock executable can successfully generate the
> docs!
>

Yesterday I had quite some trouble because of the Haddock problem, too, and
I guess I'm not alone: haskell-src-exts has 165 direct reverse
dependencies, so probably hundreds of Hackage packages are affected by
this. The workaround is simple (don't use --haddock with stack), but far
from satisfying and not very obvious.

Given the fact that this affects a very central piece of the Haskell
infrastructure in its latest stable incarnation (GHC 8.4.3): Can we have an
8.4.4 with a fixed Haddock?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/71bbf116/attachment.html>

From nickolay.kudasov at gmail.com  Mon Jul 23 10:28:08 2018
From: nickolay.kudasov at gmail.com (Nickolay Kudasov)
Date: Mon, 23 Jul 2018 13:28:08 +0300
Subject: [Haskell-cafe] Job: Haskell developer at GetShop.TV (interactive
	television platform)
In-Reply-To: <CAF1ivP9wO0cbYX-V=pHUyLMnULnVQyMG4dLZjnCKfhfer1Qcsw@mail.gmail.com>
References: <CAF1ivP9wO0cbYX-V=pHUyLMnULnVQyMG4dLZjnCKfhfer1Qcsw@mail.gmail.com>
Message-ID: <CAF1ivP_u7ar0cJjL-JJNmqqemt1P=YHJvD=3iQZ8GF+6L+00WQ@mail.gmail.com>

Hello, Cafe!

We are seeking a Haskell developer to join our team and help us build an
interactive television platform at scale in Russia! Candidates of all ages,
nationalities, genders, etc. are welcome :) Full-time position in Moscow,
Russia is preferable, but remote/part-time is possible!

Please, feel free to send your CV directly to me via e-mail or via a form
at http://getshop.tv/ourteam/sr-haskell-developer/


GetShop.TV is an interactive television platform that connects viewers with
advertisers and content providers on both live TV and video-on-demand
services. Right now the company is expanding its platform, connecting more
TV channels and operators in Russia. At the same time we are working on
automation and scalability.

Our backend in 100% Haskell (Servant) and some of our internal services
rely on GHCJS (Miso).

We are seeking a senior Haskell developer to help us build a stable,
automated, typesafe service at scale. Some of the challenges and tasks
include
- dealing and optimising for an uneven, spiky, but predictable load
- integration with multiple imperfect services and platforms
- automating processes that aren't automated yet
- improving our automatic reporting system
- performing regular code reviews
- tutoring several junior developers

Some buzzwords that we use are Git Flow, GitHub, Servant (with
servant-swagger), Miso, acid-state, PostgreSQL, hasql, postgresql-query,
hspec, HUnit, QuickCheck, critetion, Circle CI, Ansible, Docker, Telegram
(via telegram-bot-simple). We expect candidates to be familiar with most of
those, as well as having an industry experience in functional programming.

We would be thrilled if a candidate were also interested in and/or capable
of
- DevOps with Ansible/Docker/Nix
- technical writing (Russian or English)

At the company we encourage learning and knowledge sharing, which include
internal tech talks. We also support open source contributions and
participations in meetups and conferences.

We'll gladly accept submissions from candidates of all ages, nationalities,
genders, etc.

Our focus will be on the candidates located in Moscow, Russia or willing to
relocate. However, remote/part time is possible for strong candidates or
after a probationary period.

Our office in located right in the center of Moscow, a walking distance
from Red Square, Arbat, Hermitage Garden, Moscow Zoo.
It's also less than a minute from Pushkinskaya, Tverskaya and Chekhovskaya
stations.
The office is equipped with a kitchen, microwave, coffee machine, offers
tea and fresh fruit.

Kind regards,
Nickolay Kudasov
CTO GetShop.TV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/7d8cd5db/attachment.html>

From leah at vuxu.org  Mon Jul 23 15:20:15 2018
From: leah at vuxu.org (Leah Neukirchen)
Date: Mon, 23 Jul 2018 17:20:15 +0200
Subject: [Haskell-cafe] Munich Haskell Meeting, 2018-07-25 @ 19:30
Message-ID: <8736wa2d3k.fsf@vuxu.org>

Dear all,

This week, our monthly Munich Haskell Meeting will take place again on
Wednesday, July 25 at Max Emanuel Brauerei at 19h30. For details see here:

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

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

https://dudle.inf.tu-dresden.de/haskell-munich-jul-2018/

Everybody is welcome!

cu,
-- 
Leah Neukirchen  <leah at vuxu.org>  http://leah.zone

From mail at joachim-breitner.de  Mon Jul 23 15:33:39 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Jul 2018 11:33:39 -0400
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
In-Reply-To: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
References: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
Message-ID: <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>

Hi Conal,

Am Sonntag, den 22.07.2018, 21:29 -0700 schrieb Conal Elliott:
> Suppose `g :: forall z. (A,z) -> (B,z)`. Is it necessarily the case
> that `g = first f` for some `f :: A -> B` (where `first f (a,b) = (f
> a, b)`), perhaps as a free theorem for the type of `g`?

there used to be a free theorem calculator at
http://www-ps.iai.uni-bonn.de/ft
but it seems to be down :-(

There is a shell client, ftshell, lets see what it says…
it does not build with ghc-8.0 any more :-(

Ah, but lambdabot understands @free:

<nomeata>   @free g :: forall z. (A,z) -> (B,z)
<lambdabot> $map_Pair $id f . g = g . $map_Pair $id f

Which is basically what you are writing here:

> Note that `(A,)` and `(B,)` are functors and that `g` is a natural
> transformation, so `g . fmap h == fmap h . g` for any `h :: u -> v`.
> Equivalently, `g . second h == second h . g` (where `second h (a,b) =
> (a, h b)`).

Doesn’t that already answer the question? Let’s try to make it more
rigorous. I define

f :: A -> B
f a = fst (g (a, ())

and now want to prove that g = first f, using the free theorem… which
is tricky, because the free theorem is actually not as strong as it
could be; it should actually be phrased in terms of relations relation,
which might help with the proof. 

So let me try to calculate the free theorem by hand, following
https://www.well-typed.com/blog/2015/05/parametricity/

g is related to itself by the relation

   [forall z. (A,z) -> (B,z)]

and we can calculate

  g [forall z. (A,z) -> (B,z)] g
↔ ∀ z z' Rz, g [(A,z) -> (B,z)] g -- Rz relates z and z'
↔ ∀ z z' Rz, ∀ p p', p [(A,z)] p' → g p [(B,z)] g p'
↔ ∀ z z' Rz, ∀ p p', fst p = fst p' ∧ snd p Rz snd p' →
      fst (g p) = fst (g p') ∧ snd (g p) Rz snd (g p')
↔ ∀ z z' Rz, ∀ a x x', x Rz x' →
      fst (g (a,x)) = fst (g (a,x')) ∧
snd (g (a,x)) Rz snd (g (a,x'))

We can use this to show
  
   ∀ (a,x :: z). fst (g (a,x)) = f a

using (this is the tricky part that requires thinking)

   z := z, z' := (), Rz := λ_ _ -> True, a := a, x := x, x' := ()

as then the theorem implies

  fst (g (a,x)) = fst (g (a, ()) = f a.

We can also use it to show 

   ∀ (a,x :: z). snd (g (a,x)) = x

using

   z := z, z' := z, Rz := const (= x), a := a, x := x, x' := x

as then the theorem implies, under the true assumption  x Rz z'

  (snd (g (a,x))) Rz (snd (g (a,x')))
  ↔ snd (g (a,x)) = x

And from 

   ∀ (a,x :: z). fst (g (a,x)) = f a
   ∀ (a,x :: z). snd (g (a,x)) = x

we can conclude that

  g = first f

as intended.

Cheers,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/a265a0f0/attachment.sig>

From conal at conal.net  Mon Jul 23 17:56:41 2018
From: conal at conal.net (Conal Elliott)
Date: Mon, 23 Jul 2018 10:56:41 -0700
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
In-Reply-To: <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>
References: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
 <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>
Message-ID: <CAD6SzRKe8q87ZznN8W1Uz0wfmTzrx7PqqQ834yhPeW0U=faF_w@mail.gmail.com>

Thank you, Joachim! I'm refreshing my memory of free theorem construction
from that blog post. Regards, -- Conal

On Mon, Jul 23, 2018 at 8:33 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi Conal,
>
> Am Sonntag, den 22.07.2018, 21:29 -0700 schrieb Conal Elliott:
> > Suppose `g :: forall z. (A,z) -> (B,z)`. Is it necessarily the case
> > that `g = first f` for some `f :: A -> B` (where `first f (a,b) = (f
> > a, b)`), perhaps as a free theorem for the type of `g`?
>
> there used to be a free theorem calculator at
> http://www-ps.iai.uni-bonn.de/ft
> but it seems to be down :-(
>
> There is a shell client, ftshell, lets see what it says…
> it does not build with ghc-8.0 any more :-(
>
> Ah, but lambdabot understands @free:
>
> <nomeata>   @free g :: forall z. (A,z) -> (B,z)
> <lambdabot> $map_Pair $id f . g = g . $map_Pair $id f
>
> Which is basically what you are writing here:
>
> > Note that `(A,)` and `(B,)` are functors and that `g` is a natural
> > transformation, so `g . fmap h == fmap h . g` for any `h :: u -> v`.
> > Equivalently, `g . second h == second h . g` (where `second h (a,b) =
> > (a, h b)`).
>
> Doesn’t that already answer the question? Let’s try to make it more
> rigorous. I define
>
> f :: A -> B
> f a = fst (g (a, ())
>
> and now want to prove that g = first f, using the free theorem… which
> is tricky, because the free theorem is actually not as strong as it
> could be; it should actually be phrased in terms of relations relation,
> which might help with the proof.
>
> So let me try to calculate the free theorem by hand, following
> https://www.well-typed.com/blog/2015/05/parametricity/
>
> g is related to itself by the relation
>
>    [forall z. (A,z) -> (B,z)]
>
> and we can calculate
>
>   g [forall z. (A,z) -> (B,z)] g
> ↔ ∀ z z' Rz, g [(A,z) -> (B,z)] g -- Rz relates z and z'
> ↔ ∀ z z' Rz, ∀ p p', p [(A,z)] p' → g p [(B,z)] g p'
> ↔ ∀ z z' Rz, ∀ p p', fst p = fst p' ∧ snd p Rz snd p' →
>       fst (g p) = fst (g p') ∧ snd (g p) Rz snd (g p')
> ↔ ∀ z z' Rz, ∀ a x x', x Rz x' →
>       fst (g (a,x)) = fst (g (a,x')) ∧
> snd (g (a,x)) Rz snd (g (a,x'))
>
> We can use this to show
>
>    ∀ (a,x :: z). fst (g (a,x)) = f a
>
> using (this is the tricky part that requires thinking)
>
>    z := z, z' := (), Rz := λ_ _ -> True, a := a, x := x, x' := ()
>
> as then the theorem implies
>
>   fst (g (a,x)) = fst (g (a, ()) = f a.
>
> We can also use it to show
>
>    ∀ (a,x :: z). snd (g (a,x)) = x
>
> using
>
>    z := z, z' := z, Rz := const (= x), a := a, x := x, x' := x
>
> as then the theorem implies, under the true assumption  x Rz z'
>
>   (snd (g (a,x))) Rz (snd (g (a,x')))
>   ↔ snd (g (a,x)) = x
>
> And from
>
>    ∀ (a,x :: z). fst (g (a,x)) = f a
>    ∀ (a,x :: z). snd (g (a,x)) = x
>
> we can conclude that
>
>   g = first f
>
> as intended.
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/e9e517a1/attachment.html>

From olf at aatal-apotheke.de  Mon Jul 23 19:54:35 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Mon, 23 Jul 2018 21:54:35 +0200
Subject: [Haskell-cafe] Expressing disjunctions of constraints
Message-ID: <A2762A04-DFA7-43D6-A432-EAD9A72879AC@aatal-apotheke.de>

Dear cafe, 

today I wrote a type class with three parameters.

class Foo a b c | a b -> c where
  foo :: a -> b -> c
instance Foo A R A where ...
instance Foo R A A where ...

In addition to the functional dependency I'd like to express that at least one of the parameters a and b is c, that is, Foo is the union of the two classes 

class Foo1 a b where
  foo1 :: a -> b -> a
class Foo2 a b where
  foo2 :: a -> b -> b

and furthermore the choice between Foo1 and Foo2 determines one parameter to be a fixed type, say R. I understand that logical disjunction poses problems for instance resolution [1] because adding an instance may affect the instance dictionary lookup. This should not happen in my case because in the end this would be a one-parameter type class. The ultimate aim is to use the same symbol for both a function
foo :: R -> a -> a
and for flip foo. Of course writing flip foo is not that much of a nuisance, I just wonder whether Haskell is expressive enough to do this. 

Olaf

[1] https://stackoverflow.com/questions/10255148/how-can-i-combine-two-type-constraints-with-a-logical-or-in-haskell



From tanuki at gmail.com  Mon Jul 23 21:10:45 2018
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Mon, 23 Jul 2018 14:10:45 -0700
Subject: [Haskell-cafe] Why does this result in a runtime loop instead of a
 type error or typechecker loop?
Message-ID: <CAJoPsuB_ruxrOiGhR44+c1KUgfvNPyK3PnjXjpYbud+86h24pQ@mail.gmail.com>

λ. :set -XFlexibleContexts -XFlexibleInstances -XMultiParamTypeClasses
-XUndecidableInstances
λ. import RIO
λ. import Data.Has
λ. class HasBool a where boolL :: Lens' a Bool
λ. instance {-#OVERLAPPABLE#-} HasBool a => Has Bool a where hasLens = boolL
λ. instance {-#OVERLAPPABLE#-} Has Bool a => HasBool a where boolL = hasLens
λ. runRIO () $ view boolL
^CInterrupted.

The RIO environment () doesn't contain a Bool. I can see how the
typechecker might get lost in this, but I can compile an equivalent
program; it loops on execution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/2a97b788/attachment.html>

From jwlato at gmail.com  Tue Jul 24 03:32:28 2018
From: jwlato at gmail.com (John Lato)
Date: Mon, 23 Jul 2018 20:32:28 -0700
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <alpine.LNX.2.21.1807221723310.9946@localhost>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
Message-ID: <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>

I think you're attempting to optimize the wrong thing. In a dynamic
language like Ruby, this approach makes sense because download times are a
significant fraction of the user's time, and otherwise the user experience
isn't affected much because the code is basically interpreted either way.

Haskell is primarily a compiled language. The total download size probably
won't be significantly larger from downloading all modules. The cost of
recompiling/dynamically loading plugins will be expensive (relative to the
rest of the user time), and payed with every execution. Plus it's
additional work for the developer to set up.

In all likelihood you should just build a binary with all available
strategies and distribute that.

On Sun, Jul 22, 2018, 08:27 Marc Busqué <marc at lamarciana.com> wrote:

> Hi there,
>
> I'm currently programming my first non toy project in Haskell. I come from
> Ruby
> background, where everything is possible no matter how much entropy the
> universe gains after you finish your work, so I'm still not sure how to do
> certain things without this side-effect :)
>
> I'll try to be concise. My idea is that the project would consist of
> several
> different Haskell packages. The central one, call it Core, would define a
> certain data type (with info about certain URLs). Other packages would
> define
> each one an strategy to do something with that data type (processing the
> URL
> info). Each strategy would have its own dependencies, and as a user
> probably
> won't need all of the strategies, I would like to keep them in separated
> packages so she or he has no need to download the unneeded stuff.
>
> The problem is that Core should act as the central dashboard, whether
> through a
> CLI or even a web frontend. For example, in the CLI case, I would like to
> be
> able to install Core package along with package StrategyA and package
> StrategyB
> and then do something like the following:
>
> ```
> bash> core --action=fetch --strategy=A
> bash> core --action=fetch --strategy=B
> ```
>
> Two generic ideas come to my mind but I don't know how to translate them
> to Haskell:
>
> - Infer module name from the `--strategy` argument and call it dynamically.
>    However, as far as I know, in Haskell modules are not first class
> citizens,
>    so no way I can dynamically call them. I have read something to achieve
> this
>    through Template Haskell or through outdaded
>    [plugins](http://hackage.haskell.org/package/plugins) package, but I'm
> not
>    sure whether the need is the same and anyway it seems quite unnatural to
>    Haskell (I would not like to go against it, but to learn to do thing in
> its
>    way).
>
> - Define from Core some kind of global list where strategy packages can
>    register a map between CLI argument value and a defined instance of the
> core
>    data type. But, again, how to do global things in Haskell (and I would
> prefer
>    not to need external tools like RDBMS, filesystem or whatever)? And,
> anyway,
>    surely I don't want to do this because concurrency and everything...
>
> Any idea?
>
> Thanks in advance!
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
> _______________________________________________
> 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/20180723/20d4535b/attachment.html>

From michael at snoyman.com  Tue Jul 24 05:08:51 2018
From: michael at snoyman.com (Michael Snoyman)
Date: Tue, 24 Jul 2018 08:08:51 +0300
Subject: [Haskell-cafe] Why does this result in a runtime loop instead
 of a type error or typechecker loop?
In-Reply-To: <CAJoPsuB_ruxrOiGhR44+c1KUgfvNPyK3PnjXjpYbud+86h24pQ@mail.gmail.com>
References: <CAJoPsuB_ruxrOiGhR44+c1KUgfvNPyK3PnjXjpYbud+86h24pQ@mail.gmail.com>
Message-ID: <CAKT9ecPt8xCLE_TxxpBedGzshS6EZfyWeXZPUfwj5EAuKGyoyw@mail.gmail.com>

It looks like you have an infinite loop created, where `hasLens = boolL`
and `boolL = hasLens`, and the two overlappable instances are each
fulfilling the constraints of the other instance.

On Tue, Jul 24, 2018 at 12:11 AM Theodore Lief Gannon <tanuki at gmail.com>
wrote:

> λ. :set -XFlexibleContexts -XFlexibleInstances -XMultiParamTypeClasses
> -XUndecidableInstances
> λ. import RIO
> λ. import Data.Has
> λ. class HasBool a where boolL :: Lens' a Bool
> λ. instance {-#OVERLAPPABLE#-} HasBool a => Has Bool a where hasLens =
> boolL
> λ. instance {-#OVERLAPPABLE#-} Has Bool a => HasBool a where boolL =
> hasLens
> λ. runRIO () $ view boolL
> ^CInterrupted.
>
> The RIO environment () doesn't contain a Bool. I can see how the
> typechecker might get lost in this, but I can compile an equivalent
> program; it loops on execution.
> _______________________________________________
> 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/20180724/4e0f72fd/attachment.html>

From dennis.raddle at gmail.com  Tue Jul 24 05:14:54 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Mon, 23 Jul 2018 22:14:54 -0700
Subject: [Haskell-cafe] animation application
Message-ID: <CAKxLvoppzf3dX4ChwUyOhOu2cvzLjVmi1k1qXPSecS+YTFfFeA@mail.gmail.com>

I'm working on an application for animating words, images, and shapes. I'm
actually doing it in Purescript and it will become part of a math game that
runs in the browser, but I'm asking my question on the Haskell list because
the issues seem central to a functional/pure paradigm.

Let's say that the things being animated are "objects." Objects could
include photos, text, shapes, lines, etc. They can have fixed positions,
colors, and other attributes, or their attributes can change over time.

How do I compute attributes that change over time? In some cases, a
function with a single argument, the current time, would suffice. I might
want state, though -- perhaps an object's movement is pseudorandom and
needs to refer to a seed and past position state.

Objects might even need to observe each other's state. For instance,
imagine we have two words, W1 and W2, and they move according to some
stateful algorithm. Meanwhile we want to draw a line connecting their
centers, so we need a line object L that can read the centers of W1 and W2.

How do I represent the state of W1, W2, and L? I could define a general
Object data type: (here there are no fields mentioned)

data Object = W1  | W2  | L

I will need state and the ability to customize the drawing and positioning
functions, so to flesh out the fields of, say , W1.

type St = StateT WholeScene IO

data Object = W1 { leftEdge        :: Int
                 , rightEdge       :: Int
                 , topEdge         :: Int
                 , bottomEdge      :: Int
                 , computePosition :: W1 -> Time -> St W1
                 , draw            :: W1 -> St ()
                 ,  ... other state ...
                 }



Okay, so now I could define W2, which will be different in some ways,
perhaps needing different state. But it will look a lot alike. It might
have the same edge fields.

In fact, all my objects will have similar position, color, etc. attributes.
I certainly don't want to reinvent the wheel for everything.

I also want objects to be able to read each other's state. Consider a basic
positioning task: some object Obj1 keeps its left edge 100 pixels to the
right of some other object's right edge. So the Obj1 function for computing
position needs access to the other objects.

Also consider that all these objects need to be put into a list together,
to hold the state of the entire scene. They need to be members of the same
class, and have a way to look each other up.

One way to do this is have a single Object type with numerous constructors,
and define similar functions on every constructor type (say, a function for
accessing or setting the left edge).

I also thought about having an Object be an existential type, and the
fields that are custom to one object will be the existentially defined
data. I actually implemented this in Purescript, but it got out of hand,
probably due to my own weakness of understanding how existential types work.

Any ideas?

D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/5834f61b/attachment.html>

From aquagnu at gmail.com  Tue Jul 24 05:17:35 2018
From: aquagnu at gmail.com (Paul)
Date: Tue, 24 Jul 2018 08:17:35 +0300
Subject: [Haskell-cafe] Expressing disjunctions of constraints
In-Reply-To: <A2762A04-DFA7-43D6-A432-EAD9A72879AC@aatal-apotheke.de>
References: <A2762A04-DFA7-43D6-A432-EAD9A72879AC@aatal-apotheke.de>
Message-ID: <0b67725c-12d4-a7c4-bca1-fcb7974967b5@gmail.com>

 > I'd like to express that at least one of the parameters a and b is c

Hello, Olaf! I never do it, but as idea: may be to use type-level lists, 
for example, and to add such condition in instance constraints? There is 
package type-lists with types "functions" like Find, etc (for member 
checking, appending, etc)...


23.07.2018 22:54, Olaf Klinke wrotes:
> Dear cafe,
>
> today I wrote a type class with three parameters.
>
> class Foo a b c | a b -> c where
>    foo :: a -> b -> c
> instance Foo A R A where ...
> instance Foo R A A where ...
>
> In addition to the functional dependency I'd like to express that at least one of the parameters a and b is c, that is, Foo is the union of the two classes
>
> class Foo1 a b where
>    foo1 :: a -> b -> a
> class Foo2 a b where
>    foo2 :: a -> b -> b
>
> and furthermore the choice between Foo1 and Foo2 determines one parameter to be a fixed type, say R. I understand that logical disjunction poses problems for instance resolution [1] because adding an instance may affect the instance dictionary lookup. This should not happen in my case because in the end this would be a one-parameter type class. The ultimate aim is to use the same symbol for both a function
> foo :: R -> a -> a
> and for flip foo. Of course writing flip foo is not that much of a nuisance, I just wonder whether Haskell is expressive enough to do this.
>
> Olaf
>
> [1] https://stackoverflow.com/questions/10255148/how-can-i-combine-two-type-constraints-with-a-logical-or-in-haskell
>
>
> _______________________________________________
> 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 ryan.reich at gmail.com  Tue Jul 24 05:52:28 2018
From: ryan.reich at gmail.com (Ryan Reich)
Date: Mon, 23 Jul 2018 22:52:28 -0700
Subject: [Haskell-cafe] Why does this result in a runtime loop instead
 of a type error or typechecker loop?
In-Reply-To: <CAJoPsuB_ruxrOiGhR44+c1KUgfvNPyK3PnjXjpYbud+86h24pQ@mail.gmail.com>
References: <CAJoPsuB_ruxrOiGhR44+c1KUgfvNPyK3PnjXjpYbud+86h24pQ@mail.gmail.com>
Message-ID: <CAO8OcksX6C0LcPm9OPuAvq-NojWMq=TcydUjOhTdgLUyspX6kw@mail.gmail.com>

This seems like the canonical illustration of the dangers of
UndecidableInstances.  Normally an instance of the form "instance C1 a =>
C2 a" would be forbidden specifically because it does not exclude the
possibility of some other "instance C2 a => C1 a" elsewhere that would
create a loop.  UndecidableInstances disables this check, passing off on
you (the programmer) the responsibility of ensuring that you don't actually
do this.  You did, so you get the loop, and the compiler doesn't care
because you told it not to.

The reason the instance definitions don't loop during compilation is that
the type "HasBool a => Has Bool a" conveniently furnishes a HasBool
instance whence boolL can be obtained, so the compiler doesn't need to go
looking for an instance elsewhere, and so doesn't go into an infinite
recursion with the one that's on the next line.

The reason that even the line "runRIO () $ view boolL" doesn't cause the
compiler to loop is that, although it does infer that a = (), and therefore
does tie the knot with those two instances, it doesn't actually need to
look farther than the "HasBool ()" part of "instance Has Bool () => HasBool
()" to get boolL, as the constraint is not used in selecting an instance,
and since once that instance is selected it can easily also verify that we
do have "instance Has Bool ()" in the same oblivious way.  It just happens
that the particular definition of boolL that it gets is equivalent (after
two round of substitution) to "boolL = boolL", which only loops when it is
run.

On Mon, Jul 23, 2018 at 2:10 PM, Theodore Lief Gannon <tanuki at gmail.com>
wrote:

> λ. :set -XFlexibleContexts -XFlexibleInstances -XMultiParamTypeClasses
> -XUndecidableInstances
> λ. import RIO
> λ. import Data.Has
> λ. class HasBool a where boolL :: Lens' a Bool
> λ. instance {-#OVERLAPPABLE#-} HasBool a => Has Bool a where hasLens =
> boolL
> λ. instance {-#OVERLAPPABLE#-} Has Bool a => HasBool a where boolL =
> hasLens
> λ. runRIO () $ view boolL
> ^CInterrupted.
>
> The RIO environment () doesn't contain a Bool. I can see how the
> typechecker might get lost in this, but I can compile an equivalent
> program; it loops on execution.
>
> _______________________________________________
> 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/20180723/a47a91b9/attachment.html>

From marc at lamarciana.com  Tue Jul 24 06:07:38 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 24 Jul 2018 08:07:38 +0200 (CEST)
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
 <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>
Message-ID: <alpine.LNX.2.21.1807240759280.1329@localhost>

On Mon, 23 Jul 2018, John Lato wrote:

> I think you're attempting to optimize the wrong thing. In a dynamic language like Ruby, this approach makes sense because download times are a
> significant fraction of the user's time, and otherwise the user experience isn't affected much because the code is basically interpreted either
> way.
> Haskell is primarily a compiled language. The total download size probably won't be significantly larger from downloading all modules. The cost
> of recompiling/dynamically loading plugins will be expensive (relative to the rest of the user time), and payed with every execution. Plus it's
> additional work for the developer to set up.

What you say makes a lot of sense in terms of optimization. But, what
about extensibility? Take for example the Pandoc package, which would be
similar in design of what I'm trying to do. Say I want to add a
converter to some mark-up format not supported by Pandoc, and that
Pandoc team doesn't agree to merge my work in its repo or simply I don't
have the time to wait until it happens. In this sense, it would be nice
that Pandoc supported dynamically loading of extra plugins on demand.

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

From dennis.raddle at gmail.com  Tue Jul 24 06:42:55 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Mon, 23 Jul 2018 23:42:55 -0700
Subject: [Haskell-cafe] animation application
In-Reply-To: <CAKxLvoppzf3dX4ChwUyOhOu2cvzLjVmi1k1qXPSecS+YTFfFeA@mail.gmail.com>
References: <CAKxLvoppzf3dX4ChwUyOhOu2cvzLjVmi1k1qXPSecS+YTFfFeA@mail.gmail.com>
Message-ID: <CAKxLvorvS8VYXWZn64y8B-uQRgW41AtOqHeZ5L8frACO=VgAGw@mail.gmail.com>

Update: I may have gotten existential types to work.

I'm think of it like this: there's a type Object, which can be unwrapped
into different things depending on the type of the existential data.

data Object = forall s. { common :: Int, custom: s }


In purescript you define two types:

import Data.Exists

type ObjectInner s = ObjectInner { common :: Int, custom: s }

type Object = Exists ObjectInner

And then you can only access the innards of Object through the runExists
and mkExists functions.

I realized that I could think of the situation in a sort-of object oriented
way. I've got data, and an interface. I can define the interface as fields
with function values.

type ObjectInner s = ObjectInner { doSomething :: ObjectInner s -> IO (),
fetchSomething :: ObjectInner s -> Int, ... }

My whole application has a single list (or in Purescript, Array) of Object
values:

bigPicture :: Array Object

I can define functions that use runExists to access the interface of any
given Object. My understanding is that the point of Existential types is
that the custom type is not supposed to escape its scope. In this method,
it seems that both the data and the functions for operating on it are
wrapped inside Object.

I think this is working for me. Needs a little more work.



On Mon, Jul 23, 2018 at 10:14 PM, Dennis Raddle <dennis.raddle at gmail.com>
wrote:

> I'm working on an application for animating words, images, and shapes. I'm
> actually doing it in Purescript and it will become part of a math game that
> runs in the browser, but I'm asking my question on the Haskell list because
> the issues seem central to a functional/pure paradigm.
>
> Let's say that the things being animated are "objects." Objects could
> include photos, text, shapes, lines, etc. They can have fixed positions,
> colors, and other attributes, or their attributes can change over time.
>
> How do I compute attributes that change over time? In some cases, a
> function with a single argument, the current time, would suffice. I might
> want state, though -- perhaps an object's movement is pseudorandom and
> needs to refer to a seed and past position state.
>
> Objects might even need to observe each other's state. For instance,
> imagine we have two words, W1 and W2, and they move according to some
> stateful algorithm. Meanwhile we want to draw a line connecting their
> centers, so we need a line object L that can read the centers of W1 and W2.
>
> How do I represent the state of W1, W2, and L? I could define a general
> Object data type: (here there are no fields mentioned)
>
> data Object = W1  | W2  | L
>
> I will need state and the ability to customize the drawing and positioning
> functions, so to flesh out the fields of, say , W1.
>
> type St = StateT WholeScene IO
>
> data Object = W1 { leftEdge        :: Int
>                  , rightEdge       :: Int
>                  , topEdge         :: Int
>                  , bottomEdge      :: Int
>                  , computePosition :: W1 -> Time -> St W1
>                  , draw            :: W1 -> St ()
>                  ,  ... other state ...
>                  }
>
>
>
> Okay, so now I could define W2, which will be different in some ways,
> perhaps needing different state. But it will look a lot alike. It might
> have the same edge fields.
>
> In fact, all my objects will have similar position, color, etc.
> attributes. I certainly don't want to reinvent the wheel for everything.
>
> I also want objects to be able to read each other's state. Consider a
> basic positioning task: some object Obj1 keeps its left edge 100 pixels to
> the right of some other object's right edge. So the Obj1 function for
> computing position needs access to the other objects.
>
> Also consider that all these objects need to be put into a list together,
> to hold the state of the entire scene. They need to be members of the same
> class, and have a way to look each other up.
>
> One way to do this is have a single Object type with numerous
> constructors, and define similar functions on every constructor type (say,
> a function for accessing or setting the left edge).
>
> I also thought about having an Object be an existential type, and the
> fields that are custom to one object will be the existentially defined
> data. I actually implemented this in Purescript, but it got out of hand,
> probably due to my own weakness of understanding how existential types work.
>
> Any ideas?
>
> D
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/71ea73e0/attachment.html>

From aquagnu at gmail.com  Tue Jul 24 07:16:56 2018
From: aquagnu at gmail.com (Paul)
Date: Tue, 24 Jul 2018 10:16:56 +0300
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <alpine.LNX.2.21.1807240759280.1329@localhost>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
 <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>
 <alpine.LNX.2.21.1807240759280.1329@localhost>
Message-ID: <5dbc900f-ce0b-2c73-ba48-ba41168e8f95@gmail.com>

 > that Pandoc supported dynamically loading of extra plugins on demand.

It means .dll/.so. But also there are applications with pre-built 
"plugins" - you can not load them dynamically, but can turn-on/off 
dynamically (from a list of pre-installed plugins). It's useful too.


24.07.2018 09:07, Marc Busqué wrotes:
> On Mon, 23 Jul 2018, John Lato wrote:
>
>> I think you're attempting to optimize the wrong thing. In a dynamic 
>> language like Ruby, this approach makes sense because download times 
>> are a
>> significant fraction of the user's time, and otherwise the user 
>> experience isn't affected much because the code is basically 
>> interpreted either
>> way.
>> Haskell is primarily a compiled language. The total download size 
>> probably won't be significantly larger from downloading all modules. 
>> The cost
>> of recompiling/dynamically loading plugins will be expensive 
>> (relative to the rest of the user time), and payed with every 
>> execution. Plus it's
>> additional work for the developer to set up.
>
> What you say makes a lot of sense in terms of optimization. But, what
> about extensibility? Take for example the Pandoc package, which would be
> similar in design of what I'm trying to do. Say I want to add a
> converter to some mark-up format not supported by Pandoc, and that
> Pandoc team doesn't agree to merge my work in its repo or simply I don't
> have the time to wait until it happens. In this sense, it would be nice
> that Pandoc supported dynamically loading of extra plugins on demand.
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
>
>
> _______________________________________________
> 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/20180724/bd5b30cf/attachment-0001.html>

From jeremy.odonoghue at gmail.com  Tue Jul 24 07:30:07 2018
From: jeremy.odonoghue at gmail.com (Jeremy O'Donoghue)
Date: Tue, 24 Jul 2018 15:30:07 +0800
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <5dbc900f-ce0b-2c73-ba48-ba41168e8f95@gmail.com>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
 <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>
 <alpine.LNX.2.21.1807240759280.1329@localhost>
 <5dbc900f-ce0b-2c73-ba48-ba41168e8f95@gmail.com>
Message-ID: <2B389A34-1B45-4E66-885D-01C9980F5BCA@gmail.com>



> On 24 Jul 2018, at 15:16, Paul <aquagnu at gmail.com> wrote:
> 
> > that Pandoc supported dynamically loading of extra plugins on demand.
> 
> It means .dll/.so. But also there are applications with pre-built "plugins" - you can not load them dynamically, but can turn-on/off dynamically (from a list of pre-installed plugins). It's useful too.
> 
Pandoc plug-ins are separate executables rather than shared libraries. Haskell data types are serialised by Pandoc then de-serialised, modified and re-serialised in each plugin.

The Pandoc approach is more like a data pipeline with Pandoc itself at both ends.

Jeremy 

> 24.07.2018 09:07, Marc Busqué wrotes:
>> On Mon, 23 Jul 2018, John Lato wrote: 
>> 
>>> I think you're attempting to optimize the wrong thing. In a dynamic language like Ruby, this approach makes sense because download times are a 
>>> significant fraction of the user's time, and otherwise the user experience isn't affected much because the code is basically interpreted either 
>>> way. 
>>> Haskell is primarily a compiled language. The total download size probably won't be significantly larger from downloading all modules. The cost 
>>> of recompiling/dynamically loading plugins will be expensive (relative to the rest of the user time), and payed with every execution. Plus it's 
>>> additional work for the developer to set up. 
>> 
>> What you say makes a lot of sense in terms of optimization. But, what 
>> about extensibility? Take for example the Pandoc package, which would be 
>> similar in design of what I'm trying to do. Say I want to add a 
>> converter to some mark-up format not supported by Pandoc, and that 
>> Pandoc team doesn't agree to merge my work in its repo or simply I don't 
>> have the time to wait until it happens. In this sense, it would be nice 
>> that Pandoc supported dynamically loading of extra plugins on demand. 
>> 
>> Marc Busqué 
>> http://waiting-for-dev.github.io/about/
>> 
>> 
>> _______________________________________________
>> 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/20180724/de29dc54/attachment.html>

From aquagnu at gmail.com  Tue Jul 24 09:41:08 2018
From: aquagnu at gmail.com (Paul)
Date: Tue, 24 Jul 2018 12:41:08 +0300
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <2B389A34-1B45-4E66-885D-01C9980F5BCA@gmail.com>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
 <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>
 <alpine.LNX.2.21.1807240759280.1329@localhost>
 <5dbc900f-ce0b-2c73-ba48-ba41168e8f95@gmail.com>
 <2B389A34-1B45-4E66-885D-01C9980F5BCA@gmail.com>
Message-ID: <fc558fcc-2da1-f686-88ed-5ef45e972072@gmail.com>

Hmm, so this is easier even. Plugin must have standard interface, 
available through stdin/stdout/pipes/sockets. Stdin/stdout/stderr is 
more simple and it's easy to debug (as first version, at least), also 
can be "mapped" to sockets easy (in inetd-style, for example). "Driver" 
can looks like "cmd" module in Python (it's better than to use command 
line arguments, due to length limitation). Even more, it's easy 
convertable to other protocols/formats which allows to switch to 
microservice architecture without big effort ;) (I did it in D: 
communication can be automatically mapped to JSON/XML/Show-Read/etc). It 
sounds as interesting task.

I like Powershell: it extends standard way of Unix scripting languages 
communicating with strings (like Tcl, shell) to objects instead. So 
binary protocol can be supported too (MessagePack, BSON, Xdr, etc). It's 
totally language neutral plugin architecture ;) "Pipelining" can be done 
in WSGI style - with middleware which can help the "plugging" of 
protocols :)

Dispatching can be achieved with special directory layout/some config 
file (better).

24.07.2018 10:30, Jeremy O'Donoghue wrotes:
>
>
> On 24 Jul 2018, at 15:16, Paul <aquagnu at gmail.com 
> <mailto:aquagnu at gmail.com>> wrote:
>
>> > that Pandoc supported dynamically loading of extra plugins on demand.
>>
>> It means .dll/.so. But also there are applications with pre-built 
>> "plugins" - you can not load them dynamically, but can turn-on/off 
>> dynamically (from a list of pre-installed plugins). It's useful too.
>>
> Pandoc plug-ins are separate executables rather than shared libraries. 
> Haskell data types are serialised by Pandoc then de-serialised, 
> modified and re-serialised in each plugin.
>
> The Pandoc approach is more like a data pipeline with Pandoc itself at 
> both ends.
>
> Jeremy
>
>> 24.07.2018 09:07, Marc Busqué wrotes:
>>> On Mon, 23 Jul 2018, John Lato wrote:
>>>
>>>> I think you're attempting to optimize the wrong thing. In a dynamic 
>>>> language like Ruby, this approach makes sense because download 
>>>> times are a
>>>> significant fraction of the user's time, and otherwise the user 
>>>> experience isn't affected much because the code is basically 
>>>> interpreted either
>>>> way.
>>>> Haskell is primarily a compiled language. The total download size 
>>>> probably won't be significantly larger from downloading all 
>>>> modules. The cost
>>>> of recompiling/dynamically loading plugins will be expensive 
>>>> (relative to the rest of the user time), and payed with every 
>>>> execution. Plus it's
>>>> additional work for the developer to set up.
>>>
>>> What you say makes a lot of sense in terms of optimization. But, what
>>> about extensibility? Take for example the Pandoc package, which 
>>> would be
>>> similar in design of what I'm trying to do. Say I want to add a
>>> converter to some mark-up format not supported by Pandoc, and that
>>> Pandoc team doesn't agree to merge my work in its repo or simply I 
>>> don't
>>> have the time to wait until it happens. In this sense, it would be nice
>>> that Pandoc supported dynamically loading of extra plugins on demand.
>>>
>>> Marc Busqué
>>> http://waiting-for-dev.github.io/about/
>>>
>>>
>>> _______________________________________________
>>> 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/20180724/1d4a99f2/attachment.html>

From marc at lamarciana.com  Tue Jul 24 10:29:16 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 24 Jul 2018 12:29:16 +0200 (CEST)
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <5dbc900f-ce0b-2c73-ba48-ba41168e8f95@gmail.com>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
 <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>
 <alpine.LNX.2.21.1807240759280.1329@localhost>
 <5dbc900f-ce0b-2c73-ba48-ba41168e8f95@gmail.com>
Message-ID: <alpine.LNX.2.21.1807241228070.1329@localhost>

On Tue, 24 Jul 2018, Paul wrote:

> you can not load them dynamically, but can turn-on/off dynamically
> (from a list of pre-installed plugins).

Sorry if it's an obvious question, but, how do you do it?

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

From foxbenjaminfox at gmail.com  Tue Jul 24 10:32:10 2018
From: foxbenjaminfox at gmail.com (Benjamin Fox)
Date: Tue, 24 Jul 2018 12:32:10 +0200
Subject: [Haskell-cafe] Expressing disjunctions of constraints
In-Reply-To: <A2762A04-DFA7-43D6-A432-EAD9A72879AC@aatal-apotheke.de>
References: <A2762A04-DFA7-43D6-A432-EAD9A72879AC@aatal-apotheke.de>
Message-ID: <CAPeWBm6LNL2Pg+23jLBkdsu-J0WJw-6maBdRF-cBT8exu_110Q@mail.gmail.com>

You could write a type family like this one:

type family (x :: k) `IsOneOf` (y :: (k, k)) :: Bool where
  x `IsOneOf` '(x, _) = 'True
  x `IsOneOf` '(_, x) = 'True
  _ `IsOneOf` _ = 'False

This is a type family that checks if a given type matches at least one of a
given pair of types.

Once you have that, you can easily add it as a constraint to your typeclass:

class c `IsOneOf` '(a, b) ~ 'True => Foo a b c | a b -> c where
  foo :: a -> b -> c

This seems to give you what you want: It means that no instance of your
typeclass can be for types a, b, and c such that c that isn't equal to at
least one of a or b.


On Mon, Jul 23, 2018 at 9:55 PM Olaf Klinke <olf at aatal-apotheke.de> wrote:

> Dear cafe,
>
> today I wrote a type class with three parameters.
>
> class Foo a b c | a b -> c where
>   foo :: a -> b -> c
> instance Foo A R A where ...
> instance Foo R A A where ...
>
> In addition to the functional dependency I'd like to express that at least
> one of the parameters a and b is c, that is, Foo is the union of the two
> classes
>
> class Foo1 a b where
>   foo1 :: a -> b -> a
> class Foo2 a b where
>   foo2 :: a -> b -> b
>
> and furthermore the choice between Foo1 and Foo2 determines one parameter
> to be a fixed type, say R. I understand that logical disjunction poses
> problems for instance resolution [1] because adding an instance may affect
> the instance dictionary lookup. This should not happen in my case because
> in the end this would be a one-parameter type class. The ultimate aim is to
> use the same symbol for both a function
> foo :: R -> a -> a
> and for flip foo. Of course writing flip foo is not that much of a
> nuisance, I just wonder whether Haskell is expressive enough to do this.
>
> Olaf
>
> [1]
> https://stackoverflow.com/questions/10255148/how-can-i-combine-two-type-constraints-with-a-logical-or-in-haskell
>
>
> _______________________________________________
> 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/20180724/b5711937/attachment.html>

From aquagnu at gmail.com  Tue Jul 24 12:15:46 2018
From: aquagnu at gmail.com (Paul)
Date: Tue, 24 Jul 2018 15:15:46 +0300
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <alpine.LNX.2.21.1807241228070.1329@localhost>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
 <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>
 <alpine.LNX.2.21.1807240759280.1329@localhost>
 <5dbc900f-ce0b-2c73-ba48-ba41168e8f95@gmail.com>
 <alpine.LNX.2.21.1807241228070.1329@localhost>
Message-ID: <fe966bd1-707e-86df-0083-be2649e0f54a@gmail.com>

24.07.2018 13:29, Marc Busqué wrotes:
> On Tue, 24 Jul 2018, Paul wrote:
>
>> you can not load them dynamically, but can turn-on/off dynamically
>> (from a list of pre-installed plugins).
>
> Sorry if it's an obvious question, but, how do you do it?
Depends on architecture. Suppose, plugins will be compiled with the 
application and will be "registered" in some container (list, for 
example). So, the turn-off will remove them from the list / will mark 
them with some flag as "disabled". So, your pipeline will skip them.

As I understand you have cases:
- plugins are DLLs
- plugins are statically linked with application but can be disabled 
individually
- plugins are EXEs, so easy can be found/called...

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


From johannes.waldmann at htwk-leipzig.de  Tue Jul 24 13:42:32 2018
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 24 Jul 2018 15:42:32 +0200
Subject: [Haskell-cafe] how to terminate a (Posix) process and all its
	subprocesses?
Message-ID: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>

Dear Cafe,

I am using
https://hackage.haskell.org/package/process-1.6.4.0/docs/System-Process.html#v:readProcess
to start an external command, and wait for its completion.

Now I would like to time-out this after a while.
I can use
https://hackage.haskell.org/package/base-4.11.1.0/docs/System-Timeout.html
and this works in simple cases -

but not in case the external command has spawned child processes.
(cleanupProcess sends SIGTERM but only to the process at the top of
the tree ?)

I guess I need to use
https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-Process.html
but that seems rather low-level - and I don't see how I would
get the ProcessID of the process started by  readProcess,
so I'd also have to re-do that.

Is there an abstraction/library that would help here?

Thanks - J.W.

From ietf-dane at dukhovni.org  Tue Jul 24 15:31:35 2018
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 24 Jul 2018 11:31:35 -0400
Subject: [Haskell-cafe] how to terminate a (Posix) process and all its
 subprocesses?
In-Reply-To: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
References: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
Message-ID: <AB8A3466-04AD-439F-9B4F-F4162B61588D@dukhovni.org>



> On Jul 24, 2018, at 9:42 AM, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> wrote:
> 
> Now I would like to time-out this after a while.
> I can use
> https://hackage.haskell.org/package/base-4.11.1.0/docs/System-Timeout.html
> and this works in simple cases -
> 
> but not in case the external command has spawned child processes.
> (cleanupProcess sends SIGTERM but only to the process at the top of
> the tree ?)

You could start a wrapper process that starts the real process,
the wrapper process would kill the process group it spawned.

	wrapper command [args ...]

would run command as a child in its own process group and propagates
termination signals (SIGHUP, SIGINT, SIGTERM) to the child process.

There are likely multiple such wrappers available.  I don't have
a particular one to recommend.

-- 
	Viktor.


From mail at joachim-breitner.de  Tue Jul 24 17:37:46 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Jul 2018 13:37:46 -0400
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
In-Reply-To: <CAD6SzRKe8q87ZznN8W1Uz0wfmTzrx7PqqQ834yhPeW0U=faF_w@mail.gmail.com>
References: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
 <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>
 <CAD6SzRKe8q87ZznN8W1Uz0wfmTzrx7PqqQ834yhPeW0U=faF_w@mail.gmail.com>
Message-ID: <7522086b03458549b17482d30cc511ebc612724d.camel@joachim-breitner.de>

Hi,

I felt inspired to revive the free theorem calculator and gave it a new
home (and a modern, browser-only, FRP-based implementation):

http://free-theorems.nomeata.de/

which prints

   forall t1,t2 in TYPES, R in REL(t1,t2).
    forall (x, y) in lift{(,)}(id,R).
     (g_{t1} x, g_{t2} y) in lift{(,)}(id,R)

as the free theorem, which is (if one squints) the same as my 

  ∀ z z' Rz, ∀ a x x', x Rz x' →
      fst (g (a,x)) = fst (g (a,x')) ∧ snd (g (a,x)) Rz snd (g (a,x'))

Enjoy,
Joachim

Am Montag, den 23.07.2018, 10:56 -0700 schrieb Conal Elliott:
> Thank you, Joachim! I'm refreshing my memory of free theorem construction from that blog post. Regards, -- Conal
> 
> On Mon, Jul 23, 2018 at 8:33 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > Hi Conal,
> > 
> > Am Sonntag, den 22.07.2018, 21:29 -0700 schrieb Conal Elliott:
> > > Suppose `g :: forall z. (A,z) -> (B,z)`. Is it necessarily the case
> > > that `g = first f` for some `f :: A -> B` (where `first f (a,b) = (f
> > > a, b)`), perhaps as a free theorem for the type of `g`?
> > 
> > there used to be a free theorem calculator at
> > http://www-ps.iai.uni-bonn.de/ft
> > but it seems to be down :-(
> > 
> > There is a shell client, ftshell, lets see what it says…
> > it does not build with ghc-8.0 any more :-(
> > 
> > Ah, but lambdabot understands @free:
> > 
> > <nomeata>   @free g :: forall z. (A,z) -> (B,z)
> > <lambdabot> $map_Pair $id f . g = g . $map_Pair $id f
> > 
> > Which is basically what you are writing here:
> > 
> > > Note that `(A,)` and `(B,)` are functors and that `g` is a natural
> > > transformation, so `g . fmap h == fmap h . g` for any `h :: u -> v`.
> > > Equivalently, `g . second h == second h . g` (where `second h (a,b) =
> > > (a, h b)`).
> > 
> > Doesn’t that already answer the question? Let’s try to make it more
> > rigorous. I define
> > 
> > f :: A -> B
> > f a = fst (g (a, ())
> > 
> > and now want to prove that g = first f, using the free theorem… which
> > is tricky, because the free theorem is actually not as strong as it
> > could be; it should actually be phrased in terms of relations relation,
> > which might help with the proof. 
> > 
> > So let me try to calculate the free theorem by hand, following
> > https://www.well-typed.com/blog/2015/05/parametricity/
> > 
> > g is related to itself by the relation
> > 
> >    [forall z. (A,z) -> (B,z)]
> > 
> > and we can calculate
> > 
> >   g [forall z. (A,z) -> (B,z)] g
> > ↔ ∀ z z' Rz, g [(A,z) -> (B,z)] g -- Rz relates z and z'
> > ↔ ∀ z z' Rz, ∀ p p', p [(A,z)] p' → g p [(B,z)] g p'
> > ↔ ∀ z z' Rz, ∀ p p', fst p = fst p' ∧ snd p Rz snd p' →
> >       fst (g p) = fst (g p') ∧ snd (g p) Rz snd (g p')
> > ↔ ∀ z z' Rz, ∀ a x x', x Rz x' →
> >       fst (g (a,x)) = fst (g (a,x')) ∧
> > snd (g (a,x)) Rz snd (g (a,x'))
> > 
> > We can use this to show
> > 
> >    ∀ (a,x :: z). fst (g (a,x)) = f a
> > 
> > using (this is the tricky part that requires thinking)
> > 
> >    z := z, z' := (), Rz := λ_ _ -> True, a := a, x := x, x' := ()
> > 
> > as then the theorem implies
> > 
> >   fst (g (a,x)) = fst (g (a, ()) = f a.
> > 
> > We can also use it to show 
> > 
> >    ∀ (a,x :: z). snd (g (a,x)) = x
> > 
> > using
> > 
> >    z := z, z' := z, Rz := const (= x), a := a, x := x, x' := x
> > 
> > as then the theorem implies, under the true assumption  x Rz z'
> > 
> >   (snd (g (a,x))) Rz (snd (g (a,x')))
> >   ↔ snd (g (a,x)) = x
> > 
> > And from 
> > 
> >    ∀ (a,x :: z). fst (g (a,x)) = f a
> >    ∀ (a,x :: z). snd (g (a,x)) = x
> > 
> > we can conclude that
> > 
> >   g = first f
> > 
> > as intended.
> > 
> > Cheers,
> > Joachim
> > 
> > 
> > 
> > _______________________________________________
> > 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180724/52f637f8/attachment.sig>

From erkokl at gmail.com  Tue Jul 24 17:51:52 2018
From: erkokl at gmail.com (Levent Erkok)
Date: Tue, 24 Jul 2018 10:51:52 -0700
Subject: [Haskell-cafe] how to terminate a (Posix) process and all its
	subprocesses?
In-Reply-To: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
References: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
Message-ID: <CACOpX0dor8h-_srOSRMoyMxEpZsTbXSAAw7JPMUm7LA+MyARyA@mail.gmail.com>

Hi Johannes:

I had a similar question a few years back using the async library and in
particular the 'race' function. I got a nice answer on StackOverflow:


https://stackoverflow.com/questions/24446154/control-concurrent-async-race-and-runinteractiveprocess

I think you can use the ideas in there. Bottom line: You can use a
combination of 'onException' and 'terminateProcess' and let your spawned
processes clean-up after themselves properly.

Cheers,

-Levent.

On Tue, Jul 24, 2018 at 6:42 AM, Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Dear Cafe,
>
> I am using
> https://hackage.haskell.org/package/process-1.6.4.0/docs/
> System-Process.html#v:readProcess
> to start an external command, and wait for its completion.
>
> Now I would like to time-out this after a while.
> I can use
> https://hackage.haskell.org/package/base-4.11.1.0/docs/System-Timeout.html
> and this works in simple cases -
>
> but not in case the external command has spawned child processes.
> (cleanupProcess sends SIGTERM but only to the process at the top of
> the tree ?)
>
> I guess I need to use
> https://hackage.haskell.org/package/unix-2.7.2.2/docs/
> System-Posix-Process.html
> but that seems rather low-level - and I don't see how I would
> get the ProcessID of the process started by  readProcess,
> so I'd also have to re-do that.
>
> Is there an abstraction/library that would help here?
>
> Thanks - J.W.
> _______________________________________________
> 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/20180724/1d7d675b/attachment.html>

From johnw at newartisans.com  Tue Jul 24 17:54:40 2018
From: johnw at newartisans.com (John Wiegley)
Date: Tue, 24 Jul 2018 10:54:40 -0700
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
In-Reply-To: <7522086b03458549b17482d30cc511ebc612724d.camel@joachim-breitner.de>
 (Joachim Breitner's message of "Tue, 24 Jul 2018 13:37:46 -0400")
References: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
 <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>
 <CAD6SzRKe8q87ZznN8W1Uz0wfmTzrx7PqqQ834yhPeW0U=faF_w@mail.gmail.com>
 <7522086b03458549b17482d30cc511ebc612724d.camel@joachim-breitner.de>
Message-ID: <m2muugbjtr.fsf@newartisans.com>

>>>>> "JB" == Joachim Breitner <mail at joachim-breitner.de> writes:

JB> I felt inspired to revive the free theorem calculator and gave it a new
JB> home (and a modern, browser-only, FRP-based implementation):

Thank you, Joachim! I've used that calculator often, and was sad to see it
shut down.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 658 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180724/afd955f4/attachment.sig>

From litchard.michael at gmail.com  Tue Jul 24 18:04:38 2018
From: litchard.michael at gmail.com (Michael Litchard)
Date: Tue, 24 Jul 2018 11:04:38 -0700
Subject: [Haskell-cafe] Need some help figuring out how to use the repl with
 reflex using only stack
Message-ID: <CAPYUwg_sbDbxz=g-yQP4c3v_tokjcjwpMDOQ-Xb=ZLs1jw7iFg@mail.gmail.com>

I've created a minimal example to show you what I've tried. Below is also a
truncated error log. Could someone help me figure out how to get ghci
working with this example?

https://github.com/mlitchard/reflex-todo

stack repl --stack-yaml=stack-ghc.yaml

Truncated error log

Error: -- While building custom Setup.hs for package jsaddle-dom-0.9.2.0
using:
/home/mlitchard/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2
--builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0 build
lib:jsaddle-dom --ghc-options " -ddump-hi -ddump-to-file" Process exited
with code: ExitFailure 1 Logs have been written to:
/home/mlitchard/projects/git/reflex-todo/.stack-work/logs/jsaddle-dom-0.9.2.0.log

Preprocessing library jsaddle-dom-0.9.2.0... [587 of 599] Compiling
JSDOM.Custom.XMLHttpRequest ( src/JSDOM/Custom/XMLHttpRequest.hs,
.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/JSDOM/Custom/XMLHttpRequest.o
)
/home/mlitchard/projects/git/reflex-todo/.stack-work/downloaded/Vheiln5kqwE0/src/JSDOM/Custom/XMLHttpRequest.hs:39:46:
error: • Could not deduce (Control.Monad.Catch.MonadThrow
Language.Javascript.JSaddle.Types.JSM) arising from a use of ‘throwM’ from
the context: MonadDOM m bound by the type signature for: throwXHRError ::
MonadDOM m => Maybe XHRError -> m () at
src/JSDOM/Custom/XMLHttpRequest.hs:38:1-53 • In the second argument of
‘(.)’, namely ‘throwM’ In the second argument of ‘maybe’, namely ‘(liftDOM
. throwM)’ In the expression: maybe (return ()) (liftDOM . throwM)
/home/mlitchard/projects/git/reflex-todo/.stack-work/downloaded/Vheiln5kqwE0/src/JSDOM/Custom/XMLHttpRequest.hs:42:20:
error: • No instance for (Control.Monad.Catch.MonadMask
Language.Javascript.JSaddle.Types.JSM) arising from a use of ‘bracket’ • In
the first argument of ‘(.)’, namely ‘bracket aquire id’ In the expression:
bracket aquire id . const In an equation for ‘withEvent’: withEvent aquire
= bracket aquire id . const
/home/mlitchard/projects/git/reflex-todo/.stack-work/downloaded/Vheiln5kqwE0/src/JSDOM/Custom/XMLHttpRequest.hs:45:31:
error: • Could not deduce (Control.Monad.Catch.MonadCatch
Language.Javascript.JSaddle.Types.JSM) arising from an operator section
from the context: MonadDOM m bound by the type signature for: send' ::
MonadDOM m => XMLHttpRequest -> Maybe JSVal -> m () at
src/JSDOM/Custom/XMLHttpRequest.hs:44:1-62 • In the expression:
(`onException` abort self) In the second argument of ‘($)’, namely
‘(`onException` abort self) $ do { result <- liftIO newEmptyMVar; r <-
withEvent (onAsync self Generated.error . liftIO $ putMVar result (Just
XHRError)) $ withEvent (onAsync self abortEvent . liftIO $ putMVar result
(Just XHRAborted)) $ withEvent (onAsync self load . liftIO $ putMVar result
Nothing) $ do { void $ case mbVal of { Nothing -> ... Just val -> ... };
liftIO $ takeMVar result }; throwXHRError r }’ In the expression: liftDOM $
(`onException` abort self) $ do { result <- liftIO newEmptyMVar; r <-
withEvent (onAsync self Generated.error . liftIO $ putMVar result (Just
XHRError)) $ withEvent (onAsync self abortEvent . liftIO $ putMVar result
(Just XHRAborted)) $ withEvent (onAsync self load . liftIO $ putMVar result
Nothing) $ do { void $ case mbVal of { Nothing -> ... Just val -> ... };
liftIO $ takeMVar result }; throwXHRError r }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180724/f0d73ed2/attachment.html>

From allbery.b at gmail.com  Tue Jul 24 18:05:39 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 24 Jul 2018 14:05:39 -0400
Subject: [Haskell-cafe] how to terminate a (Posix) process and all its
	subprocesses?
In-Reply-To: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
References: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
Message-ID: <CAKFCL4W_8z7a_ViCQmWBYj31SndoaUJPdhq6RO_JZcpn2-PGnw@mail.gmail.com>

The trick here is to set the option that creates a process group
(System.Process's config record has a field for this), then extract the
process id of the parent and negate it to get a process group ID. A signal
sent to that will go to the entire process group.

You can do this with System.Process as opposed to System.Posix.Process, but
you need to go digging into internals to get the process ID IIRC.

On Tue, Jul 24, 2018 at 9:42 AM Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Dear Cafe,
>
> I am using
>
> https://hackage.haskell.org/package/process-1.6.4.0/docs/System-Process.html#v:readProcess
> to start an external command, and wait for its completion.
>
> Now I would like to time-out this after a while.
> I can use
> https://hackage.haskell.org/package/base-4.11.1.0/docs/System-Timeout.html
> and this works in simple cases -
>
> but not in case the external command has spawned child processes.
> (cleanupProcess sends SIGTERM but only to the process at the top of
> the tree ?)
>
> I guess I need to use
>
> https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-Process.html
> but that seems rather low-level - and I don't see how I would
> get the ProcessID of the process started by  readProcess,
> so I'd also have to re-do that.
>
> Is there an abstraction/library that would help here?
>
> Thanks - J.W.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180724/4db92b39/attachment.html>

From david.feuer at gmail.com  Tue Jul 24 18:22:27 2018
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 24 Jul 2018 14:22:27 -0400
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
In-Reply-To: <7522086b03458549b17482d30cc511ebc612724d.camel@joachim-breitner.de>
References: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
 <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>
 <CAD6SzRKe8q87ZznN8W1Uz0wfmTzrx7PqqQ834yhPeW0U=faF_w@mail.gmail.com>
 <7522086b03458549b17482d30cc511ebc612724d.camel@joachim-breitner.de>
Message-ID: <CAMgWh9t-YD2u88tSgCAWTovNU15CfAnxcFU-YV=J54SuMVWFYQ@mail.gmail.com>

Thank you! Are you going to add a place for auxiliary definitions? Perhaps
also a few default definitions like lambdabot uses? As it is, there doesn't
seem to be a way to use non-Prelude to constructors. One more thing, that
was missing from the original: a good explanation of what the output means.
"lift" is particularly mysterious. Lambdabot seems to replace these with
calls to normal Haskell functions. Perhaps that can be done sometimes? One
last thing: the FRP interface seems a bit *too* responsive. It's not fun to
see error messages flashing on and off as I type. Perhaps it would make
sense to add a delay before activating one of those?

On Tue, Jul 24, 2018, 1:38 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> I felt inspired to revive the free theorem calculator and gave it a new
> home (and a modern, browser-only, FRP-based implementation):
>
> http://free-theorems.nomeata.de/
>
> which prints
>
>    forall t1,t2 in TYPES, R in REL(t1,t2).
>     forall (x, y) in lift{(,)}(id,R).
>      (g_{t1} x, g_{t2} y) in lift{(,)}(id,R)
>
> as the free theorem, which is (if one squints) the same as my
>
>   ∀ z z' Rz, ∀ a x x', x Rz x' →
>       fst (g (a,x)) = fst (g (a,x')) ∧ snd (g (a,x)) Rz snd (g (a,x'))
>
> Enjoy,
> Joachim
>
> Am Montag, den 23.07.2018, 10:56 -0700 schrieb Conal Elliott:
> > Thank you, Joachim! I'm refreshing my memory of free theorem
> construction from that blog post. Regards, -- Conal
> >
> > On Mon, Jul 23, 2018 at 8:33 AM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
> > > Hi Conal,
> > >
> > > Am Sonntag, den 22.07.2018, 21:29 -0700 schrieb Conal Elliott:
> > > > Suppose `g :: forall z. (A,z) -> (B,z)`. Is it necessarily the case
> > > > that `g = first f` for some `f :: A -> B` (where `first f (a,b) = (f
> > > > a, b)`), perhaps as a free theorem for the type of `g`?
> > >
> > > there used to be a free theorem calculator at
> > > http://www-ps.iai.uni-bonn.de/ft
> > > but it seems to be down :-(
> > >
> > > There is a shell client, ftshell, lets see what it says…
> > > it does not build with ghc-8.0 any more :-(
> > >
> > > Ah, but lambdabot understands @free:
> > >
> > > <nomeata>   @free g :: forall z. (A,z) -> (B,z)
> > > <lambdabot> $map_Pair $id f . g = g . $map_Pair $id f
> > >
> > > Which is basically what you are writing here:
> > >
> > > > Note that `(A,)` and `(B,)` are functors and that `g` is a natural
> > > > transformation, so `g . fmap h == fmap h . g` for any `h :: u -> v`.
> > > > Equivalently, `g . second h == second h . g` (where `second h (a,b) =
> > > > (a, h b)`).
> > >
> > > Doesn’t that already answer the question? Let’s try to make it more
> > > rigorous. I define
> > >
> > > f :: A -> B
> > > f a = fst (g (a, ())
> > >
> > > and now want to prove that g = first f, using the free theorem… which
> > > is tricky, because the free theorem is actually not as strong as it
> > > could be; it should actually be phrased in terms of relations relation,
> > > which might help with the proof.
> > >
> > > So let me try to calculate the free theorem by hand, following
> > > https://www.well-typed.com/blog/2015/05/parametricity/
> > >
> > > g is related to itself by the relation
> > >
> > >    [forall z. (A,z) -> (B,z)]
> > >
> > > and we can calculate
> > >
> > >   g [forall z. (A,z) -> (B,z)] g
> > > ↔ ∀ z z' Rz, g [(A,z) -> (B,z)] g -- Rz relates z and z'
> > > ↔ ∀ z z' Rz, ∀ p p', p [(A,z)] p' → g p [(B,z)] g p'
> > > ↔ ∀ z z' Rz, ∀ p p', fst p = fst p' ∧ snd p Rz snd p' →
> > >       fst (g p) = fst (g p') ∧ snd (g p) Rz snd (g p')
> > > ↔ ∀ z z' Rz, ∀ a x x', x Rz x' →
> > >       fst (g (a,x)) = fst (g (a,x')) ∧
> > > snd (g (a,x)) Rz snd (g (a,x'))
> > >
> > > We can use this to show
> > >
> > >    ∀ (a,x :: z). fst (g (a,x)) = f a
> > >
> > > using (this is the tricky part that requires thinking)
> > >
> > >    z := z, z' := (), Rz := λ_ _ -> True, a := a, x := x, x' := ()
> > >
> > > as then the theorem implies
> > >
> > >   fst (g (a,x)) = fst (g (a, ()) = f a.
> > >
> > > We can also use it to show
> > >
> > >    ∀ (a,x :: z). snd (g (a,x)) = x
> > >
> > > using
> > >
> > >    z := z, z' := z, Rz := const (= x), a := a, x := x, x' := x
> > >
> > > as then the theorem implies, under the true assumption  x Rz z'
> > >
> > >   (snd (g (a,x))) Rz (snd (g (a,x')))
> > >   ↔ snd (g (a,x)) = x
> > >
> > > And from
> > >
> > >    ∀ (a,x :: z). fst (g (a,x)) = f a
> > >    ∀ (a,x :: z). snd (g (a,x)) = x
> > >
> > > we can conclude that
> > >
> > >   g = first f
> > >
> > > as intended.
> > >
> > > Cheers,
> > > Joachim
> > >
> > >
> > >
> > > _______________________________________________
> > > 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/
> _______________________________________________
> 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/20180724/565230cb/attachment.html>

From mail at joachim-breitner.de  Tue Jul 24 18:47:58 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Jul 2018 14:47:58 -0400
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
In-Reply-To: <CAMgWh9t-YD2u88tSgCAWTovNU15CfAnxcFU-YV=J54SuMVWFYQ@mail.gmail.com>
References: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
 <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>
 <CAD6SzRKe8q87ZznN8W1Uz0wfmTzrx7PqqQ834yhPeW0U=faF_w@mail.gmail.com>
 <7522086b03458549b17482d30cc511ebc612724d.camel@joachim-breitner.de>
 <CAMgWh9t-YD2u88tSgCAWTovNU15CfAnxcFU-YV=J54SuMVWFYQ@mail.gmail.com>
Message-ID: <dc655ecd9f3f5cc5496eb16c82d0d688510df6ee.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 24.07.2018, 14:22 -0400 schrieb David Feuer:
> Thank you! Are you going to add a place for auxiliary definitions?

You wish is my command:
https://github.com/nomeata/free-theorems-static-webui/commit/eb8e820

Should be online in 10mins or so.

> Perhaps also a few default definitions like lambdabot uses?

What do you mean? It has this background theory:
https://github.com/nomeata/free-theorems-static-webui/blob/master/src/KnownDeclarations.hs
(copied from free-theorems-webui)

> As it is, there doesn't seem to be a way to use non-Prelude to
> constructors.

That is fixed now, is it?

> One more thing, that was missing from the original: a good
> explanation of what the output means. "lift" is particularly
> mysterious. Lambdabot seems to replace these with calls to normal
> Haskell functions. Perhaps that can be done sometimes?

Pull requests welcome :-)

> One last thing: the FRP interface seems a bit *too* responsive. It's
> not fun to see error messages flashing on and off as I type. Perhaps
> it would make sense to add a delay before activating one of those?

I guess I can use 
https://hackage.haskell.org/package/reflex-dom-0.3/candidate/docs/Reflex-Dom-Time.html
for this somehow. But I guess I only want to delay errors, not
successes – I will give it a shot.

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180724/b2e0e4ca/attachment.sig>

From johannes.waldmann at htwk-leipzig.de  Tue Jul 24 18:52:44 2018
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 24 Jul 2018 20:52:44 +0200
Subject: [Haskell-cafe] how to terminate a (Posix) process and all its
 subprocesses?
In-Reply-To: <CAKFCL4W_8z7a_ViCQmWBYj31SndoaUJPdhq6RO_JZcpn2-PGnw@mail.gmail.com>
References: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
 <CAKFCL4W_8z7a_ViCQmWBYj31SndoaUJPdhq6RO_JZcpn2-PGnw@mail.gmail.com>
Message-ID: <c89bd088-52c0-917f-1dc8-81285ae22c8a@htwk-leipzig.de>

Hi Brandon, hi Levent,

> The trick here is to set the option that creates a process group

Ah yes!  interruptProcessGroupOf  seems to work here. Thanks very much.

My code:
https://gitlab.imn.htwk-leipzig.de/waldmann/pure-matchbox/blob/master/random-termination.hs#L141
but (apart from its general hackiness) I think it does not work right
when I thread-kill this from within my own program.
Which I don't, at the moment, but certainly will, sometime later.

- J.W.

From mail at joachim-breitner.de  Tue Jul 24 19:15:26 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Jul 2018 15:15:26 -0400
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
In-Reply-To: <dc655ecd9f3f5cc5496eb16c82d0d688510df6ee.camel@joachim-breitner.de>
References: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
 <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>
 <CAD6SzRKe8q87ZznN8W1Uz0wfmTzrx7PqqQ834yhPeW0U=faF_w@mail.gmail.com>
 <7522086b03458549b17482d30cc511ebc612724d.camel@joachim-breitner.de>
 <CAMgWh9t-YD2u88tSgCAWTovNU15CfAnxcFU-YV=J54SuMVWFYQ@mail.gmail.com>
 <dc655ecd9f3f5cc5496eb16c82d0d688510df6ee.camel@joachim-breitner.de>
Message-ID: <5e275bdebcbb908d50affac43864b39abd4917a8.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 24.07.2018, 14:47 -0400 schrieb Joachim Breitner:
> I guess I can use 
> https://hackage.haskell.org/package/reflex-dom-0.3/candidate/docs/Reflex-Dom-Time.html
> for this somehow. But I guess I only want to delay errors, not
> successes – I will give it a shot

Sure, why not:
https://github.com/nomeata/free-theorems-static-webui/commit/20c9aca

it seems to work. If some reflex-expert could check if this makes
sense, that would be great:

-- | Errors are delayed, but successes go through immediatelly
delayError :: (PerformEvent t m, MonadHold t m, TriggerEvent t m, MonadIO (Performable m)) =>
    Dynamic t (Either a b) -> m (Dynamic t (Either a b))
delayError d = do
    delayedEvents <- delay 0.5 (updated d)
    d' <- holdDyn Nothing (Just <$> delayedEvents)
    return $ do
        now <- d
        past <- d'
        return $ case (past, now) of
            (Nothing, _)     -> now    -- before any delayed events arrive
            (_, Right _ )    -> now  -- current value is good
            (Just x, Left _) -> x -- current value is bad, delay

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180724/c9539dce/attachment.sig>

From jo at durchholz.org  Tue Jul 24 19:20:16 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 24 Jul 2018 21:20:16 +0200
Subject: [Haskell-cafe] Design of an extensible system
In-Reply-To: <alpine.LNX.2.21.1807240759280.1329@localhost>
References: <alpine.LNX.2.21.1807221723310.9946@localhost>
 <CAJ727GgV7CKZuODhVyc3H1vE1bimjB5TtXNCwLe9ESui35yyMA@mail.gmail.com>
 <alpine.LNX.2.21.1807240759280.1329@localhost>
Message-ID: <525663ee-8513-4259-fa5b-5e2de7b60865@durchholz.org>

Am 24.07.2018 um 08:07 schrieb Marc Busqué:
>  But, what
> about extensibility? Take for example the Pandoc package, which would be
> similar in design of what I'm trying to do. Say I want to add a
> converter to some mark-up format not supported by Pandoc, and that
> Pandoc team doesn't agree to merge my work in its repo or simply I don't
> have the time to wait until it happens.

You fork Pandoc and add the code you need.
Then you put your extension into a public source repository so that 
others can share your work.
And you ask the Pandoc developers to make their code friendly for extension.

I.e. you do the plugins at the source code level, not at the binary level.

From spam at scientician.net  Tue Jul 24 19:20:39 2018
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 24 Jul 2018 21:20:39 +0200
Subject: [Haskell-cafe] how to terminate a (Posix) process and all its
	subprocesses?
In-Reply-To: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
References: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
Message-ID: <pj7u23$9gu$1@blaine.gmane.org>

On 2018-07-24 15:42, Johannes Waldmann wrote:
> Dear Cafe,
> 
> I am using
> https://hackage.haskell.org/package/process-1.6.4.0/docs/System-Process.html#v:readProcess
> to start an external command, and wait for its completion.
> 

If the process is hostile (e.g. fork bomb + countermeasures), then the
*only* realiable way to do this is to use cgroups.

Obviously, this applies to Linux only. I'm not sure there's actually any
truly POSIX way to reliably kill hostile sub-processes. I don't think
so. (The progress group thing doesn't work if the process is hostile.
It'll work fine otherwise.)

Regards,


From david.feuer at gmail.com  Tue Jul 24 19:21:08 2018
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 24 Jul 2018 15:21:08 -0400
Subject: [Haskell-cafe] Free theorem for `forall z. (A,z) -> (B,z)`?
In-Reply-To: <5e275bdebcbb908d50affac43864b39abd4917a8.camel@joachim-breitner.de>
References: <CAD6SzRKD3dtDrO4f1hwObzH7zD5XcJ0ko7iqY6U=4C8DDE=q2g@mail.gmail.com>
 <831352097659f77128f7d85384891791368720ee.camel@joachim-breitner.de>
 <CAD6SzRKe8q87ZznN8W1Uz0wfmTzrx7PqqQ834yhPeW0U=faF_w@mail.gmail.com>
 <7522086b03458549b17482d30cc511ebc612724d.camel@joachim-breitner.de>
 <CAMgWh9t-YD2u88tSgCAWTovNU15CfAnxcFU-YV=J54SuMVWFYQ@mail.gmail.com>
 <dc655ecd9f3f5cc5496eb16c82d0d688510df6ee.camel@joachim-breitner.de>
 <5e275bdebcbb908d50affac43864b39abd4917a8.camel@joachim-breitner.de>
Message-ID: <CAMgWh9uE8vQfZxNkUKuPEtdYN_kmKW5ybOA8by8dqGkHrzGR9Q@mail.gmail.com>

Personally, I'm old-fashioned. I don't mind having to press a button to
make it go. But my preferences are obviously not the end of the discussion.

On Tue, Jul 24, 2018, 3:15 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, den 24.07.2018, 14:47 -0400 schrieb Joachim Breitner:
> > I guess I can use
> >
> https://hackage.haskell.org/package/reflex-dom-0.3/candidate/docs/Reflex-Dom-Time.html
> > for this somehow. But I guess I only want to delay errors, not
> > successes – I will give it a shot
>
> Sure, why not:
> https://github.com/nomeata/free-theorems-static-webui/commit/20c9aca
>
> it seems to work. If some reflex-expert could check if this makes
> sense, that would be great:
>
> -- | Errors are delayed, but successes go through immediatelly
> delayError :: (PerformEvent t m, MonadHold t m, TriggerEvent t m, MonadIO
> (Performable m)) =>
>     Dynamic t (Either a b) -> m (Dynamic t (Either a b))
> delayError d = do
>     delayedEvents <- delay 0.5 (updated d)
>     d' <- holdDyn Nothing (Just <$> delayedEvents)
>     return $ do
>         now <- d
>         past <- d'
>         return $ case (past, now) of
>             (Nothing, _)     -> now    -- before any delayed events arrive
>             (_, Right _ )    -> now  -- current value is good
>             (Just x, Left _) -> x -- current value is bad, delay
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> 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/20180724/17f8f257/attachment.html>

From david.feuer at gmail.com  Tue Jul 24 19:26:16 2018
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 24 Jul 2018 15:26:16 -0400
Subject: [Haskell-cafe] how to terminate a (Posix) process and all its
	subprocesses?
In-Reply-To: <pj7u23$9gu$1@blaine.gmane.org>
References: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
 <pj7u23$9gu$1@blaine.gmane.org>
Message-ID: <CAMgWh9vbCFE91n29Q40NHduORW=zwsT0-MAm+2i2B=E1pAhwjg@mail.gmail.com>

If the process is not thought to be hostile, I imagine it's best to first
try signaling only the parent, and only signal the group if necessary.
Otherwise, you may prevent it from cleaning up after itself properly. Dunno
how to wait for the group to die.

On Tue, Jul 24, 2018, 3:21 PM Bardur Arantsson <spam at scientician.net> wrote:

> On 2018-07-24 15:42, Johannes Waldmann wrote:
> > Dear Cafe,
> >
> > I am using
> >
> https://hackage.haskell.org/package/process-1.6.4.0/docs/System-Process.html#v:readProcess
> > to start an external command, and wait for its completion.
> >
>
> If the process is hostile (e.g. fork bomb + countermeasures), then the
> *only* realiable way to do this is to use cgroups.
>
> Obviously, this applies to Linux only. I'm not sure there's actually any
> truly POSIX way to reliably kill hostile sub-processes. I don't think
> so. (The progress group thing doesn't work if the process is hostile.
> It'll work fine otherwise.)
>
> Regards,
>
> _______________________________________________
> 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/20180724/c36a498b/attachment-0001.html>

From allbery.b at gmail.com  Tue Jul 24 19:33:04 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 24 Jul 2018 15:33:04 -0400
Subject: [Haskell-cafe] how to terminate a (Posix) process and all its
	subprocesses?
In-Reply-To: <CAMgWh9vbCFE91n29Q40NHduORW=zwsT0-MAm+2i2B=E1pAhwjg@mail.gmail.com>
References: <e1253585-0f11-c871-c1e8-6e212dd5b67a@htwk-leipzig.de>
 <pj7u23$9gu$1@blaine.gmane.org>
 <CAMgWh9vbCFE91n29Q40NHduORW=zwsT0-MAm+2i2B=E1pAhwjg@mail.gmail.com>
Message-ID: <CAKFCL4UJjz4z+99Gqq3pJVOz60Enyvyd+zbiKrVrbPG2pNZU6w@mail.gmail.com>

https://downloads.haskell.org/~ghc/latest/docs/html/libraries/unix-2.7.2.2/System-Posix-Process.html#v:getGroupProcessStatus
(at a lower level, this is waitpid() with a negative process ID, expressing
the process group whose leader has abs(process ID)).

And yes, if a process puts itself into its own process group, it will be
immune to control in this fashion. You can do a bit more with sessions
instead of pgroups, but then a process could put itself into its own
session. cgroups are pretty much the only way to avoid this… if and only if
you prevent processes in a given cgroup from creating new cgroups. It's
something of an infinite regression.

As for cleanup, the convention is you use signal 15 (SIGTERM) to indicate
"clean up and exit". If after a reasonable amount of time (typically some
number of seconds) something is still running, you repeat with signal 9
(SIGKILL, which can't be blocked or masked). SIGTERM is usually sent to the
entire process group, as individual processes may have their own distinct
cleanup needs.

On Tue, Jul 24, 2018 at 3:26 PM David Feuer <david.feuer at gmail.com> wrote:

> If the process is not thought to be hostile, I imagine it's best to first
> try signaling only the parent, and only signal the group if necessary.
> Otherwise, you may prevent it from cleaning up after itself properly. Dunno
> how to wait for the group to die.
>
> On Tue, Jul 24, 2018, 3:21 PM Bardur Arantsson <spam at scientician.net>
> wrote:
>
>> On 2018-07-24 15:42, Johannes Waldmann wrote:
>> > Dear Cafe,
>> >
>> > I am using
>> >
>> https://hackage.haskell.org/package/process-1.6.4.0/docs/System-Process.html#v:readProcess
>> > to start an external command, and wait for its completion.
>> >
>>
>> If the process is hostile (e.g. fork bomb + countermeasures), then the
>> *only* realiable way to do this is to use cgroups.
>>
>> Obviously, this applies to Linux only. I'm not sure there's actually any
>> truly POSIX way to reliably kill hostile sub-processes. I don't think
>> so. (The progress group thing doesn't work if the process is hostile.
>> It'll work fine otherwise.)
>>
>> Regards,
>>
>> _______________________________________________
>> 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.



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180724/4ff0896b/attachment.html>

From felix at alternativebit.fr  Wed Jul 25 08:33:45 2018
From: felix at alternativebit.fr (=?utf-8?Q?F=C3=A9lix=20Baylac?=)
Date: Wed, 25 Jul 2018 10:33:45 +0200
Subject: [Haskell-cafe] Integrate GHC-API with Cabal
Message-ID: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>

Dear cafe,

I am currently working on a project [1] which aims to index the code published on
Stackage in order to provide a "code example" database. Basically, for each
library,  I want to generate a real-world example corpus for each exported 
symbol.

Before generating this database, I need to retrieve the exported symbol of a 
package. So far, I have been gathering the dependencies and integrating them in
the GHC pkg database using an external stack call, I then parse the cabal file
 and load the exposed modules using the GHC API and gather the exported
 symbols*.

It works pretty reliably on the simple packages, however, I end up with some 
missing dynamic flags for some more advanced packages (missing c includes, c 
libraries, ASM flags, etc.). I then started to parse and load these missing 
attributes to GHC until I stepped back for a moment and realized I was 
re-implementing cabal build.

I then looked for a way to "hook" my GHC API code in cabal build. This would
allow cabal to both handle the dependencies gathering as well as setting up the
correct GHC dyn-flags. The only resource I found was [2]. It's really clever, 
however, looks a bit hacky to me. 

Is there a better way to perform this kind of  "hook"?


[1] https://git.alternativebit.fr/NinjaTrappeur/Exhs
[2] http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api-programs-with-cabal/

* I am aware of the hoogle index generated by haddock. However, this index is
  missing when the haddock documentation of a package cannot be generated.

From imantc at gmail.com  Wed Jul 25 09:59:45 2018
From: imantc at gmail.com (Imants Cekusins)
Date: Wed, 25 Jul 2018 12:59:45 +0300
Subject: [Haskell-cafe] Integrate GHC-API with Cabal
In-Reply-To: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>
References: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>
Message-ID: <CAP1qinZU5bQpMLyRn4fqyoSygJU8XXMKxdc2O-r25Zo89XbOfg@mail.gmail.com>

cabal-install package includes useful modules. With these modules it is
possible to read the actual build info. These modules could be added to the
Cabal API.

What are the reasons cabal-install can not be added as a project dependency?

Can some modules be moved from cabal-install to Cabal library?



On 25 July 2018 at 11:33, Félix Baylac <felix at alternativebit.fr> wrote:

> Dear cafe,
>
> I am currently working on a project [1] which aims to index the code
> published on
> Stackage in order to provide a "code example" database. Basically, for each
> library,  I want to generate a real-world example corpus for each exported
> symbol.
>
> Before generating this database, I need to retrieve the exported symbol of
> a
> package. So far, I have been gathering the dependencies and integrating
> them in
> the GHC pkg database using an external stack call, I then parse the cabal
> file
>  and load the exposed modules using the GHC API and gather the exported
>  symbols*.
>
> It works pretty reliably on the simple packages, however, I end up with
> some
> missing dynamic flags for some more advanced packages (missing c includes,
> c
> libraries, ASM flags, etc.). I then started to parse and load these
> missing
> attributes to GHC until I stepped back for a moment and realized I was
> re-implementing cabal build.
>
> I then looked for a way to "hook" my GHC API code in cabal build. This
> would
> allow cabal to both handle the dependencies gathering as well as setting
> up the
> correct GHC dyn-flags. The only resource I found was [2]. It's really
> clever,
> however, looks a bit hacky to me.
>
> Is there a better way to perform this kind of  "hook"?
>
>
> [1] https://git.alternativebit.fr/NinjaTrappeur/Exhs
> [2] http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api-
> programs-with-cabal/
>
> * I am aware of the hoogle index generated by haddock. However, this index
> is
>   missing when the haddock documentation of a package cannot be generated.
> _______________________________________________
> 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/20180725/ddf6560a/attachment.html>

From matthewtpickering at gmail.com  Wed Jul 25 11:57:15 2018
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 25 Jul 2018 13:57:15 +0200
Subject: [Haskell-cafe] Integrate GHC-API with Cabal
In-Reply-To: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>
References: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>
Message-ID: <CALuQ0m9Yj9Y_H=GXbkJUOq898xi2SaUu7_3_O08u-KTMsKBvWw@mail.gmail.com>

You can implement your tool as a source plugin and then it will work with
any method of building.

On Wed, 25 Jul 2018, 10:34 Félix Baylac, <felix at alternativebit.fr> wrote:

> Dear cafe,
>
> I am currently working on a project [1] which aims to index the code
> published on
> Stackage in order to provide a "code example" database. Basically, for each
> library,  I want to generate a real-world example corpus for each exported
> symbol.
>
> Before generating this database, I need to retrieve the exported symbol of
> a
> package. So far, I have been gathering the dependencies and integrating
> them in
> the GHC pkg database using an external stack call, I then parse the cabal
> file
>  and load the exposed modules using the GHC API and gather the exported
>  symbols*.
>
> It works pretty reliably on the simple packages, however, I end up with
> some
> missing dynamic flags for some more advanced packages (missing c includes,
> c
> libraries, ASM flags, etc.). I then started to parse and load these
> missing
> attributes to GHC until I stepped back for a moment and realized I was
> re-implementing cabal build.
>
> I then looked for a way to "hook" my GHC API code in cabal build. This
> would
> allow cabal to both handle the dependencies gathering as well as setting
> up the
> correct GHC dyn-flags. The only resource I found was [2]. It's really
> clever,
> however, looks a bit hacky to me.
>
> Is there a better way to perform this kind of  "hook"?
>
>
> [1] https://git.alternativebit.fr/NinjaTrappeur/Exhs
> [2]
> http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api-programs-with-cabal/
>
> * I am aware of the hoogle index generated by haddock. However, this index
> is
>   missing when the haddock documentation of a package cannot be generated.
> _______________________________________________
> 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/20180725/9723a6dd/attachment.html>

From alex at functionalworks.com  Wed Jul 25 15:14:31 2018
From: alex at functionalworks.com (Alex Mesropians)
Date: Wed, 25 Jul 2018 16:14:31 +0100
Subject: [Haskell-cafe] Haskell Opportunity - New York - Blockchain
Message-ID: <CAOsGrQFzNeu1OXce3=LTDmOeanrEU5GXYr0prEXayFK1T9LOPg@mail.gmail.com>

Hey All,

All Haskell engineers in the US we have a new and exciting role with a
blockchain firm who are rapidly expanding! Check them out - Haskell Role
<http://t.sidekickopen13.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs5v0RBRW2BWcFz1qMyFKW65jBJH56dK7Rf1ccvNv02?t=https%3A%2F%2Ffunctional.works-hub.com%2Fjobs%2Fsoftware-engineer-new-york-new-york-united-states-7fd34%3Futm_source%3DAlex%26utm_medium%3DAlex%26utm_campaign%3DAlex&si=5907627934744576&pi=512b8947-5d06-4f9d-b0de-bdc577ff6353>

Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180725/e59f31fc/attachment.html>

From dxld at darkboxed.org  Wed Jul 25 21:38:28 2018
From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=)
Date: Wed, 25 Jul 2018 23:38:28 +0200
Subject: [Haskell-cafe] Integrate GHC-API with Cabal
In-Reply-To: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>
References: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>
Message-ID: <20180725213828.GA16657@Eli>

Hi,

On Wed, Jul 25, 2018 at 10:33:45AM +0200, Félix Baylac wrote:
> Before generating this database, I need to retrieve the exported symbol of a 
> package. So far, I have been gathering the dependencies and integrating them in
> the GHC pkg database using an external stack call, I then parse the cabal file
>  and load the exposed modules using the GHC API and gather the exported
>  symbols*.
> 
> It works pretty reliably on the simple packages, however, I end up with some 
> missing dynamic flags for some more advanced packages (missing c includes, c 
> libraries, ASM flags, etc.). I then started to parse and load these missing 
> attributes to GHC until I stepped back for a moment and realized I was 
> re-implementing cabal build.

I think you might be interrested in one of my packages,
[cabal-helper](https://hackage.haskell.org/package/cabal-helper). It's
geard more towards editor tooling but I think it should work for your
use case too.

Basically you'd have to do `cabal install --only-dependencies && cabal
configure && cabal build` for each package you want to inspect and
then cabal-helpers API boils down to giving you a list of GHC
flags/module names you need to pass into the GHC API to make it work.

(The `cabal build` step is needed to run preprocessors like hsc2hs and
compile C dependencies, but once cabal has taken care of that you can
usually just load the package without problems.)

Here's some example code you can use to get started (from our tests):
https://github.com/DanielG/cabal-helper/blob/7fc3b9d468a4a2997a7fed63e378567f2ef3a401/tests/GhcSession.hs#L96

Quoting from the above, the main part is:

```
let qe = mkQueryEnv dir (dir </> "dist")
cs <- runQuery qe $ components $ (,,) <$> entrypoints <.> ghcOptions
forM cs $ \(ep, opts, cn) -> do
  ...
```

where `dir` is the directory containing the cabal file of the project
you're trying to load into GHC. The do block gets called for each
component in the cabal project with 1) `ep` a datatype containing
(among other things) the list of modules you need to pass to GHC, 2)
the GHC flags `opts` and 3) `ch` the component name.

API docs are over here:
https://hackage.haskell.org/package/cabal-helper-0.8.0.2/docs/Distribution-Helper.html.
They're probably not all that much use if you're not familliar with
Cabal's inner workings though so feel free to ask me questions.

--Daniel

From dxld at darkboxed.org  Wed Jul 25 21:43:36 2018
From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=)
Date: Wed, 25 Jul 2018 23:43:36 +0200
Subject: [Haskell-cafe] Integrate GHC-API with Cabal
In-Reply-To: <20180725183048.gyoacsmblgvkm3ya@thinkpad-nix>
References: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>
 <20180725114713.GA11704@Eli>
 <20180725183048.gyoacsmblgvkm3ya@thinkpad-nix>
Message-ID: <20180725214336.GA16698@Eli>

Hi,

On Wed, Jul 25, 2018 at 08:30:48PM +0200, Félix Baylac wrote:
> Thanks a lot for this really helpful message.
> 
> > I think you might be interrested in one of my packages,
> > [cabal-helper](https://hackage.haskell.org/package/cabal-helper). It's
> > geard more towards editor tooling but I think it should work for your
> > use case too.
> 
> Indeed, looks like what I'm looking for.
> 
> > Basically you'd have to do `cabal install --only-dependencies && cabal
> > configure && cabal build` for each package you want to inspect and
> > then cabal-helpers API boils down to giving you a list of GHC
> > flags/module names you need to pass into the GHC API to make it work.
> > 
> > (The `cabal build` step is needed to run preprocessors like hsc2hs and
> > compile C dependencies, but once cabal has taken care of that you can
> > usually just load the package without problems.)
> 
> I had to make some modifications and jump in some nix hoops to use 
> cabal-install instead of stack to build the packages, but indeed, it does work
> like a charm.

Ah, I forgot you said you were using Stack. You can use it too if you
prefer. You just have to use `stack path --dist-dir` (run in the
project directory) to get the path to the dist-dir after running
`stack build` instead of using the hardcoded `$PWD/dist` value. There
have been some reports of issues with stack using weird combinations
of Cabal-library versions though which so it might need some tweaking.

> This is perfect, I just tried your library following this example on the text
> package and it seems to do the job. Thanks a lot, fixing this problem without
> re-inventing the wheel is a huge relief.
> 
> Do you mind if I write a small article on this integration. 

No not at all, send me a link when you're done.

> It'll probably prevent some other people from using dodgy hacks.

Well I'm not sure I would call cabal-helper not a dodgy hack but at
least it's a (sort of) well maintained hack :)

--Daniel

PS: Looks like I messed up the list-reply on my original message so I
resent it and I'm CC'ing haskell-cafe on this one. Sorry about that.
-------------- 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/20180725/42883e73/attachment.sig>

From anthony_clayden at clear.net.nz  Wed Jul 25 23:02:40 2018
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Thu, 26 Jul 2018 11:02:40 +1200
Subject: [Haskell-cafe] Why does this result in a runtime loop instead
 of a type error or typechecker loop?
Message-ID: <CAM7nRYSXbwv5NxkKj-Z3wEMd9aDL_jRLUduYC6yBpgFEYjnADg@mail.gmail.com>

On Tue, Jul 24, 2018 at 5:52 AM,Ryan Reich wrote:
> This seems like the canonical illustration of the dangers of UndecidableInstances.

No I don't buy that explanation. The worst UndecidableInstances can do
is send the type checker into a loop.

For mutually recursive functions to cause looping, you don't need
classes at all:

foo :: Bool -> ()
foo x = bar x
bar :: () -> Bool
bar x = foo x

No typechecking will detect that loop. This `HasBool` example is just
an obfuscated way to write that loop(?)


There's some odd thigs in the OP:

Why use OVERLAPPABLE? Neither of those instances need it.

Or are there more instances in the imports? (There must at least be
the definition for class `Has`.) If so, what are their constraints?
And what are their implementations? Perhaps that's causing the
looping?

Will `runRIO` or `view` use one of those other instances?

What does this mean: "I can compile an equivalent program; it loops on
execution."?

There doesn't need to be a `Bool` in the "environment": the `HasBool
a` instance introduces `Bool` in its constraint.

I suggest boiling this down to a stand-alone program not needing
imports. Then tell the whole story.

AntC


On Mon, Jul 23, 2018 at 2:10 PM, Theodore Lief Gannon <
tanuki at gmail.com
<http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>>
wrote:

>* λ. :set -XFlexibleContexts -XFlexibleInstances -XMultiParamTypeClasses
*>* -XUndecidableInstances
*>* λ. import RIO
*>* λ. import Data.Has
*>* λ. class HasBool a where boolL :: Lens' a Bool
*>* λ. instance {-#OVERLAPPABLE#-} HasBool a => Has Bool a where hasLens =
*>* boolL
*>* λ. instance {-#OVERLAPPABLE#-} Has Bool a => HasBool a where boolL =
*>* hasLens
*>* λ. runRIO () $ view boolL
*>* ^CInterrupted.
*>>* The RIO environment () doesn't contain a Bool. I can see how the
*>* typechecker might get lost in this, but I can compile an equivalent
*>* program; it loops on execution.
*>>* _______________________________________________
*>* Haskell-Cafe mailing list
*>* To (un)subscribe, modify options or view archives go to:
*>* http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
<http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
*>* Only members subscribed via the mailman list are allowed to post.
*>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180723/a47a91b9/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180726/58e75673/attachment.html>

From 78emil at gmail.com  Thu Jul 26 05:39:00 2018
From: 78emil at gmail.com (Emil Axelsson)
Date: Thu, 26 Jul 2018 07:39:00 +0200
Subject: [Haskell-cafe] Why does this result in a runtime loop instead
 of a type error or typechecker loop?
In-Reply-To: <CAM7nRYSXbwv5NxkKj-Z3wEMd9aDL_jRLUduYC6yBpgFEYjnADg@mail.gmail.com>
References: <CAM7nRYSXbwv5NxkKj-Z3wEMd9aDL_jRLUduYC6yBpgFEYjnADg@mail.gmail.com>
Message-ID: <4433ad62-bfa2-0eb0-8eca-4192d7abc898@gmail.com>

Den 2018-07-26 kl. 01:02, skrev Anthony Clayden:
> 
> On Tue, Jul 24, 2018 at 5:52 AM,Ryan Reich wrote:
>  > This seems like the canonical illustration of the dangers of 
> UndecidableInstances.
> 
> No I don't buy that explanation. The worst UndecidableInstances can do 
> is send the type checker into a loop.

I used to have a counter-example to that claim:

https://mail.haskell.org/pipermail/haskell-cafe/2010-January/072357.html

That example was causing looping dictionaries at run time on GHC 6.10. 
But now, on GHC 8.2, the program terminates. But one wonders if there 
are other ways to create looping dictionaries?

/ Emil

From felix at alternativebit.fr  Thu Jul 26 12:43:57 2018
From: felix at alternativebit.fr (=?utf-8?Q?F=C3=A9lix=20Baylac?=)
Date: Thu, 26 Jul 2018 14:43:57 +0200
Subject: [Haskell-cafe] Integrate GHC-API with Cabal
In-Reply-To: <CAP1qinZU5bQpMLyRn4fqyoSygJU8XXMKxdc2O-r25Zo89XbOfg@mail.gmail.com>
References: <1532507625.1682910.1452174960.57B1B977@webmail.messagingengine.com>
 <CAP1qinZU5bQpMLyRn4fqyoSygJU8XXMKxdc2O-r25Zo89XbOfg@mail.gmail.com>
Message-ID: <20180726124357.pemg3gvo3bvhakmh@thinkpad-nix>

Hi,

Thanks for the reply, I somehow missed your message.

> cabal-install package includes useful modules. With these modules it is
> possible to read the actual build info. These modules could be added to the
> Cabal API.

As mentionned in another reply, there's even a library[1] retrieving this kind of
informations.
 
> What are the reasons cabal-install can not be added as a project dependency?

I can depend on it.
 
> Can some modules be moved from cabal-install to Cabal library?

This is a really good question. Seems like exposing this kind of information 
could benefit some other people. 

I am not fimiliar with Cabal internals and have no idea whether this is 
possible nor the amount of work needed for this. I am trying to avoid digging
yet another rabbit whole for now.

[1]: https://hackage.haskell.org/package/cabal-helper

> On 25 July 2018 at 11:33, Félix Baylac <felix at alternativebit.fr> wrote:
> 
> > Dear cafe,
> >
> > I am currently working on a project [1] which aims to index the code
> > published on
> > Stackage in order to provide a "code example" database. Basically, for each
> > library,  I want to generate a real-world example corpus for each exported
> > symbol.
> >
> > Before generating this database, I need to retrieve the exported symbol of
> > a
> > package. So far, I have been gathering the dependencies and integrating
> > them in
> > the GHC pkg database using an external stack call, I then parse the cabal
> > file
> >  and load the exposed modules using the GHC API and gather the exported
> >  symbols*.
> >
> > It works pretty reliably on the simple packages, however, I end up with
> > some
> > missing dynamic flags for some more advanced packages (missing c includes,
> > c
> > libraries, ASM flags, etc.). I then started to parse and load these
> > missing
> > attributes to GHC until I stepped back for a moment and realized I was
> > re-implementing cabal build.
> >
> > I then looked for a way to "hook" my GHC API code in cabal build. This
> > would
> > allow cabal to both handle the dependencies gathering as well as setting
> > up the
> > correct GHC dyn-flags. The only resource I found was [2]. It's really
> > clever,
> > however, looks a bit hacky to me.
> >
> > Is there a better way to perform this kind of  "hook"?
> >
> >
> > [1] https://git.alternativebit.fr/NinjaTrappeur/Exhs
> > [2] http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api-
> > programs-with-cabal/
> >
> > * I am aware of the hoogle index generated by haddock. However, this index
> > is
> >   missing when the haddock documentation of a package cannot be generated.
> > _______________________________________________
> > 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  Thu Jul 26 14:53:20 2018
From: saurabhnanda at gmail.com (Saurabh Nanda)
Date: Thu, 26 Jul 2018 20:23:20 +0530
Subject: [Haskell-cafe] Access violation when stack haddock
 haskell-src-exts since LTS 12.0
In-Reply-To: <CANBN=msjrNqjFb4wGC6GS6cuPb9XcyicRF=Sewny3W2srOGw2g@mail.gmail.com>
References: <CA+6J5GEog6BZ_8kKScD8g=Htr=WRBfmd7pGkus3RAwEw+ZBsmw@mail.gmail.com>
 <CAKT9ecO3Q4NqXXzkyEE3XaK6UMfx+XKF7zKXkFnEVxHSgqq9Aw@mail.gmail.com>
 <CA+6J5GEz59DGMbqxiz2nOkz-pCvzuNqS=PzrCWqdBnU8w8=dNg@mail.gmail.com>
 <CAGegzNDkfrspbjgrMr6ZXTqF7d8TdORcRW7JqbniSwyYsCoySw@mail.gmail.com>
 <CA+6J5GH2X9pm528=ee1OYmXemR4f0xTV1zuCzVKrY8JNM7AeBA@mail.gmail.com>
 <CANBN=msjrNqjFb4wGC6GS6cuPb9XcyicRF=Sewny3W2srOGw2g@mail.gmail.com>
Message-ID: <CAPz=2oGn7At3MhUsrEWzSj6b9MV4jLQm23x99dev44hX-xRWhQ@mail.gmail.com>

Hi,

How does confirm that this bug is being hit. `stack haddock
haskell-src-exts` on LTS-12.1 fails with the following cryptic error:

    --  While building custom Setup.hs for package haskell-src-exts-1.20.2
using:

/home/vl/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.3
--builddir=.stack-work/dist/x86_64-linux/Cabal-2.2.0.1 haddock --html
--hoogle --html-location=../$pkg-$version/
--haddock-option=--hyperlinked-source
    Process exited with code: ExitFailure (-11)
    Logs have been written to:
/home/vl/vacationlabs/haskell/.stack-work/logs/haskell-src-exts-1.20.2.log

The log file doesn't contain an error.

How does one upgrade the haddock version and get stack to use it?

-- Saurabh.


On Mon, Jul 23, 2018 at 11:58 AM Sven Panne <svenpanne at gmail.com> wrote:

> Am Mo., 23. Juli 2018 um 05:49 Uhr schrieb Yuji Yamamoto <
> whosekiteneverfly at gmail.com>:
>
>> Thank you very much!
>>
>> I confirmed the replaced haddock executable can successfully generate the
>> docs!
>>
>
> Yesterday I had quite some trouble because of the Haddock problem, too,
> and I guess I'm not alone: haskell-src-exts has 165 direct reverse
> dependencies, so probably hundreds of Hackage packages are affected by
> this. The workaround is simple (don't use --haddock with stack), but far
> from satisfying and not very obvious.
>
> Given the fact that this affects a very central piece of the Haskell
> infrastructure in its latest stable incarnation (GHC 8.4.3): Can we have an
> 8.4.4 with a fixed Haddock?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
http://www.saurabhnanda.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180726/9b3f9c02/attachment.html>

From anthony_clayden at clear.net.nz  Thu Jul 26 22:31:03 2018
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Fri, 27 Jul 2018 10:31:03 +1200
Subject: [Haskell-cafe] Why does this result in a runtime loop instead
 of a type error or typechecker loop?
Message-ID: <CAM7nRYR=1JbsHuCgipUh9sZxEZG-WY9SEzxjLnDyuduwG0s8tQ@mail.gmail.com>

On Thurs, Jul 26, 2018 at 05:39:00, Emil Axelsson wrote:

>> Den 2018-07-26 kl. 01:02, skrev Anthony Clayden:

>>
 >>>
* On Tue, Jul 24, 2018 at 5:52 AM,Ryan Reich wrote:
*>*>> This seems like the canonical illustration of the dangers of
*
>>>* UndecidableInstances.*
>>
>>* No I don't buy that explanation. The worst UndecidableInstances can do *
>>* is send the type checker into a loop.*

> I used to have a counter-example to that claim:

https://mail.haskell.org/pipermail/haskell-cafe/2010-January/072357.html

> That example was causing looping dictionaries at run time on GHC 6.10.
> But now, on GHC 8.2, the program terminates.

6.10 was rather a long time ago. The whole type inference/improvement
engine has had several overhauls since 2010.

To be clear: you can write looping programs without type classes at
all -- such as mutually recursive functions. You can write looping
programs with type classes -- by turning those functions into methods
in classes. You can write looping programs with type classes that need
`UndecidableInstances` -- by making those classes mutual superclasses
or mutual constraints on instances.

That doesn't mean the `UndecidableInstances` are to 'blame' for the
looping. I would blame the functions/method calls for not reducing the
problem.


> But one wonders if there are other ways to create looping dictionaries?

With `UndecidableInstances`, yes there's plenty. And I expect that'll
make the typechecker loop at compile time.

The O.P. here is not getting typechecker looping, so I think the
explanation is to do with method calls -- for which we need to see
what's going on in the imports.

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

From olf at aatal-apotheke.de  Fri Jul 27 13:49:59 2018
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Fri, 27 Jul 2018 15:49:59 +0200 (CEST)
Subject: [Haskell-cafe] stack test hangs when using 1.7.1 but completes with
	1.4.0
Message-ID: <1545367795.77056.1532699399796@webmail.strato.de>

Dear cafe, 

I recently upgraded (with some trouble) to stack-1.7.1 from 1.4.0. I have an older project using lts-9.2 that builds just fine when using the new stack, but it hangs on `stack test`. The difference is shown below. I suspect it is something that needs to be upgraded alongside stack. Maybe Cabal? Upgrading stack was troublesome because of different index formats, which is why using the other stack causes the rebuilds of my extra-deps, I suppose. When using stack --verbosity debug I see messages of the form

Error while decoding $HOME/.stack/indices/Hackage/01-index.cache
...
(this might not be an error, when switching between stack versions)

Any help welcome.
Olaf

$> /usr/bin/stack-1.7.1 test
Populated index cache.
$MYPACKAGE: unregistering (missing dependencies: glpk-hs)
gasp-1.0.1.0: unregistering (old configure information not found)
glpk-hs-0.5: unregistering (missing dependencies: gasp)
gasp-1.0.1.0: configure
gasp-1.0.1.0: build
gasp-1.0.1.0: copy/register
glpk-hs-0.5: configure
glpk-hs-0.5: build
glpk-hs-0.5: copy/register
$MYPACKAGE: configure (lib + exe + test) 
Configuring $MYPACKAGE...
$MYPACKAGE: build (lib + exe + test) 
Preprocessing library $MYPACKAGE...
<<< some more output ... >>>
Registering $MYPACKAGE...
$MYPACKAGE: test (suite: $PACKAGENAME-test)
<<< with --verbosity debug >>>
[debug] Run process within $PACKAGEDIR/: $PACKAGEDIR/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/$PACKAGENAME-testStub/$PACKAGENAME-testStub
@(src/Stack/Build/Execute.hs:1711:27)
Progress 1/2: $MYPACKAGE
<<< Hangs from here on, does not consume CPU cycles >>>

$> /usr/bin/stack-1.4.0 test
Populated index cache.
$MYPACKAGE: unregistering (missing dependencies: glpk-hs)
gasp-1.0.1.0: unregistering (old configure information not found)
glpk-hs-0.5: unregistering (missing dependencies: gasp)
gasp-1.0.1.0: configure
gasp-1.0.1.0: build
gasp-1.0.1.0: copy/register
glpk-hs-0.5: configure
glpk-hs-0.5: build
glpk-hs-0.5: copy/register
$MYPACKAGE: configure (lib + exe + test) 
Configuring $MYPACKAGE...
$MYPACKAGE: build (lib + exe + test) 
Preprocessing library $MYPACKAGE...
<<< some more output >>>
Progress: 3/4+++ OK, passed 100 tests.
<<< some more output >>>
Completed 4 action(s).

From pervasiveproximity at gmail.com  Fri Jul 27 14:47:05 2018
From: pervasiveproximity at gmail.com (Sridhar Ratnakumar)
Date: Fri, 27 Jul 2018 10:47:05 -0400
Subject: [Haskell-cafe] Need some help figuring out how to use the repl
 with reflex using only stack
In-Reply-To: <CAPYUwg_sbDbxz=g-yQP4c3v_tokjcjwpMDOQ-Xb=ZLs1jw7iFg@mail.gmail.com>
References: <CAPYUwg_sbDbxz=g-yQP4c3v_tokjcjwpMDOQ-Xb=ZLs1jw7iFg@mail.gmail.com>
Message-ID: <CA+iqG-aEbx-soN_HOXskyDhBAOaYmBdASSjreC7vUL=EpPChYg@mail.gmail.com>

This doesn't directly answer your question, however in the case that all
you want is to get started with a simple Reflex-DOM app, I'd suggest
starting with obelisk:
- https://github.com/obsidiansystems/obelisk
- https://youtu.be/riJuXDIUMA0?t=30m15s

Then you can just run `ob repl` to get into the repl.

cheers,
-srid
https://www.srid.ca/


On Tue, 24 Jul 2018 at 14:04, Michael Litchard <litchard.michael at gmail.com>
wrote:

> I've created a minimal example to show you what I've tried. Below is also
> a truncated error log. Could someone help me figure out how to get ghci
> working with this example?
>
> https://github.com/mlitchard/reflex-todo
>
> stack repl --stack-yaml=stack-ghc.yaml
>
> Truncated error log
>
> Error: -- While building custom Setup.hs for package jsaddle-dom-0.9.2.0
> using:
> /home/mlitchard/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2
> --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0 build
> lib:jsaddle-dom --ghc-options " -ddump-hi -ddump-to-file" Process exited
> with code: ExitFailure 1 Logs have been written to:
> /home/mlitchard/projects/git/reflex-todo/.stack-work/logs/jsaddle-dom-0.9.2.0.log
>
> Preprocessing library jsaddle-dom-0.9.2.0... [587 of 599] Compiling
> JSDOM.Custom.XMLHttpRequest ( src/JSDOM/Custom/XMLHttpRequest.hs,
> .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/JSDOM/Custom/XMLHttpRequest.o
> )
> /home/mlitchard/projects/git/reflex-todo/.stack-work/downloaded/Vheiln5kqwE0/src/JSDOM/Custom/XMLHttpRequest.hs:39:46:
> error: • Could not deduce (Control.Monad.Catch.MonadThrow
> Language.Javascript.JSaddle.Types.JSM) arising from a use of ‘throwM’ from
> the context: MonadDOM m bound by the type signature for: throwXHRError ::
> MonadDOM m => Maybe XHRError -> m () at
> src/JSDOM/Custom/XMLHttpRequest.hs:38:1-53 • In the second argument of
> ‘(.)’, namely ‘throwM’ In the second argument of ‘maybe’, namely ‘(liftDOM
> . throwM)’ In the expression: maybe (return ()) (liftDOM . throwM)
> /home/mlitchard/projects/git/reflex-todo/.stack-work/downloaded/Vheiln5kqwE0/src/JSDOM/Custom/XMLHttpRequest.hs:42:20:
> error: • No instance for (Control.Monad.Catch.MonadMask
> Language.Javascript.JSaddle.Types.JSM) arising from a use of ‘bracket’ • In
> the first argument of ‘(.)’, namely ‘bracket aquire id’ In the expression:
> bracket aquire id . const In an equation for ‘withEvent’: withEvent aquire
> = bracket aquire id . const
> /home/mlitchard/projects/git/reflex-todo/.stack-work/downloaded/Vheiln5kqwE0/src/JSDOM/Custom/XMLHttpRequest.hs:45:31:
> error: • Could not deduce (Control.Monad.Catch.MonadCatch
> Language.Javascript.JSaddle.Types.JSM) arising from an operator section
> from the context: MonadDOM m bound by the type signature for: send' ::
> MonadDOM m => XMLHttpRequest -> Maybe JSVal -> m () at
> src/JSDOM/Custom/XMLHttpRequest.hs:44:1-62 • In the expression:
> (`onException` abort self) In the second argument of ‘($)’, namely
> ‘(`onException` abort self) $ do { result <- liftIO newEmptyMVar; r <-
> withEvent (onAsync self Generated.error . liftIO $ putMVar result (Just
> XHRError)) $ withEvent (onAsync self abortEvent . liftIO $ putMVar result
> (Just XHRAborted)) $ withEvent (onAsync self load . liftIO $ putMVar result
> Nothing) $ do { void $ case mbVal of { Nothing -> ... Just val -> ... };
> liftIO $ takeMVar result }; throwXHRError r }’ In the expression: liftDOM $
> (`onException` abort self) $ do { result <- liftIO newEmptyMVar; r <-
> withEvent (onAsync self Generated.error . liftIO $ putMVar result (Just
> XHRError)) $ withEvent (onAsync self abortEvent . liftIO $ putMVar result
> (Just XHRAborted)) $ withEvent (onAsync self load . liftIO $ putMVar result
> Nothing) $ do { void $ case mbVal of { Nothing -> ... Just val -> ... };
> liftIO $ takeMVar result }; throwXHRError r }
> _______________________________________________
> 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/20180727/7ef95ce6/attachment.html>

From litchard.michael at gmail.com  Fri Jul 27 15:24:45 2018
From: litchard.michael at gmail.com (Michael Litchard)
Date: Fri, 27 Jul 2018 08:24:45 -0700
Subject: [Haskell-cafe] Need some help figuring out how to use the repl
 with reflex using only stack
In-Reply-To: <CA+iqG-aEbx-soN_HOXskyDhBAOaYmBdASSjreC7vUL=EpPChYg@mail.gmail.com>
References: <CAPYUwg_sbDbxz=g-yQP4c3v_tokjcjwpMDOQ-Xb=ZLs1jw7iFg@mail.gmail.com>
 <CA+iqG-aEbx-soN_HOXskyDhBAOaYmBdASSjreC7vUL=EpPChYg@mail.gmail.com>
Message-ID: <CAPYUwg9KnN5zqUsGE1ZQdc2a_PorPOeKrcq4W0TnVVagTkHK4Q@mail.gmail.com>

I've found a solution. I'm sure your answer helps someone with a different
problem.

On Fri, Jul 27, 2018 at 7:47 AM, Sridhar Ratnakumar <
pervasiveproximity at gmail.com> wrote:

> This doesn't directly answer your question, however in the case that all
> you want is to get started with a simple Reflex-DOM app, I'd suggest
> starting with obelisk:
> - https://github.com/obsidiansystems/obelisk
> - https://youtu.be/riJuXDIUMA0?t=30m15s
>
> Then you can just run `ob repl` to get into the repl.
>
> cheers,
> -srid
> https://www.srid.ca/
>
>
> On Tue, 24 Jul 2018 at 14:04, Michael Litchard <litchard.michael at gmail.com>
> wrote:
>
>> I've created a minimal example to show you what I've tried. Below is also
>> a truncated error log. Could someone help me figure out how to get ghci
>> working with this example?
>>
>> https://github.com/mlitchard/reflex-todo
>>
>> stack repl --stack-yaml=stack-ghc.yaml
>>
>> Truncated error log
>>
>> Error: -- While building custom Setup.hs for package jsaddle-dom-0.9.2.0
>> using: /home/mlitchard/.stack/setup-exe-cache/x86_64-linux/Cabal-
>> simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0
>> build lib:jsaddle-dom --ghc-options " -ddump-hi -ddump-to-file" Process
>> exited with code: ExitFailure 1 Logs have been written to:
>> /home/mlitchard/projects/git/reflex-todo/.stack-work/logs/
>> jsaddle-dom-0.9.2.0.log
>>
>> Preprocessing library jsaddle-dom-0.9.2.0... [587 of 599] Compiling
>> JSDOM.Custom.XMLHttpRequest ( src/JSDOM/Custom/XMLHttpRequest.hs,
>> .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/JSDOM/Custom/XMLHttpRequest.o
>> ) /home/mlitchard/projects/git/reflex-todo/.stack-work/
>> downloaded/Vheiln5kqwE0/src/JSDOM/Custom/XMLHttpRequest.hs:39:46: error:
>> • Could not deduce (Control.Monad.Catch.MonadThrow
>> Language.Javascript.JSaddle.Types.JSM) arising from a use of ‘throwM’
>> from the context: MonadDOM m bound by the type signature for: throwXHRError
>> :: MonadDOM m => Maybe XHRError -> m () at src/JSDOM/Custom/XMLHttpRequest.hs:38:1-53
>> • In the second argument of ‘(.)’, namely ‘throwM’ In the second argument
>> of ‘maybe’, namely ‘(liftDOM . throwM)’ In the expression: maybe (return
>> ()) (liftDOM . throwM) /home/mlitchard/projects/git/
>> reflex-todo/.stack-work/downloaded/Vheiln5kqwE0/src/
>> JSDOM/Custom/XMLHttpRequest.hs:42:20: error: • No instance for
>> (Control.Monad.Catch.MonadMask Language.Javascript.JSaddle.Types.JSM)
>> arising from a use of ‘bracket’ • In the first argument of ‘(.)’, namely
>> ‘bracket aquire id’ In the expression: bracket aquire id . const In an
>> equation for ‘withEvent’: withEvent aquire = bracket aquire id . const
>> /home/mlitchard/projects/git/reflex-todo/.stack-work/
>> downloaded/Vheiln5kqwE0/src/JSDOM/Custom/XMLHttpRequest.hs:45:31: error:
>> • Could not deduce (Control.Monad.Catch.MonadCatch
>> Language.Javascript.JSaddle.Types.JSM) arising from an operator section
>> from the context: MonadDOM m bound by the type signature for: send' ::
>> MonadDOM m => XMLHttpRequest -> Maybe JSVal -> m () at src/JSDOM/Custom/XMLHttpRequest.hs:44:1-62
>> • In the expression: (`onException` abort self) In the second argument of
>> ‘($)’, namely ‘(`onException` abort self) $ do { result <- liftIO
>> newEmptyMVar; r <- withEvent (onAsync self Generated.error . liftIO $
>> putMVar result (Just XHRError)) $ withEvent (onAsync self abortEvent .
>> liftIO $ putMVar result (Just XHRAborted)) $ withEvent (onAsync self load .
>> liftIO $ putMVar result Nothing) $ do { void $ case mbVal of { Nothing ->
>> ... Just val -> ... }; liftIO $ takeMVar result }; throwXHRError r }’ In
>> the expression: liftDOM $ (`onException` abort self) $ do { result <-
>> liftIO newEmptyMVar; r <- withEvent (onAsync self Generated.error . liftIO
>> $ putMVar result (Just XHRError)) $ withEvent (onAsync self abortEvent .
>> liftIO $ putMVar result (Just XHRAborted)) $ withEvent (onAsync self load .
>> liftIO $ putMVar result Nothing) $ do { void $ case mbVal of { Nothing ->
>> ... Just val -> ... }; liftIO $ takeMVar result }; throwXHRError r }
>> _______________________________________________
>> 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/20180727/071d2b33/attachment.html>

From sitompulquest at gmail.com  Sat Jul 28 01:02:08 2018
From: sitompulquest at gmail.com (Donald Sitompul)
Date: Sat, 28 Jul 2018 08:02:08 +0700
Subject: [Haskell-cafe] Monad Reader pubs?
Message-ID: <CAAgL=bBpxUB-gCTJ9tDOvgN8mC9en5RFs7XUZ94C+3gHC0=NdA@mail.gmail.com>

I’m looking for past publications of the Monad Reader, where are they now?

Donald Sitompul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180728/f3e9451e/attachment.html>

From vanessa.mchale at iohk.io  Sat Jul 28 01:04:38 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Fri, 27 Jul 2018 20:04:38 -0500
Subject: [Haskell-cafe] Monad Reader pubs?
In-Reply-To: <CAAgL=bBpxUB-gCTJ9tDOvgN8mC9en5RFs7XUZ94C+3gHC0=NdA@mail.gmail.com>
References: <CAAgL=bBpxUB-gCTJ9tDOvgN8mC9en5RFs7XUZ94C+3gHC0=NdA@mail.gmail.com>
Message-ID: <e040d05a-e0ca-1a03-3ef4-a7c933dc14c7@iohk.io>

I believe it's here: https://themonadreader.wordpress.com/


On 07/27/2018 08:02 PM, Donald Sitompul wrote:
>
> I’m looking for past publications of the Monad Reader, where are they now?
>
> Donald Sitompul
>
>
>
> _______________________________________________
> 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/20180727/11c7cd22/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180727/11c7cd22/attachment.sig>

From dennis.raddle at gmail.com  Sat Jul 28 22:04:54 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Sat, 28 Jul 2018 18:04:54 -0400
Subject: [Haskell-cafe] using Haskell more like scripting language
Message-ID: <CAKxLvoorcw8WQZ87JxN6kNijqNaHZJbvvE=J7fpKMttP7OFq5A@mail.gmail.com>

I'm actually working in Purescript, but the issue is pretty much the same
as one would encounter in Haskell.

My application (animation of math-related ideas) is changing constantly.
It's research, and I don't know where I'll be with it next week, or even
tomorrow.

For instance, the kinds of "objects" I'm animating (numbers, equations) and
the way they move and interact with each other is a research project, and
I'm constantly ripping out parts of my application and scavenging them for
variations on a theme.

My objects need state. At this point I'm thinking of just putting the state
into a map with strings as keys and some kind of sum type to represent each
data item I might need.

So if I want to represent that an object has a particular color and
position and velocity,

itemState = M.fromList
  [("color"   , DataColor  blue       )
  ,("position", DataPoint  500.0 100.0)
  ,("velocity", DataVector 50.0 45.0  ) ]

Which starts to look more like a dynamically-typed scripting language. But
it's not hard to work with. I can uses lenses/prisms to inspect and update
state, and it's okay if my program crashes on encountering malformed state.

What this lets me do is create new objects that mix and match parts of old
objects, and copy and paste a lot of the code.

Is there a better way to do this? Is there a compromise I can make that
will allow the compiler to help me out more with finding errors at compile
time?

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

From vanessa.mchale at iohk.io  Sun Jul 29 01:14:18 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Sat, 28 Jul 2018 20:14:18 -0500
Subject: [Haskell-cafe] using Haskell more like scripting language
In-Reply-To: <CAKxLvoorcw8WQZ87JxN6kNijqNaHZJbvvE=J7fpKMttP7OFq5A@mail.gmail.com>
References: <CAKxLvoorcw8WQZ87JxN6kNijqNaHZJbvvE=J7fpKMttP7OFq5A@mail.gmail.com>
Message-ID: <3d4fad07-34e2-6c7f-79dd-2811599277a7@iohk.io>

If everything you use will have a color, position, and velocity I'd just
use a product type, i.e.

data itemState = ItemState Color Point Vector

or even

data ItemState = ItemState (Maybe Color) (Maybe Point) (Maybe Vector)

Alternately, if you do want to go the dynamic route, `Data.Dynamic` in
`base` actually has some facilities for dynamic programming


On 07/28/2018 05:04 PM, Dennis Raddle wrote:
> I'm actually working in Purescript, but the issue is pretty much the
> same as one would encounter in Haskell.
>
> My application (animation of math-related ideas) is changing
> constantly. It's research, and I don't know where I'll be with it next
> week, or even tomorrow.
>
> For instance, the kinds of "objects" I'm animating (numbers,
> equations) and the way they move and interact with each other is a
> research project, and I'm constantly ripping out parts of my
> application and scavenging them for variations on a theme.
>
> My objects need state. At this point I'm thinking of just putting the
> state into a map with strings as keys and some kind of sum type to
> represent each data item I might need.
>
> So if I want to represent that an object has a particular color and
> position and velocity,
>
> itemState = M.fromList
>   [("color"   , DataColor  blue       )
>   ,("position", DataPoint  500.0 100.0)
>   ,("velocity", DataVector 50.0 45.0  ) ]
>
> Which starts to look more like a dynamically-typed scripting language.
> But it's not hard to work with. I can uses lenses/prisms to inspect
> and update state, and it's okay if my program crashes on encountering
> malformed state.
>
> What this lets me do is create new objects that mix and match parts of
> old objects, and copy and paste a lot of the code.
>
> Is there a better way to do this? Is there a compromise I can make
> that will allow the compiler to help me out more with finding errors
> at compile time?
>
> D
>
>
>
>
>
>
>
> _______________________________________________
> 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/20180728/23c31816/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180728/23c31816/attachment.sig>

From michael at snoyman.com  Sun Jul 29 05:17:46 2018
From: michael at snoyman.com (Michael Snoyman)
Date: Sun, 29 Jul 2018 08:17:46 +0300
Subject: [Haskell-cafe] stack test hangs when using 1.7.1 but completes
 with 1.4.0
In-Reply-To: <1545367795.77056.1532699399796@webmail.strato.de>
References: <1545367795.77056.1532699399796@webmail.strato.de>
Message-ID: <CAKT9ecO+iP4kujeqz+pGF5x5jb70UN8digRyxH4xgqrVw_jJiA@mail.gmail.com>

I'd recommend trying to manually run the generated test executable inside
the .stack-work directory and see if it also hangs.

The warning about the index is not a big, and there's no issue with that
format changing

On Fri, Jul 27, 2018, 4:50 PM Olaf Klinke <olf at aatal-apotheke.de> wrote:

> Dear cafe,
>
> I recently upgraded (with some trouble) to stack-1.7.1 from 1.4.0. I have
> an older project using lts-9.2 that builds just fine when using the new
> stack, but it hangs on `stack test`. The difference is shown below. I
> suspect it is something that needs to be upgraded alongside stack. Maybe
> Cabal? Upgrading stack was troublesome because of different index formats,
> which is why using the other stack causes the rebuilds of my extra-deps, I
> suppose. When using stack --verbosity debug I see messages of the form
>
> Error while decoding $HOME/.stack/indices/Hackage/01-index.cache
> ...
> (this might not be an error, when switching between stack versions)
>
> Any help welcome.
> Olaf
>
> $> /usr/bin/stack-1.7.1 test
> Populated index cache.
> $MYPACKAGE: unregistering (missing dependencies: glpk-hs)
> gasp-1.0.1.0: unregistering (old configure information not found)
> glpk-hs-0.5: unregistering (missing dependencies: gasp)
> gasp-1.0.1.0: configure
> gasp-1.0.1.0: build
> gasp-1.0.1.0: copy/register
> glpk-hs-0.5: configure
> glpk-hs-0.5: build
> glpk-hs-0.5: copy/register
> $MYPACKAGE: configure (lib + exe + test)
> Configuring $MYPACKAGE...
> $MYPACKAGE: build (lib + exe + test)
> Preprocessing library $MYPACKAGE...
> <<< some more output ... >>>
> Registering $MYPACKAGE...
> $MYPACKAGE: test (suite: $PACKAGENAME-test)
> <<< with --verbosity debug >>>
> [debug] Run process within $PACKAGEDIR/:
> $PACKAGEDIR/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/$PACKAGENAME-testStub/$PACKAGENAME-testStub
> @(src/Stack/Build/Execute.hs:1711:27)
> Progress 1/2: $MYPACKAGE
> <<< Hangs from here on, does not consume CPU cycles >>>
>
> $> /usr/bin/stack-1.4.0 test
> Populated index cache.
> $MYPACKAGE: unregistering (missing dependencies: glpk-hs)
> gasp-1.0.1.0: unregistering (old configure information not found)
> glpk-hs-0.5: unregistering (missing dependencies: gasp)
> gasp-1.0.1.0: configure
> gasp-1.0.1.0: build
> gasp-1.0.1.0: copy/register
> glpk-hs-0.5: configure
> glpk-hs-0.5: build
> glpk-hs-0.5: copy/register
> $MYPACKAGE: configure (lib + exe + test)
> Configuring $MYPACKAGE...
> $MYPACKAGE: build (lib + exe + test)
> Preprocessing library $MYPACKAGE...
> <<< some more output >>>
> Progress: 3/4+++ OK, passed 100 tests.
> <<< some more output >>>
> Completed 4 action(s).
> _______________________________________________
> 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/20180729/d799d7ea/attachment.html>

From dennis.raddle at gmail.com  Sun Jul 29 07:04:23 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Sun, 29 Jul 2018 03:04:23 -0400
Subject: [Haskell-cafe] using Haskell more like scripting language
In-Reply-To: <3d4fad07-34e2-6c7f-79dd-2811599277a7@iohk.io>
References: <CAKxLvoorcw8WQZ87JxN6kNijqNaHZJbvvE=J7fpKMttP7OFq5A@mail.gmail.com>
 <3d4fad07-34e2-6c7f-79dd-2811599277a7@iohk.io>
Message-ID: <CAKxLvopkOu2WKw4wS_AXjqdpL0ChvDTghEJM=Ve25cQXT2DNvA@mail.gmail.com>

Thanks Vanessa. The issue is that not everything will have a position or
velocity. And some things will have more than those. There's a large
overlapping set of possibilities that I can't quite predict until after
I've finished several versions.

However, I think I have a solution. This is actually in Purescript, which
has has extensible record types. Each object will be represented by its own
unique record, but there are mechanisms to write polymorphic code that
operates on just portions of the records. I think that will get me through
the first few versions of this program.

Purescript also has dynamic types, but I suspect those will be hard to
debug. When I'm developing code, I like to get helpful error messages.
Please, no untraceable crashes from many levels deep in the stack. I don't
know if that's what happens when a dynamic type fails to be the expected
type, but I do know that these kinds of crashes are even harder to debug in
Purescript than Haskell, as they happen in the compiled Javascript (which I
don't understand much).

D

Mike


On Sat, Jul 28, 2018 at 9:14 PM, Vanessa McHale <vanessa.mchale at iohk.io>
wrote:

> If everything you use will have a color, position, and velocity I'd just
> use a product type, i.e.
>
> data itemState = ItemState Color Point Vector
>
> or even
>
> data ItemState = ItemState (Maybe Color) (Maybe Point) (Maybe Vector)
>
> Alternately, if you do want to go the dynamic route, `Data.Dynamic` in
> `base` actually has some facilities for dynamic programming
>
> On 07/28/2018 05:04 PM, Dennis Raddle wrote:
>
> I'm actually working in Purescript, but the issue is pretty much the same
> as one would encounter in Haskell.
>
> My application (animation of math-related ideas) is changing constantly.
> It's research, and I don't know where I'll be with it next week, or even
> tomorrow.
>
> For instance, the kinds of "objects" I'm animating (numbers, equations)
> and the way they move and interact with each other is a research project,
> and I'm constantly ripping out parts of my application and scavenging them
> for variations on a theme.
>
> My objects need state. At this point I'm thinking of just putting the
> state into a map with strings as keys and some kind of sum type to
> represent each data item I might need.
>
> So if I want to represent that an object has a particular color and
> position and velocity,
>
> itemState = M.fromList
>   [("color"   , DataColor  blue       )
>   ,("position", DataPoint  500.0 100.0)
>   ,("velocity", DataVector 50.0 45.0  ) ]
>
> Which starts to look more like a dynamically-typed scripting language. But
> it's not hard to work with. I can uses lenses/prisms to inspect and update
> state, and it's okay if my program crashes on encountering malformed state.
>
> What this lets me do is create new objects that mix and match parts of old
> objects, and copy and paste a lot of the code.
>
> Is there a better way to do this? Is there a compromise I can make that
> will allow the compiler to help me out more with finding errors at compile
> time?
>
> D
>
>
>
>
>
>
>
> _______________________________________________
> 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/20180729/c7c6273f/attachment.html>

From leandro at ostera.io  Sun Jul 29 08:08:22 2018
From: leandro at ostera.io (Leandro Ostera)
Date: Sun, 29 Jul 2018 10:08:22 +0200
Subject: [Haskell-cafe] using Haskell more like scripting language
In-Reply-To: <CAKxLvopkOu2WKw4wS_AXjqdpL0ChvDTghEJM=Ve25cQXT2DNvA@mail.gmail.com>
References: <CAKxLvoorcw8WQZ87JxN6kNijqNaHZJbvvE=J7fpKMttP7OFq5A@mail.gmail.com>
 <3d4fad07-34e2-6c7f-79dd-2811599277a7@iohk.io>
 <CAKxLvopkOu2WKw4wS_AXjqdpL0ChvDTghEJM=Ve25cQXT2DNvA@mail.gmail.com>
Message-ID: <CAH2TZMhCWYK4QYeH+RhL-jcy5Ks9yTQAnjqSCpRvVqxv0apU0g@mail.gmail.com>

Correct me if I’m wrong but isn’t this precisely where GADTs would excel?
On Sun, 29 Jul 2018 at 09:04, Dennis Raddle <dennis.raddle at gmail.com> wrote:

> Thanks Vanessa. The issue is that not everything will have a position or
> velocity. And some things will have more than those. There's a large
> overlapping set of possibilities that I can't quite predict until after
> I've finished several versions.
>
> However, I think I have a solution. This is actually in Purescript, which
> has has extensible record types. Each object will be represented by its own
> unique record, but there are mechanisms to write polymorphic code that
> operates on just portions of the records. I think that will get me through
> the first few versions of this program.
>
> Purescript also has dynamic types, but I suspect those will be hard to
> debug. When I'm developing code, I like to get helpful error messages.
> Please, no untraceable crashes from many levels deep in the stack. I don't
> know if that's what happens when a dynamic type fails to be the expected
> type, but I do know that these kinds of crashes are even harder to debug in
> Purescript than Haskell, as they happen in the compiled Javascript (which I
> don't understand much).
>
> D
>
> Mike
>
>
> On Sat, Jul 28, 2018 at 9:14 PM, Vanessa McHale <vanessa.mchale at iohk.io>
> wrote:
>
>> If everything you use will have a color, position, and velocity I'd just
>> use a product type, i.e.
>>
>> data itemState = ItemState Color Point Vector
>>
>> or even
>>
>> data ItemState = ItemState (Maybe Color) (Maybe Point) (Maybe Vector)
>>
>> Alternately, if you do want to go the dynamic route, `Data.Dynamic` in
>> `base` actually has some facilities for dynamic programming
>>
>> On 07/28/2018 05:04 PM, Dennis Raddle wrote:
>>
>> I'm actually working in Purescript, but the issue is pretty much the same
>> as one would encounter in Haskell.
>>
>> My application (animation of math-related ideas) is changing constantly.
>> It's research, and I don't know where I'll be with it next week, or even
>> tomorrow.
>>
>> For instance, the kinds of "objects" I'm animating (numbers, equations)
>> and the way they move and interact with each other is a research project,
>> and I'm constantly ripping out parts of my application and scavenging them
>> for variations on a theme.
>>
>> My objects need state. At this point I'm thinking of just putting the
>> state into a map with strings as keys and some kind of sum type to
>> represent each data item I might need.
>>
>> So if I want to represent that an object has a particular color and
>> position and velocity,
>>
>> itemState = M.fromList
>>   [("color"   , DataColor  blue       )
>>   ,("position", DataPoint  500.0 100.0)
>>   ,("velocity", DataVector 50.0 45.0  ) ]
>>
>> Which starts to look more like a dynamically-typed scripting language.
>> But it's not hard to work with. I can uses lenses/prisms to inspect and
>> update state, and it's okay if my program crashes on encountering malformed
>> state.
>>
>> What this lets me do is create new objects that mix and match parts of
>> old objects, and copy and paste a lot of the code.
>>
>> Is there a better way to do this? Is there a compromise I can make that
>> will allow the compiler to help me out more with finding errors at compile
>> time?
>>
>> D
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180729/f5525b59/attachment.html>

From fa-ml at ariis.it  Sun Jul 29 08:24:56 2018
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 29 Jul 2018 10:24:56 +0200
Subject: [Haskell-cafe] using Haskell more like scripting language
In-Reply-To: <CAH2TZMhCWYK4QYeH+RhL-jcy5Ks9yTQAnjqSCpRvVqxv0apU0g@mail.gmail.com>
References: <CAKxLvoorcw8WQZ87JxN6kNijqNaHZJbvvE=J7fpKMttP7OFq5A@mail.gmail.com>
 <3d4fad07-34e2-6c7f-79dd-2811599277a7@iohk.io>
 <CAKxLvopkOu2WKw4wS_AXjqdpL0ChvDTghEJM=Ve25cQXT2DNvA@mail.gmail.com>
 <CAH2TZMhCWYK4QYeH+RhL-jcy5Ks9yTQAnjqSCpRvVqxv0apU0g@mail.gmail.com>
Message-ID: <20180729082456.hjk5eydo2ay25xoh@x60s.casa>

On Sun, Jul 29, 2018 at 10:08:22AM +0200, Leandro Ostera wrote:
> Correct me if I’m wrong but isn’t this precisely where GADTs would excel?

I was thinking of HasSomething t => ... but you would have to enable
Template Haskell (blergh).

From mpevnev at gmail.com  Sun Jul 29 09:08:56 2018
From: mpevnev at gmail.com (mpevnev at gmail.com)
Date: Sun, 29 Jul 2018 12:08:56 +0300
Subject: [Haskell-cafe] Testing a collision detection system
Message-ID: <20180729090856.mve2lnfwqxz6zdjc@MishkaPC>

As a part of a project, I write a collision detection system. It is in
dire need of testing, but designing and writing tests for all possible
pairs of types of colliding geometry would be a pretty big effort - not
only I would have to calculate the fact of collision manually for
20-something pairs of types of colliding geometry, I would also have to
do so multiple times for each pair, since each pair requires several
test cases.

So the idea is to use an existing collision detection library to
generate (a lot of) test cases from random data. I've found two such
libraries for Haskell - HODE and Bullet. The problem is, Bullet bindings
aren't documented at all, and HODE (which isn't really documented
either, but at least lists available functions) is extremely ugly with
IO all over the place, and manual tracking of objects' lifetimes (at
least that's what I infer from `create :: World -> IO Body` and 
`destroyBody :: Body -> IO ()`, because again - no documentation).

So my question is: does anyone know a library I could use? I'll pretty
much settle for whatever.

-- 
Michail.

From brodyberg at gmail.com  Sun Jul 29 21:44:16 2018
From: brodyberg at gmail.com (Brody Berg)
Date: Sun, 29 Jul 2018 14:44:16 -0700
Subject: [Haskell-cafe] Testing a collision detection system
In-Reply-To: <20180729090856.mve2lnfwqxz6zdjc@MishkaPC>
References: <20180729090856.mve2lnfwqxz6zdjc@MishkaPC>
Message-ID: <CAGAyAWPGv8-hT-w+dbjNDTJPbTQd0ivUR5qOg=3azA1_K7r0xg@mail.gmail.com>

And you've already ruled out QuickCheck and friends?

On Sun, Jul 29, 2018 at 2:08 AM, <mpevnev at gmail.com> wrote:

> As a part of a project, I write a collision detection system. It is in
> dire need of testing, but designing and writing tests for all possible
> pairs of types of colliding geometry would be a pretty big effort - not
> only I would have to calculate the fact of collision manually for
> 20-something pairs of types of colliding geometry, I would also have to
> do so multiple times for each pair, since each pair requires several
> test cases.
>
> So the idea is to use an existing collision detection library to
> generate (a lot of) test cases from random data. I've found two such
> libraries for Haskell - HODE and Bullet. The problem is, Bullet bindings
> aren't documented at all, and HODE (which isn't really documented
> either, but at least lists available functions) is extremely ugly with
> IO all over the place, and manual tracking of objects' lifetimes (at
> least that's what I infer from `create :: World -> IO Body` and
> `destroyBody :: Body -> IO ()`, because again - no documentation).
>
> So my question is: does anyone know a library I could use? I'll pretty
> much settle for whatever.
>
> --
> Michail.
> _______________________________________________
> 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/20180729/6a5649be/attachment.html>

From ivanperezdominguez at gmail.com  Mon Jul 30 00:02:39 2018
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Sun, 29 Jul 2018 20:02:39 -0400
Subject: [Haskell-cafe] Testing a collision detection system
In-Reply-To: <CAGAyAWPGv8-hT-w+dbjNDTJPbTQd0ivUR5qOg=3azA1_K7r0xg@mail.gmail.com>
References: <20180729090856.mve2lnfwqxz6zdjc@MishkaPC>
 <CAGAyAWPGv8-hT-w+dbjNDTJPbTQd0ivUR5qOg=3azA1_K7r0xg@mail.gmail.com>
Message-ID: <CACZKWE+6KQia805J=5JqA4QeZghR-rQ0PBzNek6J6ojPj_xrFw@mail.gmail.com>

Definitely worth a try.

It seems like a large test space.

My expectation, based on what I've seen when we applied QuickCheck to
haskanoid, would be that, with the standard generators, QuickCheck may be
good at detecting things that will not normally happen in realistic
simulations, but you may have to tune the generators to look for the more
interesting cases you want to test, and that'll be similar-ish to writing
your own test cases.

But I'd love to be proven wrong! :)

Ivan

On 29 July 2018 at 17:44, Brody Berg <brodyberg at gmail.com> wrote:

> And you've already ruled out QuickCheck and friends?
>
> On Sun, Jul 29, 2018 at 2:08 AM, <mpevnev at gmail.com> wrote:
>
>> As a part of a project, I write a collision detection system. It is in
>> dire need of testing, but designing and writing tests for all possible
>> pairs of types of colliding geometry would be a pretty big effort - not
>> only I would have to calculate the fact of collision manually for
>> 20-something pairs of types of colliding geometry, I would also have to
>> do so multiple times for each pair, since each pair requires several
>> test cases.
>>
>> So the idea is to use an existing collision detection library to
>> generate (a lot of) test cases from random data. I've found two such
>> libraries for Haskell - HODE and Bullet. The problem is, Bullet bindings
>> aren't documented at all, and HODE (which isn't really documented
>> either, but at least lists available functions) is extremely ugly with
>> IO all over the place, and manual tracking of objects' lifetimes (at
>> least that's what I infer from `create :: World -> IO Body` and
>> `destroyBody :: Body -> IO ()`, because again - no documentation).
>>
>> So my question is: does anyone know a library I could use? I'll pretty
>> much settle for whatever.
>>
>> --
>> Michail.
>> _______________________________________________
>> 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/20180729/14a44fe6/attachment.html>

From jo at durchholz.org  Mon Jul 30 06:19:04 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 30 Jul 2018 08:19:04 +0200
Subject: [Haskell-cafe] Testing a collision detection system
In-Reply-To: <20180729090856.mve2lnfwqxz6zdjc@MishkaPC>
References: <20180729090856.mve2lnfwqxz6zdjc@MishkaPC>
Message-ID: <ab87a414-c18f-e2cd-e0b3-18a2b1448376@durchholz.org>

> So the idea is to use an existing collision detection library to
> generate (a lot of) test cases from random data.

I think that won't solve your problem. You wouldn't test that your 
collision library works, you'd test that your collision library is 
bug-for-bug-compatible with whatever other collision library you're 
using as your gold standard.

You'd probably be better off by writing a small collision detector that 
uses just the raw data. Optimized not for speed but for easy inspectability.

Then apply that algorithm to the test cases.
If the objects are pixels, AND the bitmaps and check whether the result 
has 1 bits or not.
If the objects are vector art, apply a collision algorithm; I dimly 
recall there was a really simple and easy-to-validate one in one of 
Robert Sedgewick's "Algorithms" books.


To generate the test cases, that's easier for vector than for bitmap - 
you have sets of points and can move/rotate the two shapes so that you 
get each permutation of line endpoints.
Depending on the complexity of your shapes, this may or may not be feasible.

You can compute the convex hull (again, pretty easy if you go by 
Sedgewick) and check that if convex hulls don't intersect, your 
algorithm does not intersect; that's going to cut down on test cases 
that you don't need to check.


Yet another approach to test case writing: Look at each decision point 
in the intersection algorithm, then take a step back and find out what 
that means, geometrically, and write (or generate) test cases for both 
branches. IOW generate your test cases towards 100% coverage.

QuickCheck may help, too.
If you find it does not detect relevant test cases, consider 
restructuring your code so that the decisionmaking is simplified, and/or 
separated out from the nitty-gritty details of actual checking. Maybe 
separate it out into a "strategy layer" and an "execution layer", where 
strategy decides how to test and execution does the actual test (I can't 
be clearer because I don't know the kind of shapes you are testing).
The goal would be to separate the logic, because that's going to 
simplify testing tremendously. It may even make the code so 
understandable that you don't even need to write tests, because the code 
is self-evident - well, that's probably just an ideal that you can come 
nearer but never fully achieve, but it's a guideline to consider 
whenever you make decisions about how you structure your code.
Refactoring in this way may amount to a full rewrite. If may also reduce 
your testing effort; it's difficult to assess whether it's going to be a 
net win.

Regards,
Jo

From mpevnev at gmail.com  Mon Jul 30 17:51:18 2018
From: mpevnev at gmail.com (Michail Pevnev)
Date: Mon, 30 Jul 2018 20:51:18 +0300
Subject: [Haskell-cafe] Testing a collision detection system
In-Reply-To: <CAGAyAWPGv8-hT-w+dbjNDTJPbTQd0ivUR5qOg=3azA1_K7r0xg@mail.gmail.com>
References: <20180729090856.mve2lnfwqxz6zdjc@MishkaPC>
 <CAGAyAWPGv8-hT-w+dbjNDTJPbTQd0ivUR5qOg=3azA1_K7r0xg@mail.gmail.com>
Message-ID: <20180730175118.biwvadxwrnbpil7k@MishkaPC>

I've just looked up a QuickCheck tutorial, and it looks positively
amazing. Thank you for showing me a beautiful piece of Haskell.

On Sun, Jul 29, 2018 at 02:44:16PM -0700, Brody Berg wrote:
> And you've already ruled out QuickCheck and friends?
> 
> On Sun, Jul 29, 2018 at 2:08 AM, <mpevnev at gmail.com> wrote:
> 
> > As a part of a project, I write a collision detection system. It is in
> > dire need of testing, but designing and writing tests for all possible
> > pairs of types of colliding geometry would be a pretty big effort - not
> > only I would have to calculate the fact of collision manually for
> > 20-something pairs of types of colliding geometry, I would also have to
> > do so multiple times for each pair, since each pair requires several
> > test cases.
> >
> > So the idea is to use an existing collision detection library to
> > generate (a lot of) test cases from random data. I've found two such
> > libraries for Haskell - HODE and Bullet. The problem is, Bullet bindings
> > aren't documented at all, and HODE (which isn't really documented
> > either, but at least lists available functions) is extremely ugly with
> > IO all over the place, and manual tracking of objects' lifetimes (at
> > least that's what I infer from `create :: World -> IO Body` and
> > `destroyBody :: Body -> IO ()`, because again - no documentation).
> >
> > So my question is: does anyone know a library I could use? I'll pretty
> > much settle for whatever.
> >
> > --
> > Michail.
> > _______________________________________________
> > 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.


-- 
Michail.

From marc at lamarciana.com  Tue Jul 31 07:07:12 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 31 Jul 2018 09:07:12 +0200 (CEST)
Subject: [Haskell-cafe] Missing common function for Maybe types
Message-ID: <alpine.LNX.2.21.1807310857500.2536@localhost>

Hi!

I have two functions:

```
foo :: a -> Maybe b
bar :: a -> Maybe c
```

>From which I want to build a higher order function:

```
foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
```

The implementation I need is:

```
foobar x f g =
   case (f x) of
     Nothing -> g x
     Just y  -> Just y
```

I'm a bit surprised that looking at hoogle I don't find a built-in
solution for this quite common need for `Maybe` types (or perhaps for
any monad).

Am I looking in the wrong way? Does it exist a similar abstraction but
with a different shape?

Thanks in advance,

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

From david.feuer at gmail.com  Tue Jul 31 07:11:36 2018
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 31 Jul 2018 03:11:36 -0400
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <alpine.LNX.2.21.1807310857500.2536@localhost>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
Message-ID: <CAMgWh9uPdJ0eEbUoeuBjhwJq9GNo-t3rNWeDocck-NzKD3tsjA@mail.gmail.com>

Your code doesn't type check and there is no way to write a total function
with the type of foobar. What are you actually trying to do? Why do you say
this is "common"?

On Tue, Jul 31, 2018, 3:07 AM Marc Busqué <marc at lamarciana.com> wrote:

> Hi!
>
> I have two functions:
>
> ```
> foo :: a -> Maybe b
> bar :: a -> Maybe c
> ```
>
> From which I want to build a higher order function:
>
> ```
> foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
> ```
>
> The implementation I need is:
>
> ```
> foobar x f g =
>    case (f x) of
>      Nothing -> g x
>      Just y  -> Just y
> ```
>
> I'm a bit surprised that looking at hoogle I don't find a built-in
> solution for this quite common need for `Maybe` types (or perhaps for
> any monad).
>
> Am I looking in the wrong way? Does it exist a similar abstraction but
> with a different shape?
>
> Thanks in advance,
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
> _______________________________________________
> 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/20180731/2bd1c514/attachment.html>

From aquagnu at gmail.com  Tue Jul 31 07:13:12 2018
From: aquagnu at gmail.com (Paul)
Date: Tue, 31 Jul 2018 10:13:12 +0300
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <alpine.LNX.2.21.1807310857500.2536@localhost>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
Message-ID: <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>

Something like "maybe" function?


31.07.2018 10:07, Marc Busqué wrotes:
> Hi!
>
> I have two functions:
>
> ```
> foo :: a -> Maybe b
> bar :: a -> Maybe c
> ```
>
> From which I want to build a higher order function:
>
> ```
> foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
> ```
>
> The implementation I need is:
>
> ```
> foobar x f g =
>   case (f x) of
>     Nothing -> g x
>     Just y  -> Just y
> ```
>
> I'm a bit surprised that looking at hoogle I don't find a built-in
> solution for this quite common need for `Maybe` types (or perhaps for
> any monad).
>
> Am I looking in the wrong way? Does it exist a similar abstraction but
> with a different shape?
>
> Thanks in advance,
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
>
>
> _______________________________________________
> 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/20180731/c086819f/attachment.html>

From marc at lamarciana.com  Tue Jul 31 07:47:07 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 31 Jul 2018 09:47:07 +0200 (CEST)
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
Message-ID: <alpine.LNX.2.21.1807310926130.2536@localhost>

Apologies, I clearly asked the question in a rushed way...

I'm working with [req](http://hackage.haskell.org/package/req) package.
I need to parse a url from a string, but I don't know whether its schema
will be `http` or `https`. However, `req` just provides me with two
functions:

```
parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
```

As I don't know the schema beforehand, I have to apply one of the two
functions, do a case analysis on its result and, depending on the
result, call the second one or return the first result.

What I think is a common case here (perhaps I'm wrong) is the need to
choose between two or more `Maybe` values where at most one of them will
be a `Just`. `maybe` does not do that. `catMaybes` could be used for
that when all the `Maybe` have the same inner type, but it is not the
exact abstraction and it would need more code (just like simply doing a
case analysis).

Thanks and, again, sorry for the hurried question before (I don't like
when I see it from others :()

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

On Tue, 31 Jul 2018, Paul wrote:

> 
> Something like "maybe" function?
> 
> 
> 31.07.2018 10:07, Marc Busqué wrotes:
>       Hi!
>
>       I have two functions:
>
>       ```
>       foo :: a -> Maybe b
>       bar :: a -> Maybe c
>       ```
>
>       From which I want to build a higher order function:
>
>       ```
>       foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
>       ```
>
>       The implementation I need is:
>
>       ```
>       foobar x f g =
>         case (f x) of
>           Nothing -> g x
>           Just y  -> Just y
>       ```
>
>       I'm a bit surprised that looking at hoogle I don't find a built-in
>       solution for this quite common need for `Maybe` types (or perhaps for
>       any monad).
>
>       Am I looking in the wrong way? Does it exist a similar abstraction but
>       with a different shape?
>
>       Thanks in advance,
>
>       Marc Busqué
>       http://waiting-for-dev.github.io/about/
> 
> 
> _______________________________________________
> 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  Tue Jul 31 08:10:02 2018
From: imantc at gmail.com (Imants Cekusins)
Date: Tue, 31 Jul 2018 11:10:02 +0300
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <alpine.LNX.2.21.1807310926130.2536@localhost>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
Message-ID: <CAP1qinZTzSB8R6Zbc+HqbVCXDM6qaYKHUd8uuePR8rNpNBg0aA@mail.gmail.com>

Salut Marc,

Are you looking for Alternative by any chance:
http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Applicative.html#t:Alternative


Prelude> :m Control.Applicative
Prelude Control.Applicative> Just 1 <|> Just 2::Maybe Int
Just 1
Prelude Control.Applicative> Nothing <|> Just 2::Maybe Int
Just 2




On 31 July 2018 at 10:47, Marc Busqué <marc at lamarciana.com> wrote:

> Apologies, I clearly asked the question in a rushed way...
>
> I'm working with [req](http://hackage.haskell.org/package/req) package.
> I need to parse a url from a string, but I don't know whether its schema
> will be `http` or `https`. However, `req` just provides me with two
> functions:
>
> ```
> parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
> parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
> ```
>
> As I don't know the schema beforehand, I have to apply one of the two
> functions, do a case analysis on its result and, depending on the
> result, call the second one or return the first result.
>
> What I think is a common case here (perhaps I'm wrong) is the need to
> choose between two or more `Maybe` values where at most one of them will
> be a `Just`. `maybe` does not do that. `catMaybes` could be used for
> that when all the `Maybe` have the same inner type, but it is not the
> exact abstraction and it would need more code (just like simply doing a
> case analysis).
>
> Thanks and, again, sorry for the hurried question before (I don't like
> when I see it from others :()
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
>
> On Tue, 31 Jul 2018, Paul wrote:
>
>
>> Something like "maybe" function?
>>
>>
>> 31.07.2018 10:07, Marc Busqué wrotes:
>>       Hi!
>>
>>       I have two functions:
>>
>>       ```
>>       foo :: a -> Maybe b
>>       bar :: a -> Maybe c
>>       ```
>>
>>       From which I want to build a higher order function:
>>
>>       ```
>>       foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
>>       ```
>>
>>       The implementation I need is:
>>
>>       ```
>>       foobar x f g =
>>         case (f x) of
>>           Nothing -> g x
>>           Just y  -> Just y
>>       ```
>>
>>       I'm a bit surprised that looking at hoogle I don't find a built-in
>>       solution for this quite common need for `Maybe` types (or perhaps
>> for
>>       any monad).
>>
>>       Am I looking in the wrong way? Does it exist a similar abstraction
>> but
>>       with a different shape?
>>
>>       Thanks in advance,
>>
>>       Marc Busqué
>>       http://waiting-for-dev.github.io/about/
>>
>>
>> _______________________________________________
>> 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/20180731/c2601117/attachment.html>

From aquagnu at gmail.com  Tue Jul 31 08:26:21 2018
From: aquagnu at gmail.com (Paul)
Date: Tue, 31 Jul 2018 11:26:21 +0300
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <CAP1qinZTzSB8R6Zbc+HqbVCXDM6qaYKHUd8uuePR8rNpNBg0aA@mail.gmail.com>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
 <CAP1qinZTzSB8R6Zbc+HqbVCXDM6qaYKHUd8uuePR8rNpNBg0aA@mail.gmail.com>
Message-ID: <95682e1b-5fd3-8f5b-5fd6-b5dcc227d44e@gmail.com>

But alternative does not apply function to first Nothing. `maybe` can 
exec function on Nothing or apply another one on Just.

maybe (g x) id (f x) ?


31.07.2018 11:10, Imants Cekusins wrotes:
> Salut Marc,
>
> Are you looking for Alternative by any chance:
> http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Applicative.html#t:Alternative
>
>
> Prelude> :m Control.Applicative
> Prelude Control.Applicative> Just 1 <|> Just 2::Maybe Int
> Just 1
> Prelude Control.Applicative> Nothing <|> Just 2::Maybe Int
> Just 2
>
>
>
>
> On 31 July 2018 at 10:47, Marc Busqué <marc at lamarciana.com 
> <mailto:marc at lamarciana.com>> wrote:
>
>     Apologies, I clearly asked the question in a rushed way...
>
>     I'm working with [req](http://hackage.haskell.org/package/req
>     <http://hackage.haskell.org/package/req>) package.
>     I need to parse a url from a string, but I don't know whether its
>     schema
>     will be `http` or `https`. However, `req` just provides me with two
>     functions:
>
>     ```
>     parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
>     parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
>     ```
>
>     As I don't know the schema beforehand, I have to apply one of the two
>     functions, do a case analysis on its result and, depending on the
>     result, call the second one or return the first result.
>
>     What I think is a common case here (perhaps I'm wrong) is the need to
>     choose between two or more `Maybe` values where at most one of
>     them will
>     be a `Just`. `maybe` does not do that. `catMaybes` could be used for
>     that when all the `Maybe` have the same inner type, but it is not the
>     exact abstraction and it would need more code (just like simply
>     doing a
>     case analysis).
>
>     Thanks and, again, sorry for the hurried question before (I don't like
>     when I see it from others :()
>
>     Marc Busqué
>     http://waiting-for-dev.github.io/about/
>     <http://waiting-for-dev.github.io/about/>
>
>     On Tue, 31 Jul 2018, Paul wrote:
>
>
>         Something like "maybe" function?
>
>
>         31.07.2018 10:07, Marc Busqué wrotes:
>               Hi!
>
>               I have two functions:
>
>               ```
>               foo :: a -> Maybe b
>               bar :: a -> Maybe c
>               ```
>
>               From which I want to build a higher order function:
>
>               ```
>               foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) ->
>         Either b c
>               ```
>
>               The implementation I need is:
>
>               ```
>               foobar x f g =
>                 case (f x) of
>                   Nothing -> g x
>                   Just y  -> Just y
>               ```
>
>               I'm a bit surprised that looking at hoogle I don't find
>         a built-in
>               solution for this quite common need for `Maybe` types
>         (or perhaps for
>               any monad).
>
>               Am I looking in the wrong way? Does it exist a similar
>         abstraction but
>               with a different shape?
>
>               Thanks in advance,
>
>               Marc Busqué
>         http://waiting-for-dev.github.io/about/
>         <http://waiting-for-dev.github.io/about/>
>
>
>         _______________________________________________
>         Haskell-Cafe mailing list
>         To (un)subscribe, modify options or view archives go to:
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>         Only members subscribed via the mailman list are allowed to post.
>
>
>
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>     Only members subscribed via the mailman list are allowed to post.
>
>

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

From imantc at gmail.com  Tue Jul 31 08:36:50 2018
From: imantc at gmail.com (Imants Cekusins)
Date: Tue, 31 Jul 2018 11:36:50 +0300
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <95682e1b-5fd3-8f5b-5fd6-b5dcc227d44e@gmail.com>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
 <CAP1qinZTzSB8R6Zbc+HqbVCXDM6qaYKHUd8uuePR8rNpNBg0aA@mail.gmail.com>
 <95682e1b-5fd3-8f5b-5fd6-b5dcc227d44e@gmail.com>
Message-ID: <CAP1qinYEYL4+2QEpe6k-7GTRLmBSEwjXjrVTngqz=yKbC2ReFQ@mail.gmail.com>

> alternative does not apply function to first Nothing

<|> or other functions from Alternative may not be the entire function to
solve Marc's problem.

It is a possibly useful function that is a bit tricky to find. ;)


On 31 July 2018 at 11:26, Paul <aquagnu at gmail.com> wrote:

> But alternative does not apply function to first Nothing. `maybe` can exec
> function on Nothing or apply another one on Just.
>
> maybe (g x) id (f x) ?
>
> 31.07.2018 11:10, Imants Cekusins wrotes:
>
> Salut Marc,
>
> Are you looking for Alternative by any chance:
> http://hackage.haskell.org/package/base-4.11.1.0/docs/
> Control-Applicative.html#t:Alternative
>
>
> Prelude> :m Control.Applicative
> Prelude Control.Applicative> Just 1 <|> Just 2::Maybe Int
> Just 1
> Prelude Control.Applicative> Nothing <|> Just 2::Maybe Int
> Just 2
>
>
>
>
> On 31 July 2018 at 10:47, Marc Busqué <marc at lamarciana.com> wrote:
>
>> Apologies, I clearly asked the question in a rushed way...
>>
>> I'm working with [req](http://hackage.haskell.org/package/req) package.
>> I need to parse a url from a string, but I don't know whether its schema
>> will be `http` or `https`. However, `req` just provides me with two
>> functions:
>>
>> ```
>> parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
>> parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
>> ```
>>
>> As I don't know the schema beforehand, I have to apply one of the two
>> functions, do a case analysis on its result and, depending on the
>> result, call the second one or return the first result.
>>
>> What I think is a common case here (perhaps I'm wrong) is the need to
>> choose between two or more `Maybe` values where at most one of them will
>> be a `Just`. `maybe` does not do that. `catMaybes` could be used for
>> that when all the `Maybe` have the same inner type, but it is not the
>> exact abstraction and it would need more code (just like simply doing a
>> case analysis).
>>
>> Thanks and, again, sorry for the hurried question before (I don't like
>> when I see it from others :()
>>
>> Marc Busqué
>> http://waiting-for-dev.github.io/about/
>>
>> On Tue, 31 Jul 2018, Paul wrote:
>>
>>
>>> Something like "maybe" function?
>>>
>>>
>>> 31.07.2018 10:07, Marc Busqué wrotes:
>>>       Hi!
>>>
>>>       I have two functions:
>>>
>>>       ```
>>>       foo :: a -> Maybe b
>>>       bar :: a -> Maybe c
>>>       ```
>>>
>>>       From which I want to build a higher order function:
>>>
>>>       ```
>>>       foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
>>>       ```
>>>
>>>       The implementation I need is:
>>>
>>>       ```
>>>       foobar x f g =
>>>         case (f x) of
>>>           Nothing -> g x
>>>           Just y  -> Just y
>>>       ```
>>>
>>>       I'm a bit surprised that looking at hoogle I don't find a built-in
>>>       solution for this quite common need for `Maybe` types (or perhaps
>>> for
>>>       any monad).
>>>
>>>       Am I looking in the wrong way? Does it exist a similar abstraction
>>> but
>>>       with a different shape?
>>>
>>>       Thanks in advance,
>>>
>>>       Marc Busqué
>>>       http://waiting-for-dev.github.io/about/
>>>
>>>
>>> _______________________________________________
>>> 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/20180731/972d8e06/attachment.html>

From david.feuer at gmail.com  Tue Jul 31 08:59:03 2018
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 31 Jul 2018 04:59:03 -0400
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <alpine.LNX.2.21.1807310926130.2536@localhost>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
Message-ID: <CAMgWh9vV=_i5b8vEHrO4mbhGs3Xfkny0rGyvN8Z0Pxv=pLKE8g@mail.gmail.com>

I think you're probably after something like

boo :: Maybe a -> Maybe b -> Maybe (Either a b)
boo ma mb = (Left <$> ma) <|> (Right <$> mb)

On Tue, Jul 31, 2018, 3:47 AM Marc Busqué <marc at lamarciana.com> wrote:

> Apologies, I clearly asked the question in a rushed way...
>
> I'm working with [req](http://hackage.haskell.org/package/req) package.
> I need to parse a url from a string, but I don't know whether its schema
> will be `http` or `https`. However, `req` just provides me with two
> functions:
>
> ```
> parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
> parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
> ```
>
> As I don't know the schema beforehand, I have to apply one of the two
> functions, do a case analysis on its result and, depending on the
> result, call the second one or return the first result.
>
> What I think is a common case here (perhaps I'm wrong) is the need to
> choose between two or more `Maybe` values where at most one of them will
> be a `Just`. `maybe` does not do that. `catMaybes` could be used for
> that when all the `Maybe` have the same inner type, but it is not the
> exact abstraction and it would need more code (just like simply doing a
> case analysis).
>
> Thanks and, again, sorry for the hurried question before (I don't like
> when I see it from others :()
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
>
> On Tue, 31 Jul 2018, Paul wrote:
>
> >
> > Something like "maybe" function?
> >
> >
> > 31.07.2018 10:07, Marc Busqué wrotes:
> >       Hi!
> >
> >       I have two functions:
> >
> >       ```
> >       foo :: a -> Maybe b
> >       bar :: a -> Maybe c
> >       ```
> >
> >       From which I want to build a higher order function:
> >
> >       ```
> >       foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
> >       ```
> >
> >       The implementation I need is:
> >
> >       ```
> >       foobar x f g =
> >         case (f x) of
> >           Nothing -> g x
> >           Just y  -> Just y
> >       ```
> >
> >       I'm a bit surprised that looking at hoogle I don't find a built-in
> >       solution for this quite common need for `Maybe` types (or perhaps
> for
> >       any monad).
> >
> >       Am I looking in the wrong way? Does it exist a similar abstraction
> but
> >       with a different shape?
> >
> >       Thanks in advance,
> >
> >       Marc Busqué
> >       http://waiting-for-dev.github.io/about/
> >
> >
> > _______________________________________________
> > 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/20180731/542aa502/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Tue Jul 31 10:24:18 2018
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 31 Jul 2018 11:24:18 +0100
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <alpine.LNX.2.21.1807310926130.2536@localhost>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
Message-ID: <20180731102418.qt7g7h2vfceo7clc@weber>

On Tue, Jul 31, 2018 at 09:47:07AM +0200, Marc Busqué wrote:
> Apologies, I clearly asked the question in a rushed way...
> 
> I'm working with [req](http://hackage.haskell.org/package/req) package.
> I need to parse a url from a string, but I don't know whether its schema
> will be `http` or `https`. However, `req` just provides me with two
> functions:
> 
> ```
> parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
> parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
> ```

This just sounds like bad API design from req.  Why is the API not

    parseUrl :: ByteString -> Maybe (Either (Url Http) (Url Https), Option scheme)

> What I think is a common case here (perhaps I'm wrong) is the need to
> choose between two or more `Maybe` values where at most one of them will
> be a `Just`.

If that invariant really does hold then the authors of those functions
should encode the invariant in the type. Requiring clients to observe the
invariant for themselves sounds like a bad idea.

Tom

From vanessa.mchale at iohk.io  Tue Jul 31 11:39:16 2018
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Tue, 31 Jul 2018 06:39:16 -0500
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <alpine.LNX.2.21.1807310857500.2536@localhost>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
Message-ID: <ab13708a-4d4e-adc3-78f5-4e9f86e24765@iohk.io>

That doesn't exactly make sense. You'd need two versions of that
function in all likelihood - one left-biased and another right-biased.


On 07/31/2018 02:07 AM, Marc Busqué wrote:
> Hi!
>
> I have two functions:
>
> ```
> foo :: a -> Maybe b
> bar :: a -> Maybe c
> ```
>
> From which I want to build a higher order function:
>
> ```
> foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
> ```
>
> The implementation I need is:
>
> ```
> foobar x f g =
>   case (f x) of
>     Nothing -> g x
>     Just y  -> Just y
> ```
>
> I'm a bit surprised that looking at hoogle I don't find a built-in
> solution for this quite common need for `Maybe` types (or perhaps for
> any monad).
>
> Am I looking in the wrong way? Does it exist a similar abstraction but
> with a different shape?
>
> Thanks in advance,
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
>
>
> _______________________________________________
> 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.

-- 



*Vanessa McHale*
Functional Compiler Engineer | Chicago, IL

Website: www.iohk.io <http://iohk.io>
Twitter: @vamchale
PGP Key ID: 4209B7B5

Input Output <http://iohk.io>

Twitter <https://twitter.com/InputOutputHK> Github
<https://github.com/input-output-hk> LinkedIn
<https://www.linkedin.com/company/input-output-global>


This e-mail and any file transmitted with it are confidential and
intended solely for the use of the recipient(s) to whom it is addressed.
Dissemination, distribution, and/or copying of the transmission by
anyone other than the intended recipient(s) is prohibited. If you have
received this transmission in error please notify IOHK immediately and
delete it from your system. E-mail transmissions cannot be guaranteed to
be secure or error free. We do not accept liability for any loss,
damage, or error arising from this transmission
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180731/b298afda/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180731/b298afda/attachment-0001.sig>

From marc at lamarciana.com  Tue Jul 31 11:52:34 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 31 Jul 2018 13:52:34 +0200 (CEST)
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <CAP1qinZTzSB8R6Zbc+HqbVCXDM6qaYKHUd8uuePR8rNpNBg0aA@mail.gmail.com>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
 <CAP1qinZTzSB8R6Zbc+HqbVCXDM6qaYKHUd8uuePR8rNpNBg0aA@mail.gmail.com>
Message-ID: <alpine.LNX.2.21.1807311351030.2536@localhost>

On Tue, 31 Jul 2018, Imants Cekusins wrote:

> Salut Marc,
> Are you looking for Alternative by any chance:
> http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Applicative.html#t:Alternative
> 
> 
> Prelude> :m Control.Applicative
> Prelude Control.Applicative> Just 1 <|> Just 2::Maybe Int
> Just 1
> Prelude Control.Applicative> Nothing <|> Just 2::Maybe Int
> Just 2

Thanks for your answer Imants. That seems would be the perfect fit in
the case that both Maybe were parametrized by the same type, but it is
not the case. For that reason I thought I needed an `Either` in the
result.

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

From marc at lamarciana.com  Tue Jul 31 11:55:48 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 31 Jul 2018 13:55:48 +0200 (CEST)
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <95682e1b-5fd3-8f5b-5fd6-b5dcc227d44e@gmail.com>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
 <CAP1qinZTzSB8R6Zbc+HqbVCXDM6qaYKHUd8uuePR8rNpNBg0aA@mail.gmail.com>
 <95682e1b-5fd3-8f5b-5fd6-b5dcc227d44e@gmail.com>
Message-ID: <alpine.LNX.2.21.1807311354510.2536@localhost>

On Tue, 31 Jul 2018, Paul wrote:

> But alternative does not apply function to first Nothing. `maybe` can exec function on Nothing or apply another one on Just.
> 
> maybe (g x) id (f x) ?

As in the alternative case, it seems to be a good fit when there is only
one type involved, but it is two in this case.

Marc Busqué
http://waiting-for-dev.github.io/about/
> 
> 
> 31.07.2018 11:10, Imants Cekusins wrotes:
>       Salut Marc,
> Are you looking for Alternative by any chance:
> http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Applicative.html#t:Alternative
> 
> 
> Prelude> :m Control.Applicative
> Prelude Control.Applicative> Just 1 <|> Just 2::Maybe Int
> Just 1
> Prelude Control.Applicative> Nothing <|> Just 2::Maybe Int
> Just 2
> 
> 
> 
> 
> On 31 July 2018 at 10:47, Marc Busqué <marc at lamarciana.com> wrote:
>       Apologies, I clearly asked the question in a rushed way...
>
>       I'm working with [req](http://hackage.haskell.org/package/req) package.
>       I need to parse a url from a string, but I don't know whether its schema
>       will be `http` or `https`. However, `req` just provides me with two
>       functions:
>
>       ```
>       parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
>       parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
>       ```
>
>       As I don't know the schema beforehand, I have to apply one of the two
>       functions, do a case analysis on its result and, depending on the
>       result, call the second one or return the first result.
>
>       What I think is a common case here (perhaps I'm wrong) is the need to
>       choose between two or more `Maybe` values where at most one of them will
>       be a `Just`. `maybe` does not do that. `catMaybes` could be used for
>       that when all the `Maybe` have the same inner type, but it is not the
>       exact abstraction and it would need more code (just like simply doing a
>       case analysis).
>
>       Thanks and, again, sorry for the hurried question before (I don't like
>       when I see it from others :()
>
>       Marc Busqué
>       http://waiting-for-dev.github.io/about/
>
>       On Tue, 31 Jul 2018, Paul wrote:
> 
>
>             Something like "maybe" function?
> 
>
>             31.07.2018 10:07, Marc Busqué wrotes:
>                   Hi!
>
>                   I have two functions:
>
>                   ```
>                   foo :: a -> Maybe b
>                   bar :: a -> Maybe c
>                   ```
>
>                   From which I want to build a higher order function:
>
>                   ```
>                   foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
>                   ```
>
>                   The implementation I need is:
>
>                   ```
>                   foobar x f g =
>                     case (f x) of
>                       Nothing -> g x
>                       Just y  -> Just y
>                   ```
>
>                   I'm a bit surprised that looking at hoogle I don't find a built-in
>                   solution for this quite common need for `Maybe` types (or perhaps for
>                   any monad).
>
>                   Am I looking in the wrong way? Does it exist a similar abstraction but
>                   with a different shape?
>
>                   Thanks in advance,
>
>                   Marc Busqué
>                   http://waiting-for-dev.github.io/about/
> 
>
>             _______________________________________________
>             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 marc at lamarciana.com  Tue Jul 31 11:58:35 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 31 Jul 2018 13:58:35 +0200 (CEST)
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <CAMgWh9vV=_i5b8vEHrO4mbhGs3Xfkny0rGyvN8Z0Pxv=pLKE8g@mail.gmail.com>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
 <CAMgWh9vV=_i5b8vEHrO4mbhGs3Xfkny0rGyvN8Z0Pxv=pLKE8g@mail.gmail.com>
Message-ID: <alpine.LNX.2.21.1807311356530.2536@localhost>

On Tue, 31 Jul 2018, David Feuer wrote:

> I think you're probably after something like
> 
> boo :: Maybe a -> Maybe b -> Maybe (Either a b)
> boo ma mb = (Left <$> ma) <|> (Right <$> mb)

Thanks! That seems the right function for my case :) I see we need a
little bit of handcrafting and nothing exists out of the box in base
Haskell.

Marc Busqué
http://waiting-for-dev.github.io/about/
> 
> On Tue, Jul 31, 2018, 3:47 AM Marc Busqué <marc at lamarciana.com> wrote:
>       Apologies, I clearly asked the question in a rushed way...
>
>       I'm working with [req](http://hackage.haskell.org/package/req) package.
>       I need to parse a url from a string, but I don't know whether its schema
>       will be `http` or `https`. However, `req` just provides me with two
>       functions:
>
>       ```
>       parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
>       parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
>       ```
>
>       As I don't know the schema beforehand, I have to apply one of the two
>       functions, do a case analysis on its result and, depending on the
>       result, call the second one or return the first result.
>
>       What I think is a common case here (perhaps I'm wrong) is the need to
>       choose between two or more `Maybe` values where at most one of them will
>       be a `Just`. `maybe` does not do that. `catMaybes` could be used for
>       that when all the `Maybe` have the same inner type, but it is not the
>       exact abstraction and it would need more code (just like simply doing a
>       case analysis).
>
>       Thanks and, again, sorry for the hurried question before (I don't like
>       when I see it from others :()
>
>       Marc Busqué
>       http://waiting-for-dev.github.io/about/
>
>       On Tue, 31 Jul 2018, Paul wrote:
>
>       >
>       > Something like "maybe" function?
>       >
>       >
>       > 31.07.2018 10:07, Marc Busqué wrotes:
>       >       Hi!
>       >
>       >       I have two functions:
>       >
>       >       ```
>       >       foo :: a -> Maybe b
>       >       bar :: a -> Maybe c
>       >       ```
>       >
>       >       From which I want to build a higher order function:
>       >
>       >       ```
>       >       foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
>       >       ```
>       >
>       >       The implementation I need is:
>       >
>       >       ```
>       >       foobar x f g =
>       >         case (f x) of
>       >           Nothing -> g x
>       >           Just y  -> Just y
>       >       ```
>       >
>       >       I'm a bit surprised that looking at hoogle I don't find a built-in
>       >       solution for this quite common need for `Maybe` types (or perhaps for
>       >       any monad).
>       >
>       >       Am I looking in the wrong way? Does it exist a similar abstraction but
>       >       with a different shape?
>       >
>       >       Thanks in advance,
>       >
>       >       Marc Busqué
>       >       http://waiting-for-dev.github.io/about/
>       >
>       >
>       > _______________________________________________
>       > 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 wiggly at wiggly.org  Tue Jul 31 12:07:21 2018
From: wiggly at wiggly.org (Nigel Rantor)
Date: Tue, 31 Jul 2018 13:07:21 +0100
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <alpine.LNX.2.21.1807310857500.2536@localhost>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
Message-ID: <390303ce-5629-205e-ae8c-6f22f8ae3a6c@wiggly.org>


Your `foobar` function cannot work, it doesn't handle the case when the 
URL is neither http nor https.

I would use catMaybes and headMay to work this out...untested code, and 
you'll need the `safe` library for headMay too...

parse :: ByteString -> Maybe (Url Http, Option scheme)
parse input = headMay $ catMaybes $ fmap input [parseUrlHttp, parseUrlHttps]

And everything is lazy so if the input gets parsed correctly by the 
first call you never actually perform the second one....

   n

On 31/07/18 08:07, Marc Busqué wrote:
> Hi!
> 
> I have two functions:
> 
> ```
> foo :: a -> Maybe b
> bar :: a -> Maybe c
> ```
> 
>  From which I want to build a higher order function:
> 
> ```
> foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
> ```
> 
> The implementation I need is:
> 
> ```
> foobar x f g =
>    case (f x) of
>      Nothing -> g x
>      Just y  -> Just y
> ```
> 
> I'm a bit surprised that looking at hoogle I don't find a built-in
> solution for this quite common need for `Maybe` types (or perhaps for
> any monad).
> 
> Am I looking in the wrong way? Does it exist a similar abstraction but
> with a different shape?
> 
> Thanks in advance,
> 
> Marc Busqué
> http://waiting-for-dev.github.io/about/
> 
> 
> _______________________________________________
> 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 marc at lamarciana.com  Tue Jul 31 12:07:38 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 31 Jul 2018 14:07:38 +0200 (CEST)
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <20180731102418.qt7g7h2vfceo7clc@weber>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <7a8ecc42-bf9e-f5e6-3a7f-a8cfc165a37c@gmail.com>
 <alpine.LNX.2.21.1807310926130.2536@localhost>
 <20180731102418.qt7g7h2vfceo7clc@weber>
Message-ID: <alpine.LNX.2.21.1807311406390.2536@localhost>

On Tue, 31 Jul 2018, Tom Ellis wrote:

> On Tue, Jul 31, 2018 at 09:47:07AM +0200, Marc Busqué wrote:
>> Apologies, I clearly asked the question in a rushed way...
>> 
>> I'm working with [req](http://hackage.haskell.org/package/req) package.
>> I need to parse a url from a string, but I don't know whether its schema
>> will be `http` or `https`. However, `req` just provides me with two
>> functions:
>> 
>> ```
>> parseUrlHttp :: ByteString -> Maybe (Url Http, Option scheme)
>> parseUrlHttps :: ByteString -> Maybe (Url Https, Option scheme)
>> ```
>
> This just sounds like bad API design from req.  Why is the API not
>
>    parseUrl :: ByteString -> Maybe (Either (Url Http) (Url Https), Option scheme)
>
>> What I think is a common case here (perhaps I'm wrong) is the need to
>> choose between two or more `Maybe` values where at most one of them will
>> be a `Just`.
>
> If that invariant really does hold then the authors of those functions
> should encode the invariant in the type. Requiring clients to observe the
> invariant for themselves sounds like a bad idea.

It sounds reasonably. I have opened an [issue in
req](https://github.com/mrkkrp/req/issues/48) with this feature request.

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

From marc at lamarciana.com  Tue Jul 31 13:58:58 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 31 Jul 2018 15:58:58 +0200 (CEST)
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <390303ce-5629-205e-ae8c-6f22f8ae3a6c@wiggly.org>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <390303ce-5629-205e-ae8c-6f22f8ae3a6c@wiggly.org>
Message-ID: <alpine.LNX.2.21.1807311556490.2536@localhost>

On Tue, 31 Jul 2018, Nigel Rantor wrote:

>
> Your `foobar` function cannot work, it doesn't handle the case when the 
> URL is neither http nor https.
>
> I would use catMaybes and headMay to work this out...untested code, and 
> you'll need the `safe` library for headMay too...
>
> parse :: ByteString -> Maybe (Url Http, Option scheme)
> parse input = headMay $ catMaybes $ fmap input [parseUrlHttp, parseUrlHttps]
>
> And everything is lazy so if the input gets parsed correctly by the 
> first call you never actually perform the second one....

Thanks Nigel! The problem is that the return type could be an `Url Http`
or an `Url Https`, so that wouldn't work. But an answer before by David
Feuer worked for my case:

```
boo :: Maybe a -> Maybe b -> Maybe (Either a b)
boo ma mb = (Left <$> ma) <|> (Right <$> mb)
```

Marc Busqué
http://waiting-for-dev.github.io/about/
>
>   n
>
> On 31/07/18 08:07, Marc Busqué wrote:
>> Hi!
>> 
>> I have two functions:
>> 
>> ```
>> foo :: a -> Maybe b
>> bar :: a -> Maybe c
>> ```
>>
>>  From which I want to build a higher order function:
>> 
>> ```
>> foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
>> ```
>> 
>> The implementation I need is:
>> 
>> ```
>> foobar x f g =
>>    case (f x) of
>>      Nothing -> g x
>>      Just y  -> Just y
>> ```
>> 
>> I'm a bit surprised that looking at hoogle I don't find a built-in
>> solution for this quite common need for `Maybe` types (or perhaps for
>> any monad).
>> 
>> Am I looking in the wrong way? Does it exist a similar abstraction but
>> with a different shape?
>> 
>> Thanks in advance,
>> 
>> Marc Busqué
>> http://waiting-for-dev.github.io/about/
>> 
>> 
>> _______________________________________________
>> 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 wiggly at wiggly.org  Tue Jul 31 15:09:02 2018
From: wiggly at wiggly.org (Nigel Rantor)
Date: Tue, 31 Jul 2018 16:09:02 +0100
Subject: [Haskell-cafe] Missing common function for Maybe types
In-Reply-To: <alpine.LNX.2.21.1807311556490.2536@localhost>
References: <alpine.LNX.2.21.1807310857500.2536@localhost>
 <390303ce-5629-205e-ae8c-6f22f8ae3a6c@wiggly.org>
 <alpine.LNX.2.21.1807311556490.2536@localhost>
Message-ID: <eadec801-89d4-1b02-a1d2-e216d200543d@wiggly.org>


I hadn't noticed they were different types...I can't say I love that API 
choice.

On 31/07/18 14:58, Marc Busqué wrote:
> On Tue, 31 Jul 2018, Nigel Rantor wrote:
> 
>>
>> Your `foobar` function cannot work, it doesn't handle the case when 
>> the URL is neither http nor https.
>>
>> I would use catMaybes and headMay to work this out...untested code, 
>> and you'll need the `safe` library for headMay too...
>>
>> parse :: ByteString -> Maybe (Url Http, Option scheme)
>> parse input = headMay $ catMaybes $ fmap input [parseUrlHttp, 
>> parseUrlHttps]
>>
>> And everything is lazy so if the input gets parsed correctly by the 
>> first call you never actually perform the second one....
> 
> Thanks Nigel! The problem is that the return type could be an `Url Http`
> or an `Url Https`, so that wouldn't work. But an answer before by David
> Feuer worked for my case:
> 
> ```
> boo :: Maybe a -> Maybe b -> Maybe (Either a b)
> boo ma mb = (Left <$> ma) <|> (Right <$> mb)
> ```
> 
> Marc Busqué
> http://waiting-for-dev.github.io/about/
>>
>>   n
>>
>> On 31/07/18 08:07, Marc Busqué wrote:
>>> Hi!
>>>
>>> I have two functions:
>>>
>>> ```
>>> foo :: a -> Maybe b
>>> bar :: a -> Maybe c
>>> ```
>>>
>>>  From which I want to build a higher order function:
>>>
>>> ```
>>> foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c
>>> ```
>>>
>>> The implementation I need is:
>>>
>>> ```
>>> foobar x f g =
>>>    case (f x) of
>>>      Nothing -> g x
>>>      Just y  -> Just y
>>> ```
>>>
>>> I'm a bit surprised that looking at hoogle I don't find a built-in
>>> solution for this quite common need for `Maybe` types (or perhaps for
>>> any monad).
>>>
>>> Am I looking in the wrong way? Does it exist a similar abstraction but
>>> with a different shape?
>>>
>>> Thanks in advance,
>>>
>>> Marc Busqué
>>> http://waiting-for-dev.github.io/about/
>>>
>>>
>>> _______________________________________________
>>> 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.