From monkleyon at gmail.com  Tue Dec  1 01:01:07 2020
From: monkleyon at gmail.com (MarLinn)
Date: Tue, 1 Dec 2020 02:01:07 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
Message-ID: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>

Most importantly: A good IDE is not a text editor, but an AST editor. If 
the AST happens to be presented as text, that's a choice of 
visualisation, nothing more. Better to start with a graph-like 
visualisation to free the mind, then think through the possible 
interactions. Maybe add the typical text-like visualisation later. But 
don't start there or you'll just re-invent notepad for the nth time.

Maybe don't even /store/ the code as ascii text.


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

From guthrie at miu.edu  Tue Dec  1 01:13:49 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Tue, 1 Dec 2020 01:13:49 +0000
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
Message-ID: <DM6PR03MB4331AC0504AB392C108E561BA1F40@DM6PR03MB4331.namprd03.prod.outlook.com>

Sem like there are *many* standard examples around, IntelliJ, Eclipse, Netbeans, etc.

Are there specific reasons that a Haskell IDE would be different in features??

Is there something lacking in use of (say) the standard IntelliJ IDE for Haskell?


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

From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of MarLinn
Sent: Monday, November 30, 2020 7:01 PM
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] What features should an (fictitious) IDE for Haskell have?


Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time.

Maybe don't even store the code as ascii text.

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

From migmit at gmail.com  Tue Dec  1 02:06:05 2020
From: migmit at gmail.com (Mig Mit)
Date: Tue, 1 Dec 2020 03:06:05 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
	Haskell have?
In-Reply-To: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
References: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
Message-ID: <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>

Please DO store code as ascii text. At the very least that would allow the use of external tools — sed, diff, git, whatever. Non-ascii representations were tried multiple times, and largely failed, in particular because of terrible interaction with other tools.

Also, please make sure your IDE is a good text editor. Because that's what the code is — not AST, but text. Until it is finished (to a certain lax definition of "finished") it is likely to not even be representable in AST form.

Sent from my iPad

> On 2020. Dec 1., at 2:02, MarLinn <monkleyon at gmail.com> wrote:
> 
> 
> Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time.
> 
> Maybe don't even store the code as ascii 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201201/97db765a/attachment.html>

From branimir.maksimovic at gmail.com  Tue Dec  1 02:38:24 2020
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Tue, 1 Dec 2020 03:38:24 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
References: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
Message-ID: <ce090106-5475-922b-d058-f17fe450aab5@gmail.com>

I am pretty sure they all work iwth utf-8 files...

Greets, Branimir.

On 1.12.20. 3:06 пре подне, Mig Mit wrote:
> Please DO store code as ascii text. At the very least that would allow 
> the use of external tools — sed, diff, git, whatever. Non-ascii 
> representations were tried multiple times, and largely failed, in 
> particular because of terrible interaction with other tools.
>
> Also, please make sure your IDE is a good text editor. Because that's 
> what the code is — not AST, but text. Until it is finished (to a 
> certain lax definition of "finished") it is likely to not even be 
> representable in AST form.
>
> Sent from my iPad
>
>> On 2020. Dec 1., at 2:02, MarLinn <monkleyon at gmail.com> wrote:
>>
>> 
>>
>> Most importantly: A good IDE is not a text editor, but an AST editor. 
>> If the AST happens to be presented as text, that's a choice of 
>> visualisation, nothing more. Better to start with a graph-like 
>> visualisation to free the mind, then think through the possible 
>> interactions. Maybe add the typical text-like visualisation later. 
>> But don't start there or you'll just re-invent notepad for the nth time.
>>
>> Maybe don't even /store/ the code as ascii 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.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201201/a5308b00/attachment.html>

From cma at bitemyapp.com  Tue Dec  1 02:50:22 2020
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 30 Nov 2020 20:50:22 -0600
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
Message-ID: <CADnndOqk0+B8twD0X4YVQ0Zo-EzGPYJ_inRnk_r3nu84KRZ_Cw@mail.gmail.com>

It would suffice for me if it was as performant, featureful, and reliable
as Intellij's Rust support.

On Mon, Nov 30, 2020 at 2:35 PM Gueven Bay via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Greetings,
>
> Imagine that you can decide what functionality and features an
> Integrated Development Environment for Haskell should get. You can
> make this IDE with your wishlist similar in power as other IDEs for
> Java for example.
>
> Now list as many features as you can, what would make the life of a
> Haskell developer as comfortable as possible!?
>
> I am dying to know how this list of features at the end (of this
> thread) will look like.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201130/9e369068/attachment.html>

From guthrie at miu.edu  Tue Dec  1 03:59:33 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Tue, 1 Dec 2020 03:59:33 +0000
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CADnndOqk0+B8twD0X4YVQ0Zo-EzGPYJ_inRnk_r3nu84KRZ_Cw@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <CADnndOqk0+B8twD0X4YVQ0Zo-EzGPYJ_inRnk_r3nu84KRZ_Cw@mail.gmail.com>
Message-ID: <DM6PR03MB4331A2D70663E7F7621FEB32A1F40@DM6PR03MB4331.namprd03.prod.outlook.com>

It might be good to update and refer to the wikihaskell.org page on Haskell IDEs.
     https://wiki.haskell.org/IDEs

(It only lists one IntelliJ option, of three)

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

From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Christopher Allen
Sent: Monday, November 30, 2020 8:50 PM
To: Gueven Bay <gueven.bay at googlemail.com>
Cc: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] What features should an (fictitious) IDE for Haskell have?

It would suffice for me if it was as performant, featureful, and reliable as Intellij's Rust support.

On Mon, Nov 30, 2020 at 2:35 PM Gueven Bay via Haskell-Cafe <haskell-cafe at haskell.org<mailto:haskell-cafe at haskell.org>> wrote:
Greetings,

Imagine that you can decide what functionality and features an
Integrated Development Environment for Haskell should get. You can
make this IDE with your wishlist similar in power as other IDEs for
Java for example.

Now list as many features as you can, what would make the life of a
Haskell developer as comfortable as possible!?

I am dying to know how this list of features at the end (of this
thread) will look like.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


--
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201201/fd0d4e08/attachment.html>

From compl.yue at icloud.com  Tue Dec  1 06:53:19 2020
From: compl.yue at icloud.com (YueCompl)
Date: Tue, 1 Dec 2020 14:53:19 +0800
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <DM6PR03MB4331AC0504AB392C108E561BA1F40@DM6PR03MB4331.namprd03.prod.outlook.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <DM6PR03MB4331AC0504AB392C108E561BA1F40@DM6PR03MB4331.namprd03.prod.outlook.com>
Message-ID: <AD8F8F5B-7EDB-4FD1-A10C-08DD1AE13A81@icloud.com>

Typically, you programming with procedural mindset in an imperative language, but programming with mathematical mindset in a functional language. The difference in methodology would require difference in choices of methods / tactics.

> On 2020-12-01, at 09:13, Gregory Guthrie <guthrie at miu.edu> wrote:
> 
> Sem like there are *many* standard examples around, IntelliJ, Eclipse, Netbeans, etc.
>  
> Are there specific reasons that a Haskell IDE would be different in features??
>  
> Is there something lacking in use of (say) the standard IntelliJ IDE for Haskell?
>  
>  
> Dr. Gregory Guthrie
> Maharishi International University
> ----------------------------------------------------------------
>  
> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of MarLinn
> Sent: Monday, November 30, 2020 7:01 PM
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] What features should an (fictitious) IDE for Haskell have?
>  
> Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time.
> 
> Maybe don't even store the code as ascii 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.

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

From compl.yue at icloud.com  Tue Dec  1 07:05:16 2020
From: compl.yue at icloud.com (YueCompl)
Date: Tue, 1 Dec 2020 15:05:16 +0800
Subject: [Haskell-cafe] What features should an (fictitious) IDE
	for	Haskell have?
In-Reply-To: <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
References: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
Message-ID: <AACA2C07-E4C0-4B37-A185-92A50569856E@icloud.com>

Text is linear as it appears, but it is actually structured, and might be even more flexible. 

 In expressing structured ideas, I don't think it's easy to beat the ergonomics of text typing with certain graphics manipulation techniques, that'll be significant discovery in civilization of human beings once realized.

The Chinese word for civilization 文明 literally reads text and enlighten.

> On 2020-12-01, at 10:06, Mig Mit <migmit at gmail.com> wrote:
> 
> Please DO store code as ascii text. At the very least that would allow the use of external tools — sed, diff, git, whatever. Non-ascii representations were tried multiple times, and largely failed, in particular because of terrible interaction with other tools.
> 
> Also, please make sure your IDE is a good text editor. Because that's what the code is — not AST, but text. Until it is finished (to a certain lax definition of "finished") it is likely to not even be representable in AST form.
> 
> Sent from my iPad
> 
>> On 2020. Dec 1., at 2:02, MarLinn <monkleyon at gmail.com> wrote:
>> 
>> 
>> Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time.
>> 
>> Maybe don't even store the code as ascii 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.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201201/3706d10b/attachment.html>

From jo at durchholz.org  Tue Dec  1 08:28:44 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 1 Dec 2020 09:28:44 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
Message-ID: <712674d3-7305-48f3-9689-37cccdd51599@durchholz.org>

That's one of the ideas that come up on a regular basis, but it doesn't 
buy you anything in practice.

You want to be able to represent code in mails, websites, and books.
And you want that representation to be unambiguous, so you need to 
define the whole parsing process.

In the past, having a binary representation would help with refactoring 
and such, but modern CPUs are fast enough to create the AST on the fly. 
Even in the presence of syntax errors.

Also, pure AST editors tend to be clunky. They disallow invalid syntax, 
so the programmer is forced to do everything right. There are many 
situations where you start writing down something vague and refine it, 
dealing with those aspects first that you need.
In a sense, the problem is that an AST doesn't give you a scratchpad for 
ideas and vagueness, everything has to be perfect from the get-go.

I first heard about such an idea in the 90s (when on-the-fly parsing 
wasn't really doable). It was one of the things MS wanted to do, and 
they even created a prototype. It failed.

Am 01.12.20 um 02:01 schrieb MarLinn:
> Most importantly: A good IDE is not a text editor, but an AST editor. If 
> the AST happens to be presented as text, that's a choice of 
> visualisation, nothing more. Better to start with a graph-like 
> visualisation to free the mind, then think through the possible 
> interactions. Maybe add the typical text-like visualisation later. But 
> don't start there or you'll just re-invent notepad for the nth time.
> 
> Maybe don't even /store/ the code as ascii 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 jo at durchholz.org  Tue Dec  1 08:34:33 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 1 Dec 2020 09:34:33 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <AD8F8F5B-7EDB-4FD1-A10C-08DD1AE13A81@icloud.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <DM6PR03MB4331AC0504AB392C108E561BA1F40@DM6PR03MB4331.namprd03.prod.outlook.com>
 <AD8F8F5B-7EDB-4FD1-A10C-08DD1AE13A81@icloud.com>
Message-ID: <d0f45e08-0e15-b4f5-1d8f-3a2f055f5b01@durchholz.org>

All IDEs mentioned have good, sometimes excellent support for 
declarative languages like HTML, CSS, SQL, XML, you name it.

Sure, some things won't transfer easily. E.g. Haskell needs different 
debugging tools, and different performance investigation tools.

But at the coding & code inspection level, Haskell isn't any different. 
You code, you look up modules, you transform and refactor code. Modern 
IDEs tend to struggle with dynamic languages where the lack of type 
information makes them misidentify a lot of things, but Haskell isn't 
one of these (type inference is easy to do on the fly with a modern CPU).

Am 01.12.20 um 07:53 schrieb YueCompl via Haskell-Cafe:
> Typically, you programming with procedural mindset in an imperative 
> language, but programming with mathematical mindset in a functional 
> language. The difference in methodology would require difference in 
> choices of methods / tactics.
> 
>> On 2020-12-01, at 09:13, Gregory Guthrie <guthrie at miu.edu 
>> <mailto:guthrie at miu.edu>> wrote:
>>
>> Sem like there are **many** standard examples around, IntelliJ, 
>> Eclipse, Netbeans, etc.
>> Are there specific reasons that a Haskell IDE would be different in 
>> features??
>> Is there something lacking in use of (say) the standard IntelliJ IDE 
>> for Haskell?
>> Dr. Gregory Guthrie
>> Maharishi International University
>> ----------------------------------------------------------------
>> *From:*Haskell-Cafe <haskell-cafe-bounces at haskell.org 
>> <mailto:haskell-cafe-bounces at haskell.org>>*On Behalf Of*MarLinn
>> *Sent:*Monday, November 30, 2020 7:01 PM
>> *To:*haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org>
>> *Subject:*Re: [Haskell-cafe] What features should an (fictitious) IDE 
>> for Haskell have?
>>
>> Most importantly: A good IDE is not a text editor, but an AST editor. 
>> If the AST happens to be presented as text, that's a choice of 
>> visualisation, nothing more. Better to start with a graph-like 
>> visualisation to free the mind, then think through the possible 
>> interactions. Maybe add the typical text-like visualisation later. But 
>> don't start there or you'll just re-invent notepad for the nth time.
>>
>> Maybe don't even/store/the code as ascii 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.
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 compl.yue at icloud.com  Tue Dec  1 08:43:02 2020
From: compl.yue at icloud.com (YueCompl)
Date: Tue, 1 Dec 2020 16:43:02 +0800
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <712674d3-7305-48f3-9689-37cccdd51599@durchholz.org>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <712674d3-7305-48f3-9689-37cccdd51599@durchholz.org>
Message-ID: <2AC85AA7-D9A5-4A6F-B1FF-B96CB372988F@icloud.com>

I wish this is being discussed in https://www.reddit.com/r/haskell/ <https://www.reddit.com/r/haskell/> so I can upvote this comment.

Do we have an alternative mechanism as with the mailing list?

I noticed Julia's community has some bots cross posting between a few of its sites, do we or can we have a similar mechanism?

> On 2020-12-01, at 16:28, Joachim Durchholz <jo at durchholz.org> wrote:
> 
> That's one of the ideas that come up on a regular basis, but it doesn't buy you anything in practice.
> 
> You want to be able to represent code in mails, websites, and books.
> And you want that representation to be unambiguous, so you need to define the whole parsing process.
> 
> In the past, having a binary representation would help with refactoring and such, but modern CPUs are fast enough to create the AST on the fly. Even in the presence of syntax errors.
> 
> Also, pure AST editors tend to be clunky. They disallow invalid syntax, so the programmer is forced to do everything right. There are many situations where you start writing down something vague and refine it, dealing with those aspects first that you need.
> In a sense, the problem is that an AST doesn't give you a scratchpad for ideas and vagueness, everything has to be perfect from the get-go.
> 
> I first heard about such an idea in the 90s (when on-the-fly parsing wasn't really doable). It was one of the things MS wanted to do, and they even created a prototype. It failed.
> 
> Am 01.12.20 um 02:01 schrieb MarLinn:
>> Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time.
>> Maybe don't even /store/ the code as ascii 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.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201201/d3f141d0/attachment.html>

From jo at durchholz.org  Tue Dec  1 08:44:58 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 1 Dec 2020 09:44:58 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
Message-ID: <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>

I'm surprised nobody is looking at what's already there.

Haskell does have langserver support, which means it's easy to have a 
plugin in any modern IDE that does code completion, cross-referencing, 
on-the-fly diagnostics and such.

The more interesting question is: What's missing in the plugins for the 
popular IDEs?


Am 30.11.20 um 21:34 schrieb Gueven Bay via Haskell-Cafe:
> Greetings,
> 
> Imagine that you can decide what functionality and features an
> Integrated Development Environment for Haskell should get. You can
> make this IDE with your wishlist similar in power as other IDEs for
> Java for example.
> 
> Now list as many features as you can, what would make the life of a
> Haskell developer as comfortable as possible!?
> 
> I am dying to know how this list of features at the end (of this
> thread) will look like.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 svenpanne at gmail.com  Tue Dec  1 15:22:41 2020
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 1 Dec 2020 16:22:41 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
Message-ID: <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>

Am Di., 1. Dez. 2020 um 09:48 Uhr schrieb Joachim Durchholz <
jo at durchholz.org>:

> I'm surprised nobody is looking at what's already there.
>

Well, some time ago I actually did, and it was a slightly frustrating
experience: I'm using Spacemacs, and when I had a look last time, the
haskell-language-server project was very young, and so was lsp-haskell.el.
It took quite some time to read HOWTOs/compile/set up things etc., and the
result was a bit underwhelming: Slow, using tons of memory, buggy, etc.
Somehow this was to be expected from a new project, nevertheless it was a
bit demotivating. Although it had a much smaller feature set, I was much
more happy with Intero, it worked basically out-of-the-box. For most other
IDEs, setting up a language mode is often just ticking a checkbox or
pressing a button in an extension manager.

Haskell does have langserver support, which means it's easy to have a
> plugin in any modern IDE that does code completion, cross-referencing,
> on-the-fly diagnostics and such.
>

Unless things have changed dramatically in the last few months, "easy" is
definitely not the right word. Using the C++-LSP-Mode in Spacemacs takes a
one-liner in the config ("Hey, please use clangd as the LSP backend") and
an "apt install clangd" (if you don't have it already on your disk, which
is very likely if you do development in C++ on Linux). I had a very
different experience with Haskell and LSP.


> The more interesting question is: What's missing in the plugins for the
> popular IDEs?
>

You have probably already guessed my wish by now: A better end-user
experience for setting up a Haskell IDE. Perhaps I should give
haskell-language-server a new try, there seem to be precompiled binaries by
now, and the Emacs Lisp part had quite a few fixes. Don't get me wrong:
haskell-language-server is a great and important project, it's just that
some months ago I wouldn't have recommended it to a newcomer. But this is a
general problem in most Open Source projects: In their spare time,
programmers like to program new features, not some packaging/deployment
stuff, as important as the latter may be. This is probably only something
for a person who gets paid to do this, and I'm not sure if there are such
people in this project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201201/1aee3a35/attachment.html>

From godzbanebane at gmail.com  Tue Dec  1 15:36:41 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Tue, 1 Dec 2020 17:36:41 +0200
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
Message-ID: <CABT0e9pW470=3vSDpPy-VzF8xFACkk6VL0R_0yeD=NrwATfoGg@mail.gmail.com>

Things *have* changed dramatically - you can install hls via ghcup, or
clone+stack install.hs <desired-version>. For vim enabling it is literally
one line for your lsp client. For vscode you don't even need to
download/install it - there are static executables and installing the
extension is enough.

It also fails much less often, automatic setup configuration is improved,
and features are growing at a steady pace.

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

From svenpanne at gmail.com  Tue Dec  1 16:15:18 2020
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 1 Dec 2020 17:15:18 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CABT0e9pW470=3vSDpPy-VzF8xFACkk6VL0R_0yeD=NrwATfoGg@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <CABT0e9pW470=3vSDpPy-VzF8xFACkk6VL0R_0yeD=NrwATfoGg@mail.gmail.com>
Message-ID: <CANBN=ms4xEpPU4oytDqMMKK8f-NcYtuDp5jNNv9JNhS0ho-rOw@mail.gmail.com>

Am Di., 1. Dez. 2020 um 16:36 Uhr schrieb Georgi Lyubenov <
godzbanebane at gmail.com>:

> Things *have* changed dramatically - you can install hls via ghcup, or
> clone+stack install.hs <desired-version>. For vim enabling it is literally
> one line for your lsp client. For vscode you don't even need to
> download/install it - there are static executables and installing the
> extension is enough.
>

Looking at https://taylor.fausak.me/2020/11/22/haskell-survey-results/#s2q1,
stack is by far the most popular way to manage GHC installations. If I read
https://github.com/haskell/haskell-language-server correctly and I don't
want to compile hls for myself, I have the option of either using ghcup or
manually downloading the prebuilt binaries. I have never used ghcup before,
and I don't intend to do so in the future (stack user here ;-), but I gave
it a try. It took me some tries and modifications to the script to install
only hls (no need for additional GHC/Cabal installations) to an
XDG-conformant path. Downloading the wrapper + some hls versions manually
from https://github.com/haskell/haskell-language-server/releases is
definitely doable, but still a bit fiddly. I guess Vim people need to do
the same, only the VS Code extension does things more automagically.

In a nutshell: Much better than before, but a far cry from a one-liner for
the most common installation/IDE combos. There is probably not much
missing: Only a simple script to install the wrapper/all hls versions into
an XDG-conformant path (optionally selecting only a subset of the versions,
but this shouldn't be the default). Coupling this to ghcup doesn't look
like a good idea, this tries to set up too many unneeded things, at least I
wasn't able to figure out how to download *only* hls.


> It also fails much less often, automatic setup configuration is improved,
> and features are growing at a steady pace.
>

Great! :-) I think I'll give it a real try soon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201201/09fab1a4/attachment.html>

From tonyzorman at mailbox.org  Tue Dec  1 16:22:01 2020
From: tonyzorman at mailbox.org (Tony Zorman)
Date: Tue, 01 Dec 2020 17:22:01 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
Message-ID: <87wny11opi.fsf@hyperspace>

[ I forgot to CC the Haskell Cafe in the first version of this, my
  apologies to Sven for getting this message twice ]

On Tue, Dec 01 2020 16:22, Sven Panne wrote:
> Well, some time ago I actually did, and it was a slightly frustrating
> experience: I'm using Spacemacs, and when I had a look last time, the
> haskell-language-server project was very young, and so was lsp-haskell.el.
> It took quite some time to read HOWTOs/compile/set up things etc., and the
> result was a bit underwhelming: Slow, using tons of memory, buggy, etc.
> Somehow this was to be expected from a new project, nevertheless it was a
> bit demotivating. Although it had a much smaller feature set, I was much
> more happy with Intero, it worked basically out-of-the-box. For most other
> IDEs, setting up a language mode is often just ticking a checkbox or
> pressing a button in an extension manager.

Things are actually much better now, especially for Emacs.  Starting
with Emacs 27, it now uses a proper JSON parser, making LSP operations
much, much faster.  Installation is also a breeze.  For example, eglot
uses HIE by default, so setting it up within Emacs (vanilla, though I
doubt it would be much more complicated for Spacemacs) would just be

    (use-package eglot
      :hook (haskell-mode . eglot-ensure))

If you want to use ghcide instead of HIE, you can throw a 

    (add-to-list 'eglot-server-programs '(haskell-mode . ("ghcide" "--lsp")))

in there somewhere.  The procedure is very similar if you use lsp-mode
instead of eglot.

> Unless things have changed dramatically in the last few months, "easy" is
> definitely not the right word. Using the C++-LSP-Mode in Spacemacs takes a
> one-liner in the config ("Hey, please use clangd as the LSP backend") and
> an "apt install clangd" (if you don't have it already on your disk, which
> is very likely if you do development in C++ on Linux). I had a very
> different experience with Haskell and LSP.

The second part is more of a "why has no-one packaged this for
Debian/Ubuntu derivatives" (which I'm not sure is true anymore, but I
don't use either so I can't check) shortcoming than a Haskell LSP
shortcoming, don't you think?

From x+haskell at tomsmeding.com  Tue Dec  1 16:36:13 2020
From: x+haskell at tomsmeding.com (Tom Smeding)
Date: Tue, 01 Dec 2020 16:36:13 +0000
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
	Haskell have?
In-Reply-To: <CANBN=ms4xEpPU4oytDqMMKK8f-NcYtuDp5jNNv9JNhS0ho-rOw@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <CABT0e9pW470=3vSDpPy-VzF8xFACkk6VL0R_0yeD=NrwATfoGg@mail.gmail.com>
 <CANBN=ms4xEpPU4oytDqMMKK8f-NcYtuDp5jNNv9JNhS0ho-rOw@mail.gmail.com>
Message-ID: <Q3m-h2C9-qA2KvLjCz9sCWnz25eLLWMH543OBZ2-ucFEsw86qbYP1WsA5xUz1FyAHnzmEWdiUH30OQuTNvTeT40mxvlrBcgx5R4pEXJpHrw=@tomsmeding.com>

What I believe you got hung up on is the installation script that the website (https://www.haskell.org/ghcup/) attempts to push on you. This installation scripts tries to do lots of things, but what may have worked better for you is to just offer the right precompiled binary to the user.

If you want to try, the current latest binary can be downloaded this directory (select the one for your system): https://downloads.haskell.org/~ghcup/0.1.12/
Having that and putting the binary in your PATH allows you to run the following:
$ env GHCUP_USE_XDG_DIRS=1 ghcup install hls
This will install HLS only, no additional stuff, and use the XDG directory structure.

An alternative to letting users download the right binary themselves is of course to change the script. My point is that the only part of ghcup that tries to do "too much" is that installation script, not ghcup itself.

Cheers,
Tom

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, December 1, 2020 5:15 PM, Sven Panne <svenpanne at gmail.com> wrote:

> Am Di., 1. Dez. 2020 um 16:36 Uhr schrieb Georgi Lyubenov <godzbanebane at gmail.com>:
>
>> Things *have* changed dramatically - you can install hls via ghcup, or clone+stack install.hs <desired-version>. For vim enabling it is literally one line for your lsp client. For vscode you don't even need to download/install it - there are static executables and installing the extension is enough.
>
> Looking at https://taylor.fausak.me/2020/11/22/haskell-survey-results/#s2q1, stack is by far the most popular way to manage GHC installations. If I read https://github.com/haskell/haskell-language-server correctly and I don't want to compile hls for myself, I have the option of either using ghcup or manually downloading the prebuilt binaries. I have never used ghcup before, and I don't intend to do so in the future (stack user here ;-), but I gave it a try. It took me some tries and modifications to the script to install only hls (no need for additional GHC/Cabal installations) to an XDG-conformant path. Downloading the wrapper + some hls versions manually from https://github.com/haskell/haskell-language-server/releases is definitely doable, but still a bit fiddly. I guess Vim people need to do the same, only the VS Code extension does things more automagically.
>
> In a nutshell: Much better than before, but a far cry from a one-liner for the most common installation/IDE combos. There is probably not much missing: Only a simple script to install the wrapper/all hls versions into an XDG-conformant path (optionally selecting only a subset of the versions, but this shouldn't be the default). Coupling this to ghcup doesn't look like a good idea, this tries to set up too many unneeded things, at least I wasn't able to figure out how to download *only* hls.
>
>> It also fails much less often, automatic setup configuration is improved, and features are growing at a steady pace.
>
> Great! :-) I think I'll give it a real try soon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201201/ac04a760/attachment.html>

From marian.jancar at gmx.com  Tue Dec  1 16:57:47 2020
From: marian.jancar at gmx.com (Marian Jancar)
Date: Tue, 1 Dec 2020 16:57:47 +0000
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
References: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
Message-ID: <117e9faf-2896-4416-d9ec-62b36bc12444@gmx.com>

Some time ago there was a thread about an article where the author
advocated for extremely long and descriptive variable names.
Discussion spread if that is the right approach and what is the best
variable name length and descriptiveness.

The correct choice depends on the reader context.

The article author works as a contractor.
He reads a lot of code for the first time.
Long and descriptive variable names help him a lot.

For someone else, well acquainted with the code, are such long names
only a clutter that reduces readability.
They might prefer single letter variable names, or pointfree style.

So each of them goes and adjusts the variable name descriptiveness
slider in the fictitious IDE aproppriately.

The todays text-as-the-primary-representation approach however forces
the author to make a pick already when writing the code.

On 12/1/20 2:06 AM, Mig Mit wrote:
> Please DO store code as ascii text. At the very least that would allow
> the use of external tools — sed, diff, git, whatever. Non-ascii
> representations were tried multiple times, and largely failed, in
> particular because of terrible interaction with other tools.
>
> Also, please make sure your IDE is a good text editor. Because that's
> what the code is — not AST, but text. Until it is finished (to a certain
> lax definition of "finished") it is likely to not even be representable
> in AST form.
>
> Sent from my iPad
>
>> On 2020. Dec 1., at 2:02, MarLinn <monkleyon at gmail.com> wrote:
>>
>> 
>>
>> Most importantly: A good IDE is not a text editor, but an AST editor.
>> If the AST happens to be presented as text, that's a choice of
>> visualisation, nothing more. Better to start with a graph-like
>> visualisation to free the mind, then think through the possible
>> interactions. Maybe add the typical text-like visualisation later. But
>> don't start there or you'll just re-invent notepad for the nth time.
>>
>> Maybe don't even /store/ the code as ascii 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.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 svenpanne at gmail.com  Tue Dec  1 18:58:11 2020
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 1 Dec 2020 19:58:11 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <117e9faf-2896-4416-d9ec-62b36bc12444@gmx.com>
References: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
 <117e9faf-2896-4416-d9ec-62b36bc12444@gmx.com>
Message-ID: <CANBN=mtLe6YKc6wMHJ578cmOqHwpU-b+PxkFWwOXHmGRshJbVg@mail.gmail.com>

Am Di., 1. Dez. 2020 um 17:59 Uhr schrieb Marian Jancar <
marian.jancar at gmx.com>:

> [...] The correct choice depends on the reader context.
>

I don't think so: The choice mainly depends on the size of the scope where
a name is valid. If you have e.g. a one-line comprehension, I don't see any
point in having a long descriptive name for a name only bound within this
comprehension, it just makes reading harder and more tedious. OTOH, if you
have an API entry point (i.e. a huge/global scope), a longer descriptive
name is far better. And even then: The initial assumption seems to be that
people will pick *good *long names, but this doesn't match with my
experience: People who write incomprehensible code usually pick
incomprehensible/silly/misleading names, too. OTOH, clear, well-structured
code is very readable even with f, g, x, y, ...

[...] The todays text-as-the-primary-representation approach however forces
> the author to make a pick already when writing the code.
>

The fictitious example forces the author to come up with a good *long *name
(which I guess won't work most of the time). How could the IDE come up with
a long name otherwise? I would simply refuse to give a name in a one-liner
comprehension a long name, what for? And shortening long names in a
sensible way doesn't look easy either.

As others have already mentioned before: The idea of having AST editors
instead of text editors comes up again and again for several decades, and
no one has come up with a nice working IDE yet which people actually want
to use in day-to-day work. It's simply hard to beat the efficiency of
people trained in typing text for decades in a text-based editor. The idea
seems to be good enough to produce some research work and/or conference
papers, but not really much more...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201201/0fd6c2c0/attachment.html>

From jo at durchholz.org  Tue Dec  1 21:48:43 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 1 Dec 2020 22:48:43 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <117e9faf-2896-4416-d9ec-62b36bc12444@gmx.com>
References: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
 <117e9faf-2896-4416-d9ec-62b36bc12444@gmx.com>
Message-ID: <7e28756b-73d2-c12b-6258-77b7e676f29e@durchholz.org>

Am 01.12.20 um 17:57 schrieb Marian Jancar:
> The todays text-as-the-primary-representation approach however forces
> the author to make a pick already when writing the code.

A binary-only representation will also force to pick names.
After all, the code will have to be read and understood, so the 
requirements on names are essentially identical.

From jo at durchholz.org  Tue Dec  1 21:50:13 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 1 Dec 2020 22:50:13 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <2AC85AA7-D9A5-4A6F-B1FF-B96CB372988F@icloud.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <712674d3-7305-48f3-9689-37cccdd51599@durchholz.org>
 <2AC85AA7-D9A5-4A6F-B1FF-B96CB372988F@icloud.com>
Message-ID: <b7089560-c1e8-b41d-7cd4-f447b4ba1aa7@durchholz.org>

Well, mailing lists don't give you that option so just can't judge a 
post by number of upvotes.

Which has advantages and drawbacks, so I guess it's fine as it is.

Am 01.12.20 um 09:43 schrieb YueCompl:
> I wish this is being discussed in https://www.reddit.com/r/haskell/ so I 
> can upvote this comment.
> 
> Do we have an alternative mechanism as with the mailing list?
> 
> I noticed Julia's community has some bots cross posting between a few of 
> its sites, do we or can we have a similar mechanism?
> 
>> On 2020-12-01, at 16:28, Joachim Durchholz <jo at durchholz.org 
>> <mailto:jo at durchholz.org>> wrote:
>>
>> That's one of the ideas that come up on a regular basis, but it 
>> doesn't buy you anything in practice.
>>
>> You want to be able to represent code in mails, websites, and books.
>> And you want that representation to be unambiguous, so you need to 
>> define the whole parsing process.
>>
>> In the past, having a binary representation would help with 
>> refactoring and such, but modern CPUs are fast enough to create the 
>> AST on the fly. Even in the presence of syntax errors.
>>
>> Also, pure AST editors tend to be clunky. They disallow invalid 
>> syntax, so the programmer is forced to do everything right. There are 
>> many situations where you start writing down something vague and 
>> refine it, dealing with those aspects first that you need.
>> In a sense, the problem is that an AST doesn't give you a scratchpad 
>> for ideas and vagueness, everything has to be perfect from the get-go.
>>
>> I first heard about such an idea in the 90s (when on-the-fly parsing 
>> wasn't really doable). It was one of the things MS wanted to do, and 
>> they even created a prototype. It failed.
>>
>> Am 01.12.20 um 02:01 schrieb MarLinn:
>>> Most importantly: A good IDE is not a text editor, but an AST editor. 
>>> If the AST happens to be presented as text, that's a choice of 
>>> visualisation, nothing more. Better to start with a graph-like 
>>> visualisation to free the mind, then think through the possible 
>>> interactions. Maybe add the typical text-like visualisation later. 
>>> But don't start there or you'll just re-invent notepad for the nth time.
>>> Maybe don't even /store/ the code as ascii 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.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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 jo at durchholz.org  Tue Dec  1 21:59:52 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 1 Dec 2020 22:59:52 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <87wny11opi.fsf@hyperspace>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <87wny11opi.fsf@hyperspace>
Message-ID: <b4104bb8-12f7-e352-dc8c-f1f79c5e05af@durchholz.org>

Am 01.12.20 um 17:22 schrieb Tony Zorman:
> The second part is more of a "why has no-one packaged this for
> Debian/Ubuntu derivatives" (which I'm not sure is true anymore, but I
> don't use either so I can't check) shortcoming than a Haskell LSP
> shortcoming, don't you think?

Actually I have stopped using prepackaged development environments on 
the Debian-based distros I have been using.

The thing is plugins. As soon as you need a plugin that isn't packages, 
you're starting to use a mixture of distro-provided IDE + standard 
plugins plus your own plugins. The experience tends to be "interesting" 
or "hell" depending on personal perspective, but at the end of the day, 
the primary purpose of a packaged IDE should be using it, not tinkering 
with it.

I have switched to installing all IDEs to ~/bin/, and the experience has 
become _much_ less painful - I couldn't care less about an Eclipse or 
IntelliJ package.

For things like Perl and Python, things can be even worse because these 
packages are geared towards running the distro, not towards developing 
software with them.
At least with Python, it's easy to set up in ~/bin/ or in a project 
directory using virtualenv, so I'm not using those packages either.

(I'm not going to advocate using any of these environments on a Haskell 
list, just showing experiences made with other languages ;-) )

Regards,
Jo

From spam at scientician.net  Wed Dec  2 09:08:40 2020
From: spam at scientician.net (Bardur Arantsson)
Date: Wed, 2 Dec 2020 10:08:40 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
	Haskell have?
In-Reply-To: <b4104bb8-12f7-e352-dc8c-f1f79c5e05af@durchholz.org>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <87wny11opi.fsf@hyperspace>
 <b4104bb8-12f7-e352-dc8c-f1f79c5e05af@durchholz.org>
Message-ID: <rq7liq$t3c$1@ciao.gmane.io>

On 01/12/2020 22.59, Joachim Durchholz wrote:
> Am 01.12.20 um 17:22 schrieb Tony Zorman:
>> The second part is more of a "why has no-one packaged this for
>> Debian/Ubuntu derivatives" (which I'm not sure is true anymore, but I
>> don't use either so I can't check) shortcoming than a Haskell LSP
>> shortcoming, don't you think?
> 
> I have switched to installing all IDEs to ~/bin/, and the experience has
> become _much_ less painful - I couldn't care less about an Eclipse or
> IntelliJ package.
> 

Absolutely agreed from many many years of experience. It almost always
ends up being less painful to just use the upstream's binary bundle (For
the reasons you stated.)... but perhaps I've been spoiled by the
(relative) good quality of Intellij IDEA's bundles.

> For things like Perl and Python, things can be even worse because these
> packages are geared towards running the distro, not towards developing
> software with them.

Same thing applies for Haskell on Arch Linux, for example.

Regards,


From branimir.maksimovic at gmail.com  Wed Dec  2 09:30:34 2020
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Wed, 2 Dec 2020 10:30:34 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <rq7liq$t3c$1@ciao.gmane.io>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <87wny11opi.fsf@hyperspace>
 <b4104bb8-12f7-e352-dc8c-f1f79c5e05af@durchholz.org>
 <rq7liq$t3c$1@ciao.gmane.io>
Message-ID: <ef2ca2e1-ccc4-c346-a25a-0030820d2c0a@gmail.com>


On 2.12.20. 10:08 пре подне, Bardur Arantsson wrote:
> On 01/12/2020 22.59, Joachim Durchholz wrote:
>> Am 01.12.20 um 17:22 schrieb Tony Zorman:
>>> The second part is more of a "why has no-one packaged this for
>>> Debian/Ubuntu derivatives" (which I'm not sure is true anymore, but I
>>> don't use either so I can't check) shortcoming than a Haskell LSP
>>> shortcoming, don't you think?
>> I have switched to installing all IDEs to ~/bin/, and the experience has
>> become _much_ less painful - I couldn't care less about an Eclipse or
>> IntelliJ package.
>>
> Absolutely agreed from many many years of experience. It almost always
> ends up being less painful to just use the upstream's binary bundle (For
> the reasons you stated.)... but perhaps I've been spoiled by the
> (relative) good quality of Intellij IDEA's bundles.
>
>> For things like Perl and Python, things can be even worse because these
>> packages are geared towards running the distro, not towards developing
>> software with them.
> Same thing applies for Haskell on Arch Linux, for example.


On Arch Linux you can't build anything. Only if you use bundle not 
related to distro...

and compiler is set for dynamic libraries so you have to set up cabal config

and ghs-options to use dynamic. But anyway you can't build lot of 
libraries...

Greets, Branimir.

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

From brenthwalker at gmail.com  Wed Dec  2 15:12:22 2020
From: brenthwalker at gmail.com (Brent Walker)
Date: Wed, 2 Dec 2020 17:12:22 +0200
Subject: [Haskell-cafe] Question on Coerce
Message-ID: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>

In the following code, function fmap does not compile because variable 'y'
on line marked <***> has type (Expr a) where an (Expr b) is expected.  The
code can be fixed simply by returning (Val x) on the rhs of the function
but then we are allocating a new object for something we could potentially
reuse since (Val n) has the same runtime representation in (Expr a) and
(Expr b) (it has no dependence on the type variable).

I was reading about coerce (Data.Coerce) recently and thought this could be
a place it could be used but simply replacing the 'y' on the rhs with
'coerce y' does not compile (error message below).

Is it possible to use coerce in this context?

Thanks for any help,
Brent

=======================================
data Expr a = Var a | Val Int | Add (Expr a) (Expr a)
  deriving Show

instance Functor Expr where
  fmap :: (a -> b) -> Expr a -> Expr b
  fmap f (Var a) = Var (f a)
  fmap f (Add e0 e1) = Add (fmap f e0) (fmap f e1)
  fmap _ y@(Val x) = y   -- <***>

=======================================
/dev/proj/src/Ex12.hs:69:22: error:
    • Couldn't match representation of type ‘a’ with that of ‘b’
        arising from a use of ‘coerce’
      ‘a’ is a rigid type variable bound by
        the type signature for:
          fmap :: forall a b. (a -> b) -> Expr a -> Expr b
        at /dev/proj/src/Ex12.hs:66:11-38
      ‘b’ is a rigid type variable bound by
        the type signature for:
          fmap :: forall a b. (a -> b) -> Expr a -> Expr b
        at /dev/proj/src/Ex12.hs:66:11-38
    • In the expression: coerce y
      In an equation for ‘fmap’: fmap _ y@(Val _) = coerce y
      In the instance declaration for ‘Functor Expr’
    • Relevant bindings include
        y :: Expr a (bound at /dev/proj/src/Ex12.hs:69:10)
        fmap :: (a -> b) -> Expr a -> Expr b
          (bound at /dev/proj/src/Ex12.hs:67:3)
   |
69 |   fmap _ y@(Val _) = coerce y
   |                      ^^^^^^^^
=======================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201202/87d50f3d/attachment.html>

From david.feuer at gmail.com  Wed Dec  2 15:22:04 2020
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 2 Dec 2020 10:22:04 -0500
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
Message-ID: <CAMgWh9vAqvSV7+X8h0vjK0ovBA5y-np-mCVeb3YpFin-YgrvFQ@mail.gmail.com>

You could use unsafeCoerce, but I don't think it's worth the risk. With the
plain code, GHC will *try* to recover sharing in cases like this late in
compilation, after the types are erased.

On Wed, Dec 2, 2020, 10:12 AM Brent Walker <brenthwalker at gmail.com> wrote:

> In the following code, function fmap does not compile because variable 'y'
> on line marked <***> has type (Expr a) where an (Expr b) is expected.  The
> code can be fixed simply by returning (Val x) on the rhs of the function
> but then we are allocating a new object for something we could potentially
> reuse since (Val n) has the same runtime representation in (Expr a) and
> (Expr b) (it has no dependence on the type variable).
>
> I was reading about coerce (Data.Coerce) recently and thought this could
> be a place it could be used but simply replacing the 'y' on the rhs with
> 'coerce y' does not compile (error message below).
>
> Is it possible to use coerce in this context?
>
> Thanks for any help,
> Brent
>
> =======================================
> data Expr a = Var a | Val Int | Add (Expr a) (Expr a)
>   deriving Show
>
> instance Functor Expr where
>   fmap :: (a -> b) -> Expr a -> Expr b
>   fmap f (Var a) = Var (f a)
>   fmap f (Add e0 e1) = Add (fmap f e0) (fmap f e1)
>   fmap _ y@(Val x) = y   -- <***>
>
> =======================================
> /dev/proj/src/Ex12.hs:69:22: error:
>     • Couldn't match representation of type ‘a’ with that of ‘b’
>         arising from a use of ‘coerce’
>       ‘a’ is a rigid type variable bound by
>         the type signature for:
>           fmap :: forall a b. (a -> b) -> Expr a -> Expr b
>         at /dev/proj/src/Ex12.hs:66:11-38
>       ‘b’ is a rigid type variable bound by
>         the type signature for:
>           fmap :: forall a b. (a -> b) -> Expr a -> Expr b
>         at /dev/proj/src/Ex12.hs:66:11-38
>     • In the expression: coerce y
>       In an equation for ‘fmap’: fmap _ y@(Val _) = coerce y
>       In the instance declaration for ‘Functor Expr’
>     • Relevant bindings include
>         y :: Expr a (bound at /dev/proj/src/Ex12.hs:69:10)
>         fmap :: (a -> b) -> Expr a -> Expr b
>           (bound at /dev/proj/src/Ex12.hs:67:3)
>    |
> 69 |   fmap _ y@(Val _) = coerce y
>    |                      ^^^^^^^^
> =======================================
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201202/7c10ad0c/attachment.html>

From godzbanebane at gmail.com  Wed Dec  2 15:24:33 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Wed, 2 Dec 2020 17:24:33 +0200
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
Message-ID: <CABT0e9rwepwbFGGR_9qtJsgcBW7N9jPcCD9-yGo6t-xsJ=730w@mail.gmail.com>

You can only coerce between types that guaranteedly have the same runtime
representation (newtypes), and "structures of them". Look up Coercible for
more information.

In this case, there is no way to know that two arbitrary types a and b have
the same representation, so you can't coerce between them.

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

From godzbanebane at gmail.com  Wed Dec  2 15:26:36 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Wed, 2 Dec 2020 17:26:36 +0200
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAMgWh9vAqvSV7+X8h0vjK0ovBA5y-np-mCVeb3YpFin-YgrvFQ@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
 <CAMgWh9vAqvSV7+X8h0vjK0ovBA5y-np-mCVeb3YpFin-YgrvFQ@mail.gmail.com>
Message-ID: <CABT0e9qkP3cG_mcaP43DLOsm=iqa1OKmsihcsQxK139HJ22QLA@mail.gmail.com>

Oops! I was very confused! Sorry, ignore that. I think ghc doesn't "know"
which case you're in (after the pattern match) to allow the coercal.

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

From lemming at henning-thielemann.de  Wed Dec  2 16:00:21 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 2 Dec 2020 17:00:21 +0100 (CET)
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2012021659210.5986@sputnik>


On Wed, 2 Dec 2020, Brent Walker wrote:

> In the following code, function fmap does not compile because variable 
> 'y' on line marked <***> has type (Expr a) where an (Expr b) is 
> expected.  The code can be fixed simply by returning (Val x) on the rhs 
> of the function but then we are allocating a new object for something we 
> could potentially reuse since (Val n) has the same runtime 
> representation in (Expr a) and (Expr b) (it has no dependence on the 
> type variable).

Is it worth the trouble? It is only a leaf of the tree.

From brenthwalker at gmail.com  Wed Dec  2 16:14:37 2020
From: brenthwalker at gmail.com (Brent Walker)
Date: Wed, 2 Dec 2020 18:14:37 +0200
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAMgWh9vAqvSV7+X8h0vjK0ovBA5y-np-mCVeb3YpFin-YgrvFQ@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
 <CAMgWh9vAqvSV7+X8h0vjK0ovBA5y-np-mCVeb3YpFin-YgrvFQ@mail.gmail.com>
Message-ID: <CAGbt7rhUVuR95OX72T_jnt8wiypY+w3_St_Z=ohxPra_TkLbQg@mail.gmail.com>

At least up to the core representation (generated with -O2) the
optimization you suggest has not happened (see the marked line below).
Does it happen further down the pipeline?  Is there some flag I can use to
get some lower level representation to see that it actually does happen?
How does one get the final STG representation?

P.$fFunctorExpr_$cfmap
  = \ (@ a_a5Tu)
      (@ b_a5Tv)
      (f_a5Sb :: a_a5Tu -> b_a5Tv)
      (ds_d5Vm :: Expr a_a5Tu) ->
      case ds_d5Vm of {
        Var a1_a5Sc -> P.Var @ b_a5Tv (f_a5Sb a1_a5Sc);
        Val x_a5Sg -> P.Val @ b_a5Tv x_a5Sg;       <--
*****************************************
        Add e0_a5Se e1_a5Sf ->
          P.Add
            @ b_a5Tv
            (P.$fFunctorExpr_$cfmap @ a_a5Tu @ b_a5Tv f_a5Sb e0_a5Se)
            (P.$fFunctorExpr_$cfmap @ a_a5Tu @ b_a5Tv f_a5Sb e1_a5Sf)
      }

On Wed, Dec 2, 2020 at 5:22 PM David Feuer <david.feuer at gmail.com> wrote:

> You could use unsafeCoerce, but I don't think it's worth the risk. With
> the plain code, GHC will *try* to recover sharing in cases like this late
> in compilation, after the types are erased.
>
> On Wed, Dec 2, 2020, 10:12 AM Brent Walker <brenthwalker at gmail.com> wrote:
>
>> In the following code, function fmap does not compile because variable
>> 'y' on line marked <***> has type (Expr a) where an (Expr b) is expected.
>> The code can be fixed simply by returning (Val x) on the rhs of the
>> function but then we are allocating a new object for something we could
>> potentially reuse since (Val n) has the same runtime representation in
>> (Expr a) and (Expr b) (it has no dependence on the type variable).
>>
>> I was reading about coerce (Data.Coerce) recently and thought this could
>> be a place it could be used but simply replacing the 'y' on the rhs with
>> 'coerce y' does not compile (error message below).
>>
>> Is it possible to use coerce in this context?
>>
>> Thanks for any help,
>> Brent
>>
>> =======================================
>> data Expr a = Var a | Val Int | Add (Expr a) (Expr a)
>>   deriving Show
>>
>> instance Functor Expr where
>>   fmap :: (a -> b) -> Expr a -> Expr b
>>   fmap f (Var a) = Var (f a)
>>   fmap f (Add e0 e1) = Add (fmap f e0) (fmap f e1)
>>   fmap _ y@(Val x) = y   -- <***>
>>
>> =======================================
>> /dev/proj/src/Ex12.hs:69:22: error:
>>     • Couldn't match representation of type ‘a’ with that of ‘b’
>>         arising from a use of ‘coerce’
>>       ‘a’ is a rigid type variable bound by
>>         the type signature for:
>>           fmap :: forall a b. (a -> b) -> Expr a -> Expr b
>>         at /dev/proj/src/Ex12.hs:66:11-38
>>       ‘b’ is a rigid type variable bound by
>>         the type signature for:
>>           fmap :: forall a b. (a -> b) -> Expr a -> Expr b
>>         at /dev/proj/src/Ex12.hs:66:11-38
>>     • In the expression: coerce y
>>       In an equation for ‘fmap’: fmap _ y@(Val _) = coerce y
>>       In the instance declaration for ‘Functor Expr’
>>     • Relevant bindings include
>>         y :: Expr a (bound at /dev/proj/src/Ex12.hs:69:10)
>>         fmap :: (a -> b) -> Expr a -> Expr b
>>           (bound at /dev/proj/src/Ex12.hs:67:3)
>>    |
>> 69 |   fmap _ y@(Val _) = coerce y
>>    |                      ^^^^^^^^
>> =======================================
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20201202/c2dd919d/attachment.html>

From jaro.reinders at gmail.com  Wed Dec  2 16:19:25 2020
From: jaro.reinders at gmail.com (Jaro Reinders)
Date: Wed, 2 Dec 2020 17:19:25 +0100
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CABT0e9rwepwbFGGR_9qtJsgcBW7N9jPcCD9-yGo6t-xsJ=730w@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
 <CABT0e9rwepwbFGGR_9qtJsgcBW7N9jPcCD9-yGo6t-xsJ=730w@mail.gmail.com>
Message-ID: <2d9fe230-5736-f465-cb09-e8b5601ecd3f@gmail.com>

Would it be possible to extend Coercible? I have also always wanted a coercible 
between the fixed point of the F-algebra and a recursive data type, e.g.:

	newtype Fix f = Fix (f (Fix f))

	data List a = Nil | Cons a (List a)

	data ListF a f = NilF | ConsF a f deriving Functor

	type List' a = Fix (ListF a)

I would like Coercible (List a) (Fix (ListF a)), then you don't have to 
manually write a conversion function when using a general catamorphism:

	cata :: (Functor f, Coercible a (Fix f)) => (f b -> b) -> (a -> b)

I have already tried this with unsafeCoerce and that works, much to my surprise.

It would be even nicer if GHC provided a built-in F-algebras, so that I 
wouldn't even need to define ListF manually.

(I know that these F-algebras can be generated automatically with Template 
Haskell, but that is too heavyweight for most of my use cases)

On 12/2/20 4:24 PM, Georgi Lyubenov wrote:
> You can only coerce between types that guaranteedly have the same runtime 
> representation (newtypes), and "structures of them". Look up Coercible for more 
> information.
> 
> In this case, there is no way to know that two arbitrary types a and b have the 
> same representation, so you can't coerce between them.
> 
> =======
> Georgi
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
> 

From brenthwalker at gmail.com  Wed Dec  2 16:32:22 2020
From: brenthwalker at gmail.com (Brent Walker)
Date: Wed, 2 Dec 2020 18:32:22 +0200
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <alpine.DEB.2.20.2012021659210.5986@sputnik>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
 <alpine.DEB.2.20.2012021659210.5986@sputnik>
Message-ID: <CAGbt7ribotiTzpjBxab9wPLwxzdOR94MWTZKF4fekYQ5BA_U_w@mail.gmail.com>

My question was on how to use coerce -- not whether this is worth doing or
not.  If we were discussing that, then I would say it's not 'just a leaf'
-- it's ALL the leaves of the tree -- and for a tree of depth n, there are
2^n of them so depending on what 'n' is, it could potentially be something
to worry about.



On Wed, Dec 2, 2020 at 6:00 PM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Wed, 2 Dec 2020, Brent Walker wrote:
>
> > In the following code, function fmap does not compile because variable
> > 'y' on line marked <***> has type (Expr a) where an (Expr b) is
> > expected.  The code can be fixed simply by returning (Val x) on the rhs
> > of the function but then we are allocating a new object for something we
> > could potentially reuse since (Val n) has the same runtime
> > representation in (Expr a) and (Expr b) (it has no dependence on the
> > type variable).
>
> Is it worth the trouble? It is only a leaf of the tree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201202/b03c3cd4/attachment.html>

From allbery.b at gmail.com  Wed Dec  2 17:19:23 2020
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 2 Dec 2020 12:19:23 -0500
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAGbt7ribotiTzpjBxab9wPLwxzdOR94MWTZKF4fekYQ5BA_U_w@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
 <alpine.DEB.2.20.2012021659210.5986@sputnik>
 <CAGbt7ribotiTzpjBxab9wPLwxzdOR94MWTZKF4fekYQ5BA_U_w@mail.gmail.com>
Message-ID: <CAKFCL4XooSJRFQ3T7JpBZRYe+j04JLXvA2FdMeb3_sxr5p0NdQ@mail.gmail.com>

coerce works when one type is a newtype wrapper for another, not when two
types happen to share the same runtime representation. I don't think ghc
can currently prove the latter except in the case of newtypes, especially
in the presence of optimizations.

On Wed, Dec 2, 2020 at 11:33 AM Brent Walker <brenthwalker at gmail.com> wrote:

> My question was on how to use coerce -- not whether this is worth doing or
> not.  If we were discussing that, then I would say it's not 'just a leaf'
> -- it's ALL the leaves of the tree -- and for a tree of depth n, there are
> 2^n of them so depending on what 'n' is, it could potentially be something
> to worry about.
>
>
>
> On Wed, Dec 2, 2020 at 6:00 PM Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>> On Wed, 2 Dec 2020, Brent Walker wrote:
>>
>> > In the following code, function fmap does not compile because variable
>> > 'y' on line marked <***> has type (Expr a) where an (Expr b) is
>> > expected.  The code can be fixed simply by returning (Val x) on the rhs
>> > of the function but then we are allocating a new object for something
>> we
>> > could potentially reuse since (Val n) has the same runtime
>> > representation in (Expr a) and (Expr b) (it has no dependence on the
>> > type variable).
>>
>> Is it worth the trouble? It is only a leaf of the tree.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



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

From jo at durchholz.org  Wed Dec  2 17:47:12 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Wed, 2 Dec 2020 18:47:12 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <rq7liq$t3c$1@ciao.gmane.io>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <87wny11opi.fsf@hyperspace>
 <b4104bb8-12f7-e352-dc8c-f1f79c5e05af@durchholz.org>
 <rq7liq$t3c$1@ciao.gmane.io>
Message-ID: <6eba7c48-89c9-0710-022a-f9bce90b8dee@durchholz.org>

> Absolutely agreed from many many years of experience. It almost always
> ends up being less painful to just use the upstream's binary bundle (For
> the reasons you stated.)... but perhaps I've been spoiled by the
> (relative) good quality of Intellij IDEA's bundles.

Eclipse works, too.
I had been using it for years before I had to switch for work-related 
reasons - IntelliJ has some strengths and some weaknesses compared to 
Eclipse, and it depends a lot on which of the two got more love and 
attention in the previous years.

From david.feuer at gmail.com  Wed Dec  2 17:50:09 2020
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 2 Dec 2020 12:50:09 -0500
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAKFCL4XooSJRFQ3T7JpBZRYe+j04JLXvA2FdMeb3_sxr5p0NdQ@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
 <alpine.DEB.2.20.2012021659210.5986@sputnik>
 <CAGbt7ribotiTzpjBxab9wPLwxzdOR94MWTZKF4fekYQ5BA_U_w@mail.gmail.com>
 <CAKFCL4XooSJRFQ3T7JpBZRYe+j04JLXvA2FdMeb3_sxr5p0NdQ@mail.gmail.com>
Message-ID: <CAMgWh9vSX4Y_rfndJbdFHQBwk3jvmMMdNdE=49X49qD02roX5Q@mail.gmail.com>

Optimizations don't seem to make the problem much *harder* (Generics manage
to work out "decided strictness", including unpacking), but they do make it
less stable: whether two things have the same representation in memory may
depend on optimization flags.

On Wed, Dec 2, 2020, 12:19 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> coerce works when one type is a newtype wrapper for another, not when two
> types happen to share the same runtime representation. I don't think ghc
> can currently prove the latter except in the case of newtypes, especially
> in the presence of optimizations.
>
> On Wed, Dec 2, 2020 at 11:33 AM Brent Walker <brenthwalker at gmail.com>
> wrote:
>
>> My question was on how to use coerce -- not whether this is worth doing
>> or not.  If we were discussing that, then I would say it's not 'just a
>> leaf' -- it's ALL the leaves of the tree -- and for a tree of depth n,
>> there are 2^n of them so depending on what 'n' is, it could potentially be
>> something to worry about.
>>
>>
>>
>> On Wed, Dec 2, 2020 at 6:00 PM Henning Thielemann <
>> lemming at henning-thielemann.de> wrote:
>>
>>>
>>> On Wed, 2 Dec 2020, Brent Walker wrote:
>>>
>>> > In the following code, function fmap does not compile because variable
>>> > 'y' on line marked <***> has type (Expr a) where an (Expr b) is
>>> > expected.  The code can be fixed simply by returning (Val x) on the
>>> rhs
>>> > of the function but then we are allocating a new object for something
>>> we
>>> > could potentially reuse since (Val n) has the same runtime
>>> > representation in (Expr a) and (Expr b) (it has no dependence on the
>>> > type variable).
>>>
>>> Is it worth the trouble? It is only a leaf of the tree.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201202/25ef1308/attachment.html>

From gueven.bay at googlemail.com  Wed Dec  2 19:24:21 2020
From: gueven.bay at googlemail.com (Gueven Bay)
Date: Wed, 2 Dec 2020 20:24:21 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <6eba7c48-89c9-0710-022a-f9bce90b8dee@durchholz.org>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <87wny11opi.fsf@hyperspace>
 <b4104bb8-12f7-e352-dc8c-f1f79c5e05af@durchholz.org>
 <rq7liq$t3c$1@ciao.gmane.io>
 <6eba7c48-89c9-0710-022a-f9bce90b8dee@durchholz.org>
Message-ID: <CAHonXRA0RwOTGe_s2-JO_MEXTgty5BeM1RUfFBtEyKVpZUBS+Q@mail.gmail.com>

Hi,

Thank you all for participating and gathering the features.

After reading all your answers I want to subsume all your features:
* moldable views of sources and searches in the sources
* automated refactoring
* configurable formatting and indentation
   (ghc-exactprint used in retrie, hlint and HaRe can help with that)
* a good IDE is an AST editor (or should it be just a very featureful
text editor?)
* IDEs like IntelliJ and Eclipse are designed from and for imperative
and  object-oriented developers
* Haskell would need specialized debugging and performance investigation tools
* some kind of automated adjustment (with an slider as GUI element) of
(very) * descriptive variable names
* the IDE itself should be performant and reliable
* use the haskell language server
* the IDE should be easy to set up and manage
 (it should come in a big but modularized bundle)

For some time now I had an idea for interactive wizards which create
Haskell source. Thinking about these little helpers I wanted to see if
there are some features Haskell devs wish they had in their
environments which I can with time build into the wizards.

Now how should the Haskell creator wizards look like:
On the very basic level they create every language feature of Haskell.
You want create a function? The wizard creates the function and its
parameters and everything needed to run the function and stores them
in the source.
Based on this the helpers should create data structures and
algorithms: As to create these you need in most cases several calls to
the basic level.
Next level would be "functionality": You do not want data structures,
you are a user, you want your problem solved. Using the DS+ALGS the
helpers create a calendar, a basic key-value store and much more.
Of course you can create your own functionality wizards using the more
basic wizards. It should be possible to call the wizards from the
command line and later there should be some kind of easy and basic GUI
(speak ncurses dialogs) for the wizards.
You now gave me some points more to think about to integrate in the wizards.

Am Mi., 2. Dez. 2020 um 18:47 Uhr schrieb Joachim Durchholz <jo at durchholz.org>:
>
> > Absolutely agreed from many many years of experience. It almost always
> > ends up being less painful to just use the upstream's binary bundle (For
> > the reasons you stated.)... but perhaps I've been spoiled by the
> > (relative) good quality of Intellij IDEA's bundles.
>
> Eclipse works, too.
> I had been using it for years before I had to switch for work-related
> reasons - IntelliJ has some strengths and some weaknesses compared to
> Eclipse, and it depends a lot on which of the two got more love and
> attention in the previous years.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 will.yager at gmail.com  Wed Dec  2 19:56:20 2020
From: will.yager at gmail.com (Will Yager)
Date: Wed, 2 Dec 2020 12:56:20 -0700
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAGbt7rhUVuR95OX72T_jnt8wiypY+w3_St_Z=ohxPra_TkLbQg@mail.gmail.com>
References: <CAGbt7rhUVuR95OX72T_jnt8wiypY+w3_St_Z=ohxPra_TkLbQg@mail.gmail.com>
Message-ID: <0840CFEF-9702-40B5-A367-485CA2E79B74@gmail.com>

This optimization happens after Core. Core is typed, and this optimization only makes sense after type erasure. 

> On Dec 2, 2020, at 9:16 AM, Brent Walker <brenthwalker at gmail.com> wrote:
> 
> 
> At least up to the core representation (generated with -O2) the optimization you suggest has not happened (see the marked line below).  Does it happen further down the pipeline? 

From compl.yue at icloud.com  Wed Dec  2 20:23:24 2020
From: compl.yue at icloud.com (YueCompl)
Date: Thu, 3 Dec 2020 04:23:24 +0800
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CAHonXRA0RwOTGe_s2-JO_MEXTgty5BeM1RUfFBtEyKVpZUBS+Q@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <87wny11opi.fsf@hyperspace>
 <b4104bb8-12f7-e352-dc8c-f1f79c5e05af@durchholz.org>
 <rq7liq$t3c$1@ciao.gmane.io>
 <6eba7c48-89c9-0710-022a-f9bce90b8dee@durchholz.org>
 <CAHonXRA0RwOTGe_s2-JO_MEXTgty5BeM1RUfFBtEyKVpZUBS+Q@mail.gmail.com>
Message-ID: <89D3FA5A-7F8B-4831-B783-958133380432@icloud.com>

I can't speak for other Haskellers, I even doubt I am a qualified Haskeller yet, but I don't think such *wizard* things will work well with Haskell, they might be suited to populate boilerplate bloated codebase, and when the project codebase would vastly follow imperative paradigm to develop routine business procedures. But I don't think Haskell is a great fit for that by today, though it had been said "Haskell is the best imperative language", as the ecosystem is geared toward solving whole categories of problems with highly abstract code, there are plenty pitfalls to develop specific, procedural components in Haskell.

Regards,
Compl

> On 2020-12-03, at 03:24, Gueven Bay via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
> Hi,
> 
> Thank you all for participating and gathering the features.
> 
> After reading all your answers I want to subsume all your features:
> * moldable views of sources and searches in the sources
> * automated refactoring
> * configurable formatting and indentation
>   (ghc-exactprint used in retrie, hlint and HaRe can help with that)
> * a good IDE is an AST editor (or should it be just a very featureful
> text editor?)
> * IDEs like IntelliJ and Eclipse are designed from and for imperative
> and  object-oriented developers
> * Haskell would need specialized debugging and performance investigation tools
> * some kind of automated adjustment (with an slider as GUI element) of
> (very) * descriptive variable names
> * the IDE itself should be performant and reliable
> * use the haskell language server
> * the IDE should be easy to set up and manage
> (it should come in a big but modularized bundle)
> 
> For some time now I had an idea for interactive wizards which create
> Haskell source. Thinking about these little helpers I wanted to see if
> there are some features Haskell devs wish they had in their
> environments which I can with time build into the wizards.
> 
> Now how should the Haskell creator wizards look like:
> On the very basic level they create every language feature of Haskell.
> You want create a function? The wizard creates the function and its
> parameters and everything needed to run the function and stores them
> in the source.
> Based on this the helpers should create data structures and
> algorithms: As to create these you need in most cases several calls to
> the basic level.
> Next level would be "functionality": You do not want data structures,
> you are a user, you want your problem solved. Using the DS+ALGS the
> helpers create a calendar, a basic key-value store and much more.
> Of course you can create your own functionality wizards using the more
> basic wizards. It should be possible to call the wizards from the
> command line and later there should be some kind of easy and basic GUI
> (speak ncurses dialogs) for the wizards.
> You now gave me some points more to think about to integrate in the wizards.
> 
> Am Mi., 2. Dez. 2020 um 18:47 Uhr schrieb Joachim Durchholz <jo at durchholz.org>:
>> 
>>> Absolutely agreed from many many years of experience. It almost always
>>> ends up being less painful to just use the upstream's binary bundle (For
>>> the reasons you stated.)... but perhaps I've been spoiled by the
>>> (relative) good quality of Intellij IDEA's bundles.
>> 
>> Eclipse works, too.
>> I had been using it for years before I had to switch for work-related
>> reasons - IntelliJ has some strengths and some weaknesses compared to
>> Eclipse, and it depends a lot on which of the two got more love and
>> attention in the previous years.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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 david.feuer at gmail.com  Wed Dec  2 20:26:27 2020
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 2 Dec 2020 15:26:27 -0500
Subject: [Haskell-cafe] Question on Coerce
In-Reply-To: <CAGbt7ribotiTzpjBxab9wPLwxzdOR94MWTZKF4fekYQ5BA_U_w@mail.gmail.com>
References: <CAGbt7rj9wbwH=kUxiapxQfM8Nz-9Fe-z04s-8_11CZPk8zdoCQ@mail.gmail.com>
 <alpine.DEB.2.20.2012021659210.5986@sputnik>
 <CAGbt7ribotiTzpjBxab9wPLwxzdOR94MWTZKF4fekYQ5BA_U_w@mail.gmail.com>
Message-ID: <CAMgWh9uuwN8Td9OJiugphZR+Kzh0+4TxDhNFAxXEb-Lo9HYD4w@mail.gmail.com>

Coincidentally, I've been thinking about (a small part of) this issue for a
day or two. I think it would probably be pretty easy to add a language
feature that basically brought what the compiler does up to the Haskell
level. Imagine a sort of *generalized* as-pattern:

f x@@(Right y) = ...

`x` here is not bound to the actual argument; instead, it is bound to
`Right y`. The type of `x` will either be inferred or given explicitly:

f (x :: ...)@@(Right y) = ...

How can this translate to Core? Roughly speaking, it would look like

f _x = case _x of
  Left p -> ...
  Right y ->
    let x = unsafeCoerce _x
    in ...

But `x` would be given the unfolding `Right y`.

For existentials and GADTs, the type checking and Core translation needs
some extras. In particular, the dictionary arguments need to be included to
ensure the coercion is valid. Just make sure they match. The special ~ and
Coercible constraints don't need to be included in that check, but it must
be possible to produce coercions with the appropriate types.

On Wed, Dec 2, 2020, 11:32 AM Brent Walker <brenthwalker at gmail.com> wrote:

> My question was on how to use coerce -- not whether this is worth doing or
> not.  If we were discussing that, then I would say it's not 'just a leaf'
> -- it's ALL the leaves of the tree -- and for a tree of depth n, there are
> 2^n of them so depending on what 'n' is, it could potentially be something
> to worry about.
>
>
>
> On Wed, Dec 2, 2020 at 6:00 PM Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>> On Wed, 2 Dec 2020, Brent Walker wrote:
>>
>> > In the following code, function fmap does not compile because variable
>> > 'y' on line marked <***> has type (Expr a) where an (Expr b) is
>> > expected.  The code can be fixed simply by returning (Val x) on the rhs
>> > of the function but then we are allocating a new object for something
>> we
>> > could potentially reuse since (Val n) has the same runtime
>> > representation in (Expr a) and (Expr b) (it has no dependence on the
>> > type variable).
>>
>> Is it worth the trouble? It is only a leaf of the tree.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201202/0e1463db/attachment-0001.html>

From branimir.maksimovic at gmail.com  Wed Dec  2 21:06:50 2020
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Wed, 2 Dec 2020 22:06:50 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <89D3FA5A-7F8B-4831-B783-958133380432@icloud.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <3209a376-f5e9-1f44-dd7d-5e19eb74f043@durchholz.org>
 <CANBN=msc=z4KSvU2ap8zCMroLoY_t-=GmTRusOFO31BaJj=DCw@mail.gmail.com>
 <87wny11opi.fsf@hyperspace>
 <b4104bb8-12f7-e352-dc8c-f1f79c5e05af@durchholz.org>
 <rq7liq$t3c$1@ciao.gmane.io>
 <6eba7c48-89c9-0710-022a-f9bce90b8dee@durchholz.org>
 <CAHonXRA0RwOTGe_s2-JO_MEXTgty5BeM1RUfFBtEyKVpZUBS+Q@mail.gmail.com>
 <89D3FA5A-7F8B-4831-B783-958133380432@icloud.com>
Message-ID: <3ab6e3e2-e6e2-a0af-c344-010930620ff9@gmail.com>

Fancy editor, VScode has Haskell support ;)

Greets, Branimir.

On 2.12.20. 9:23 по подне, YueCompl via Haskell-Cafe wrote:
> I can't speak for other Haskellers, I even doubt I am a qualified Haskeller yet, but I don't think such *wizard* things will work well with Haskell, they might be suited to populate boilerplate bloated codebase, and when the project codebase would vastly follow imperative paradigm to develop routine business procedures. But I don't think Haskell is a great fit for that by today, though it had been said "Haskell is the best imperative language", as the ecosystem is geared toward solving whole categories of problems with highly abstract code, there are plenty pitfalls to develop specific, procedural components in Haskell.
>
> Regards,
> Compl
>
>> On 2020-12-03, at 03:24, Gueven Bay via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
>>
>> Hi,
>>
>> Thank you all for participating and gathering the features.
>>
>> After reading all your answers I want to subsume all your features:
>> * moldable views of sources and searches in the sources
>> * automated refactoring
>> * configurable formatting and indentation
>>    (ghc-exactprint used in retrie, hlint and HaRe can help with that)
>> * a good IDE is an AST editor (or should it be just a very featureful
>> text editor?)
>> * IDEs like IntelliJ and Eclipse are designed from and for imperative
>> and  object-oriented developers
>> * Haskell would need specialized debugging and performance investigation tools
>> * some kind of automated adjustment (with an slider as GUI element) of
>> (very) * descriptive variable names
>> * the IDE itself should be performant and reliable
>> * use the haskell language server
>> * the IDE should be easy to set up and manage
>> (it should come in a big but modularized bundle)
>>
>> For some time now I had an idea for interactive wizards which create
>> Haskell source. Thinking about these little helpers I wanted to see if
>> there are some features Haskell devs wish they had in their
>> environments which I can with time build into the wizards.
>>
>> Now how should the Haskell creator wizards look like:
>> On the very basic level they create every language feature of Haskell.
>> You want create a function? The wizard creates the function and its
>> parameters and everything needed to run the function and stores them
>> in the source.
>> Based on this the helpers should create data structures and
>> algorithms: As to create these you need in most cases several calls to
>> the basic level.
>> Next level would be "functionality": You do not want data structures,
>> you are a user, you want your problem solved. Using the DS+ALGS the
>> helpers create a calendar, a basic key-value store and much more.
>> Of course you can create your own functionality wizards using the more
>> basic wizards. It should be possible to call the wizards from the
>> command line and later there should be some kind of easy and basic GUI
>> (speak ncurses dialogs) for the wizards.
>> You now gave me some points more to think about to integrate in the wizards.
>>
>> Am Mi., 2. Dez. 2020 um 18:47 Uhr schrieb Joachim Durchholz <jo at durchholz.org>:
>>>> Absolutely agreed from many many years of experience. It almost always
>>>> ends up being less painful to just use the upstream's binary bundle (For
>>>> the reasons you stated.)... but perhaps I've been spoiled by the
>>>> (relative) good quality of Intellij IDEA's bundles.
>>> Eclipse works, too.
>>> I had been using it for years before I had to switch for work-related
>>> reasons - IntelliJ has some strengths and some weaknesses compared to
>>> Eclipse, and it depends a lot on which of the two got more love and
>>> attention in the previous years.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view 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 m at jaspervdj.be  Thu Dec  3 18:52:54 2020
From: m at jaspervdj.be (Jasper Van der Jeugt)
Date: Thu, 3 Dec 2020 19:52:54 +0100
Subject: [Haskell-cafe] 2020 Haskell.org Call for Nominations
Message-ID: <20201203185254.GA7027@taiyaki>

Dear Haskellers,

It is time to put out a call for new nominations (typically but not
necessarily self-nominations) to the haskell.org committee.  Three
members of the committee are at the ends of their current terms: Ryan
Trinkle, George Wilson and Tikhon Jelvis.

The Haskell Foundation has also recently put out a call for
nominations.  How does Haskell.org differ from the new Haskell
Foundation?  Why should you nominate yourself for a role?

While the Haskell.org committee shares many goals with the Haskell
Foundation, it remains an independent organization to operate the
haskell.org website, provide resources and infrastructure, and
run programs such as GSoC, like it has been doing for years.  The
Haskell.org committee has voted to affiliate itself with the Haskell
Foundation and several of its members were involved in the founding of
the Haskell Foundation.  We believe that Haskell.org can represent the
community as a stakeholder in the Haskell Foundation and help drive it
forward.

This makes it an exciting time to nominate yourself, as we'll be able
to serve the community better, working closely with other groups in
the Haskell community.

To nominate yourself, please send an email to committee at haskell.org
by the 7th of January, 2020.  Current members are eligible to
re-nominate themselves.  Please feel free to include any information
about yourself that you think will help us to make a decision.

Being a member of the committee does not necessarily require a
significant amount of time, but committee members should aim to be
responsive during discussions when the committee is called upon to
make a decision.

Committee members do not need to be deep technical Haskell experts.
Instead we look for enthusiasm towards improving the Haskell
community.  We aim to represent the different facets of the community.
We aim to be diverse in terms of industry or research, and in terms of
gender, race and location.

The role is about setting policy, providing direction/guidance for
Haskell.org infrastructure, planning for the long term, and being
fiscally responsible with the Haskell.org funds and donations.  As
overseers for policy regarding the open source side of Haskell,
committee members must also be able to set aside personal or business
related bias and make decisions with the good of the open source
Haskell community in mind.

More details about the committee's roles and responsibilities are on

https://www.haskell.org/haskell-org-committee/

If you have any questions about the process, please feel free
to e-mail us at committee at haskell.org, or contact one of us
individually.

Warm regards
Jasper

From ben.franksen at online.de  Fri Dec  4 17:50:02 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Fri, 4 Dec 2020 18:50:02 +0100
Subject: [Haskell-cafe] untyped printf
Message-ID: <rqdssa$15fd$1@ciao.gmane.io>

I am writing an interpreter for a very simple untyped language and I
want to provide a built-in function to format a list of values in a
printf like fashion. There is the beautiful Text.Printf module with its
multi-variadic printf function, and I would like to use that to do all
the heavy lifting.

I can easily implement an

  instance PrintfArg Value

for my Value type, but what I need in addition to that is an "untyped"
version of printf i.e. something like

  format :: String -> [Value] -> String

with the property that

  format fmt [] = printf fmt
  format fmt [x] = printf fmt x
  format fmt [x,y] = printf fmt x y
  ...

I am pretty sure this is possible using a bit of class hackery and
perhaps GADTs or continuation passing thrown in, but I can't seem to get
it working. Any hint that helps to untangle the knots in my brain would
be appreciated!

Cheers
Ben


From lemming at henning-thielemann.de  Fri Dec  4 18:06:15 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 4 Dec 2020 19:06:15 +0100 (CET)
Subject: [Haskell-cafe] untyped printf
In-Reply-To: <rqdssa$15fd$1@ciao.gmane.io>
References: <rqdssa$15fd$1@ciao.gmane.io>
Message-ID: <alpine.DEB.2.20.2012041855450.6065@sputnik>


On Fri, 4 Dec 2020, Ben Franksen wrote:

> I am writing an interpreter for a very simple untyped language and I
> want to provide a built-in function to format a list of values in a
> printf like fashion. There is the beautiful Text.Printf module with its
> multi-variadic printf function, and I would like to use that to do all
> the heavy lifting.
>
> I can easily implement an
>
>  instance PrintfArg Value
>
> for my Value type, but what I need in addition to that is an "untyped"
> version of printf i.e. something like
>
>  format :: String -> [Value] -> String
>
> with the property that
>
>  format fmt [] = printf fmt
>  format fmt [x] = printf fmt x
>  format fmt [x,y] = printf fmt x y
>  ...


{-# LANGUAGE Rank2Types #-}
import Text.Printf (PrintfType, printf)

type Value = Int

formatWith :: (forall t. (PrintfType t) => t) -> [Value] -> String
formatWith pf [] = pf
formatWith pf (x:xs) = formatWith (pf x) xs

format :: String -> [Value] -> String
format fmt = formatWith (printf fmt)


*Main> format "(%d,%d)" [1,2]
"(1,2)"

*Main> format "(%d,%d)" [1,2,3]
"(1,2)*** Exception: printf: formatting string ended prematurely

*Main> format "(%d,%d)" [1]
"(1,*** Exception: printf: argument list ended prematurely

From ben.franksen at online.de  Fri Dec  4 18:43:50 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Fri, 4 Dec 2020 19:43:50 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
	Haskell have?
In-Reply-To: <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
References: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com>
Message-ID: <rqe016$c5i$1@ciao.gmane.io>

Am 01.12.20 um 03:06 schrieb Mig Mit:
> Please DO store code as ascii text. At the very least that would
> allow the use of external tools — sed, diff, git, whatever. Non-ascii
> representations were tried multiple times, and largely failed, in
> particular because of terrible interaction with other tools.
> 
> Also, please make sure your IDE is a good text editor. Because that's
> what the code is — not AST, but text. Until it is finished (to a
> certain lax definition of "finished") it is likely to not even be
> representable in AST form.

Absolutely. And "a good text editor" for me includes (a) an easy way to
re-configure key bindings and (b) the ability to define macros (using
some sort of embedded language). The point is that I want to be able to
re-use my finger's muscle memory as far as possible.

That's just the basics, of course, and on top of that I would expect at
least the ability to easily navigate to the definition of a variable and
also to iteratively visit all places where it is used, centering the
code in the editor window and highlighting the variable, such that I can
navigate to the next/previous occurrence, skip the whole file or
subdirectory, etc. Like a multi-file/multi-dir language aware search and
replace.

A very cool feature would be if I could select a program phrase and let
it find /similar/ phrases, where a similarity metric could be
edit-distance with respect to language tokens (ideally ignoring
redundant parentheses and stuff like that).

Cheers
Ben


From ben.franksen at online.de  Fri Dec  4 18:51:13 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Fri, 4 Dec 2020 19:51:13 +0100
Subject: [Haskell-cafe] untyped printf
In-Reply-To: <alpine.DEB.2.20.2012041855450.6065@sputnik>
References: <rqdssa$15fd$1@ciao.gmane.io>
 <alpine.DEB.2.20.2012041855450.6065@sputnik>
Message-ID: <rqe0f1$4qv$1@ciao.gmane.io>

Wow, that simple. Thanks Henning, my untangled brain feels a lot better :-)

Cheers
Ben

Am 04.12.20 um 19:06 schrieb Henning Thielemann:
> 
> On Fri, 4 Dec 2020, Ben Franksen wrote:
> 
>> I am writing an interpreter for a very simple untyped language and I
>> want to provide a built-in function to format a list of values in a
>> printf like fashion. There is the beautiful Text.Printf module with its
>> multi-variadic printf function, and I would like to use that to do all
>> the heavy lifting.
>>
>> I can easily implement an
>>
>>  instance PrintfArg Value
>>
>> for my Value type, but what I need in addition to that is an "untyped"
>> version of printf i.e. something like
>>
>>  format :: String -> [Value] -> String
>>
>> with the property that
>>
>>  format fmt [] = printf fmt
>>  format fmt [x] = printf fmt x
>>  format fmt [x,y] = printf fmt x y
>>  ...
> 
> 
> {-# LANGUAGE Rank2Types #-}
> import Text.Printf (PrintfType, printf)
> 
> type Value = Int
> 
> formatWith :: (forall t. (PrintfType t) => t) -> [Value] -> String
> formatWith pf [] = pf
> formatWith pf (x:xs) = formatWith (pf x) xs
> 
> format :: String -> [Value] -> String
> format fmt = formatWith (printf fmt)
> 
> 
> *Main> format "(%d,%d)" [1,2]
> "(1,2)"
> 
> *Main> format "(%d,%d)" [1,2,3]
> "(1,2)*** Exception: printf: formatting string ended prematurely
> 
> *Main> format "(%d,%d)" [1]
> "(1,*** Exception: printf: argument list ended prematurely
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



From lemming at henning-thielemann.de  Fri Dec  4 20:08:15 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 4 Dec 2020 21:08:15 +0100 (CET)
Subject: [Haskell-cafe] untyped printf
In-Reply-To: <rqe0f1$4qv$1@ciao.gmane.io>
References: <rqdssa$15fd$1@ciao.gmane.io>
 <alpine.DEB.2.20.2012041855450.6065@sputnik> <rqe0f1$4qv$1@ciao.gmane.io>
Message-ID: <alpine.DEB.2.20.2012042106340.6065@sputnik>


On Fri, 4 Dec 2020, Ben Franksen wrote:

> Wow, that simple. Thanks Henning, my untangled brain feels a lot better :-)

I tangled my brain because I expected that it must be possible in Haskell 
98 ...

... and actually it is:


import Text.Printf (PrintfType, printf)

type Value = Int

printfv :: (PrintfType printf) => String -> [Value] -> printf
printfv fmt [] = printf fmt
printfv fmt (x:xs) = printfv fmt xs x

format :: String -> [Value] -> String
format fmt = printfv fmt . reverse

From agocorona at gmail.com  Fri Dec  4 22:28:11 2020
From: agocorona at gmail.com (Alberto G. Corona)
Date: Fri, 4 Dec 2020 23:28:11 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <rqe016$c5i$1@ciao.gmane.io>
References: <20da4c92-0a74-5570-aca6-93a2b683f628@gmail.com>
 <2D4081A6-1D37-4D85-B830-067C17F89D2F@gmail.com> <rqe016$c5i$1@ciao.gmane.io>
Message-ID: <CAArEJmaYaMRJw5Vt9ujbujPnDV_Aqiaw12MpeCgpOEFjd6kdEw@mail.gmail.com>

Automatic code generation from type signature, using djinn exference and
other packages,

Automatically fill holes in the code using the same engines.

El vie, 4 dic 2020 a las 19:45, Ben Franksen (<ben.franksen at online.de>)
escribió:

> Am 01.12.20 um 03:06 schrieb Mig Mit:
> > Please DO store code as ascii text. At the very least that would
> > allow the use of external tools — sed, diff, git, whatever. Non-ascii
> > representations were tried multiple times, and largely failed, in
> > particular because of terrible interaction with other tools.
> >
> > Also, please make sure your IDE is a good text editor. Because that's
> > what the code is — not AST, but text. Until it is finished (to a
> > certain lax definition of "finished") it is likely to not even be
> > representable in AST form.
>
> Absolutely. And "a good text editor" for me includes (a) an easy way to
> re-configure key bindings and (b) the ability to define macros (using
> some sort of embedded language). The point is that I want to be able to
> re-use my finger's muscle memory as far as possible.
>
> That's just the basics, of course, and on top of that I would expect at
> least the ability to easily navigate to the definition of a variable and
> also to iteratively visit all places where it is used, centering the
> code in the editor window and highlighting the variable, such that I can
> navigate to the next/previous occurrence, skip the whole file or
> subdirectory, etc. Like a multi-file/multi-dir language aware search and
> replace.
>
> A very cool feature would be if I could select a program phrase and let
> it find /similar/ phrases, where a similarity metric could be
> edit-distance with respect to language tokens (ideally ignoring
> redundant parentheses and stuff like that).
>
> Cheers
> Ben
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201204/80cb4be1/attachment.html>

From jake.mcarthur at gmail.com  Fri Dec  4 22:38:09 2020
From: jake.mcarthur at gmail.com (Jake McArthur)
Date: Fri, 4 Dec 2020 17:38:09 -0500
Subject: [Haskell-cafe] STM rollback?
In-Reply-To: <5292b95a-e477-1cf4-deee-4605c8296e90@durchholz.org>
References: <20201128210552.GB20626@painter.painter>
 <5292b95a-e477-1cf4-deee-4605c8296e90@durchholz.org>
Message-ID: <CACN--9AieGEiGJbRpqYt2wRdDVU6FSshsGoN_LrWGmA6NFJTHw@mail.gmail.com>

I made an STM implementation for work with the ability to give a "reason"
for retrying, which I have found very useful. A Haskell version might look
something like this:

data STM e a
instance Monad (STM e)

-- These also form a monad, but we'd need a newtype to define the instance.
retry :: e -> STM e a
orElse :: STM e1 a -> (e1 -> STM e2 a) -> STM e2 a

With this interface, you could define something like this:

possiblyRollback :: STM (Either e a) b -> STM e (Either a b)
possiblyRollback stm = fmap stm Right `orElse` either retry (return . Left)

With this, you can retry as normal with `retry (Left e)`, locally rollback
with `retry (Right a)`, or return as normal with `return b`.

On Mon, Nov 30, 2020 at 3:47 AM Joachim Durchholz <jo at durchholz.org> wrote:

>  From a contract design perspective, rolling back means that an
> operation failed and had to be undone. (If everything was fine, you
> wouldn't want to rollback, wouldn't you?)
>
> So if rollback is the reaction to some failure, then triggering it via
> an exception is the Right Thing To Do, actually.
> Oh, and you always want to rollback if there's an exception somewhere.
>
> Now that contract thing warrants a few more words.
> Yes, you can word your contracts so that they include failure. It's just
> that they get more complicated. Usually so much more complicated that
> it's not worth it.
> Also, you want any exception (i.e. breach of contract) to go into a
> rollback. Now in Haskell, rolling back means just abandoning the
> computation since things aren't mutable and there is no state that you
> need to restore. Technically, not even in STM - so there *is* reason to
> make the rollback non-exceptional here: One could argue that STM is
> *supposed* to include the rollback in the contract.
> In the end, it depends on your use case: Do you want the rollback in the
> contract or not?
>
> Now for STM itself, yeah using an exception to trigger a rollback is a
> bit hacky.
> OTOH it works.
> OT3H it might be a good idea to have a rollback function for STM.
> Technically it would just trigger the same exception, but it would
> indicate that the rollback is part of the contract.
> OT4H throwing Rollback is essentially an indicator of non-failure
> rollback (otherwise you'd be throwing whatever exception is appropriate,
> or get aborted by some library functionality that throws an exception).
>
> Regards,
> Jo
>
> Am 28.11.20 um 22:05 schrieb amindfv--- via Haskell-Cafe:
> > I'd like to be able to give up on an STM transaction: roll back and
> don't retry.
> > I've cooked up something with exceptions but it feels a bit icky to use
> exceptions for something like this - is there a better way?:
> >
> >      data Rollback = Rollback deriving (Show)
> >      instance Exception Rollback
> >
> >      rollback :: STM x
> >      rollback = throwSTM Rollback
> >
> >      atomicallyWithRollback :: STM x -> IO (Maybe x)
> >      atomicallyWithRollback a =
> >         (Just <$> atomically a)
> >            `catch` (\Rollback -> pure Nothing)
> >
> > The alternative I've found is something like:
> >
> >      otherWay :: STM x -> IO (Maybe x)
> >      otherWay a =
> >         atomically $ (Just <$> a) `orElse` pure Nothing
> >
> > But this turns any "retry" in "a" into a rollback, and I'd like to have
> the option to do either (retry or rollback).
> >
> > Thanks,
> > Tom
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> >
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201204/cc9727ae/attachment.html>

From jake.mcarthur at gmail.com  Fri Dec  4 22:44:21 2020
From: jake.mcarthur at gmail.com (Jake McArthur)
Date: Fri, 4 Dec 2020 17:44:21 -0500
Subject: [Haskell-cafe] STM rollback?
In-Reply-To: <CACN--9AieGEiGJbRpqYt2wRdDVU6FSshsGoN_LrWGmA6NFJTHw@mail.gmail.com>
References: <20201128210552.GB20626@painter.painter>
 <5292b95a-e477-1cf4-deee-4605c8296e90@durchholz.org>
 <CACN--9AieGEiGJbRpqYt2wRdDVU6FSshsGoN_LrWGmA6NFJTHw@mail.gmail.com>
Message-ID: <CACN--9AMqA1pYQK5Pbx--CNxPyRbfLt3Y-=sknvSSmyqH0HbEA@mail.gmail.com>

Sorry for the noise. My code is wrong. Here is a corrected version:

possiblyRollback :: STM (Either e a) b -> STM e (Either a b)
possiblyRollback stm = fmap Right stm `orElse` either retry (return . Left)

On Fri, Dec 4, 2020 at 5:38 PM Jake McArthur <jake.mcarthur at gmail.com>
wrote:

> I made an STM implementation for work with the ability to give a "reason"
> for retrying, which I have found very useful. A Haskell version might look
> something like this:
>
> data STM e a
> instance Monad (STM e)
>
> -- These also form a monad, but we'd need a newtype to define the instance.
> retry :: e -> STM e a
> orElse :: STM e1 a -> (e1 -> STM e2 a) -> STM e2 a
>
> With this interface, you could define something like this:
>
> possiblyRollback :: STM (Either e a) b -> STM e (Either a b)
> possiblyRollback stm = fmap stm Right `orElse` either retry (return . Left)
>
> With this, you can retry as normal with `retry (Left e)`, locally rollback
> with `retry (Right a)`, or return as normal with `return b`.
>
> On Mon, Nov 30, 2020 at 3:47 AM Joachim Durchholz <jo at durchholz.org>
> wrote:
>
>>  From a contract design perspective, rolling back means that an
>> operation failed and had to be undone. (If everything was fine, you
>> wouldn't want to rollback, wouldn't you?)
>>
>> So if rollback is the reaction to some failure, then triggering it via
>> an exception is the Right Thing To Do, actually.
>> Oh, and you always want to rollback if there's an exception somewhere.
>>
>> Now that contract thing warrants a few more words.
>> Yes, you can word your contracts so that they include failure. It's just
>> that they get more complicated. Usually so much more complicated that
>> it's not worth it.
>> Also, you want any exception (i.e. breach of contract) to go into a
>> rollback. Now in Haskell, rolling back means just abandoning the
>> computation since things aren't mutable and there is no state that you
>> need to restore. Technically, not even in STM - so there *is* reason to
>> make the rollback non-exceptional here: One could argue that STM is
>> *supposed* to include the rollback in the contract.
>> In the end, it depends on your use case: Do you want the rollback in the
>> contract or not?
>>
>> Now for STM itself, yeah using an exception to trigger a rollback is a
>> bit hacky.
>> OTOH it works.
>> OT3H it might be a good idea to have a rollback function for STM.
>> Technically it would just trigger the same exception, but it would
>> indicate that the rollback is part of the contract.
>> OT4H throwing Rollback is essentially an indicator of non-failure
>> rollback (otherwise you'd be throwing whatever exception is appropriate,
>> or get aborted by some library functionality that throws an exception).
>>
>> Regards,
>> Jo
>>
>> Am 28.11.20 um 22:05 schrieb amindfv--- via Haskell-Cafe:
>> > I'd like to be able to give up on an STM transaction: roll back and
>> don't retry.
>> > I've cooked up something with exceptions but it feels a bit icky to use
>> exceptions for something like this - is there a better way?:
>> >
>> >      data Rollback = Rollback deriving (Show)
>> >      instance Exception Rollback
>> >
>> >      rollback :: STM x
>> >      rollback = throwSTM Rollback
>> >
>> >      atomicallyWithRollback :: STM x -> IO (Maybe x)
>> >      atomicallyWithRollback a =
>> >         (Just <$> atomically a)
>> >            `catch` (\Rollback -> pure Nothing)
>> >
>> > The alternative I've found is something like:
>> >
>> >      otherWay :: STM x -> IO (Maybe x)
>> >      otherWay a =
>> >         atomically $ (Just <$> a) `orElse` pure Nothing
>> >
>> > But this turns any "retry" in "a" into a rollback, and I'd like to have
>> the option to do either (retry or rollback).
>> >
>> > Thanks,
>> > Tom
>> >
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>> >
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20201204/ae7f92b7/attachment.html>

From emilypi at cohomolo.gy  Sat Dec  5 18:52:48 2020
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Sat, 05 Dec 2020 18:52:48 +0000
Subject: [Haskell-cafe] [Ann] group-theory
Message-ID: <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>

Hello all,

I am pleased to announce the release of the group-theory ( https://hackage.haskell.org/package/group-theory ) package: a package aimed at implementing the theory of finite groups in a reasonably ergonomic, well-documented, and featureful way. It's hardly finished, but my co-maintainer, Reed Mullanix (@totbwf) and I thought this was a good mvp with which we could announce.

Contributions are very welcome, and I hope everyone enjoys.

Cheers,

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

From emilypi at cohomolo.gy  Sat Dec  5 21:10:28 2020
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Sat, 05 Dec 2020 21:10:28 +0000
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <fESJl_F5iqIOrJivujxxLy1QqszBzBojPvB-fqUWob5s4ljagQtusMkEv8vw8uao0-lH_IxzXrIzh2DTtdpe9quu7EhSPjqM16vZrjbpv9Y=@coot.me>
References: <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <fESJl_F5iqIOrJivujxxLy1QqszBzBojPvB-fqUWob5s4ljagQtusMkEv8vw8uao0-lH_IxzXrIzh2DTtdpe9quu7EhSPjqM16vZrjbpv9Y=@coot.me>
Message-ID: <kic6k9qm.fa982fd8-431c-4db7-a23d-fc33da7a12cd@we.are.superhuman.com>

Hi Marcin,

> 
> Nice work; I also implemented free groups in the free-algebra package
> 
> 

Wonderful - I'll take a look. Those were a bit rough, and it'd be good to see how you encoded them in `free-algebra`. Maybe we can collaborate on expanding the knowledgebase and utility of free group calculations in our respective packages :)

> 
> However 'FG' is the free group in the class of all groups.
> 
> 

I'm glad you noted this as well! The `DList` encoding is interesting - I'll need to study that a bit :)

Someone has also linked me to Sjoerd's `free-functors` library, which seems is also very interesting:

https://github.com/sjoerdvisscher/free-functors/blob/master/src/Data/Functor/Free.hs#L70

> 
> There's an interesting difference between 'FreeGroup' (using notation of
> your package) and 'FG'.  First one is not a free group in the class of all
> groups, but only free in the class of groups for which multiplication is
> strict in the left argument
> 
> 

Correct. Regarding motivation, I provided both because I know some people do like to operate in the fast-and-loose strict subset of Haskell. It's no skin off my back. But I was very unsatisfied with strict (vis. "moral") Free constructions with respect to bottoms, and, inspired by Dan Doel's article ( http://comonad.com/reader/2015/free-monoids-in-haskell/ ), attempted to find a free construction for groups that was more in line with Haskell's domain-like types. I note this article in the documentation for FG.

Maybe this deserves a broader blog post?

> 
> I identified that `Foldable` can only be defined for algebraic structures
> for which `Endo b` has the same algebra type; this fails for groups: only
> automorphisms form a group.  Having a seprate `GroupFoldable` class makes
> sense.
> 
> 

That class ended up being good for two things:

* Great puns.

* Very convenient word evaluation

If you'd like to add to it, I'd be stoked.

Cheers,

Emily

On Sat, Dec 05, 2020 at 2:53 PM, < coot at coot.me > wrote:

> 
> Hi Emily,
> 
> Nice work; I also implemented free groups in the free-algebra package.
> 
> 
> There's an interesting difference between 'FreeGroup' (using notation of
> your package) and 'FG'.  First one is not a free group in the class of all
> groups, but only free in the class of groups for which multiplication is
> strict in the left argument, i.e. ones that satisfy the equation `⊥ <> a
> == ⊥`.   That's because `++` is strict in the left argument. For the same
> reason `[]` is free monoid in the class of left strict monoids.
> 
> 
> 
> However 'FG' is the free group in the class of all groups.  Another
> isomorphic construction of a free group  (in the class of all groups) can
> be based on `DList` - the free monoid.  You might want to check out https:/
> / hackage. haskell. org/ package/ free-algebras-0. 1. 0. 0/ docs/ Data-Algebra-Free.
> html (
> https://hackage.haskell.org/package/free-algebras-0.1.0.0/docs/Data-Algebra-Free.html
> ) which gives a uniform interface for all free algebras (not just groups). 
> You'll recover there `Monad` instance of `FG` (and `FreeGroup`), and a bit
> more.
> 
> 
> I identified that `Foldable` can only be defined for algebraic structures
> for which `Endo b` has the same algebra type; this fails for groups: only
> automorphisms form a group.  Having a seprate `GroupFoldable` class makes
> sense.
> 
> 
> 
> Cheers,
> 
> Marcin Szamotulski
> 
> 
> 
> 
> 
> 
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On Saturday, December 5th, 2020 at 19:52, Emily Pillmore < emilypi@ cohomolo.
> gy ( emilypi at cohomolo.gy ) > wrote:
> 
> 
> 
> 
>> Hello all,
>> 
>> 
>> 
>> I am pleased to announce the release of the group-theory (
>> https://hackage.haskell.org/package/group-theory ) package: a package aimed
>> at implementing the theory of finite groups in a reasonably ergonomic,
>> well-documented, and featureful way. It's hardly finished, but my
>> co-maintainer, Reed Mullanix (@totbwf) and I thought this was a good mvp
>> with which we could announce.
>> 
>> 
>> 
>> Contributions are very welcome, and I hope everyone enjoys.
>> 
>> 
>> 
>> Cheers,
>> 
>> Emily Pillmore
>> 
>> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201205/933add7e/attachment.html>

From jack at jackkelly.name  Sun Dec  6 00:04:55 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Sun, 06 Dec 2020 00:04:55 GMT
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
References: <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
Message-ID: <387165f3b38988de076a34462a1b9e61@jackkelly.name>


Hi Emily, Reed,

Congrats on the release. The mathematics involved is a little above my pay grade (there's only a bit of undergrad group theory in my brain somewhere, covered in cobwebs), but there is an implementation thing I'd like your thoughts on, while your heads are in this space:

Over in Reflex-land, they've been using an internal Group class for their `patch` library ( https://hackage.haskell.org/package/patch ), which has an instance (Ord k, Group q) => Group (MonoidalMap k q) that's unlawful:

fromList [(1,Sum 1)] <> invert (fromList [(1, Sum 1)]) == fromList [(1, Sum 0)]

(This is used in reflex's QueryT, I think so you can get incremental updates to the answer to a query.)

I think the actual abstraction they'd want is more like an inverse semigroup, where (x <> invert x <> x == x) and (invert x <> x <> invert x == x). But when I was chatting with taneb about this (we were talking about moving `patch` over to `groups` at one point), just putting `class InverseSemigroup` into a groups package means you have a tower of three classes that differ only in laws. And that feels a bit awkward.

Dunno what the answer is, but I wanted to flag it while your package is young and breaking changes are easy. I've been meaning to have a crack at moving the reflex patch-verse over to monoid-subclasses ( https://hackage.haskell.org/package/monoid-subclasses ), which I provides some the necessary tools with different names (patch reinvents MonoidNull, and I'm hoping that a subtraction-that-removes keys could be lawful for one of the Reductive/Cancellative classes).

-- Jack

December 6, 2020 4:52 AM, "Emily Pillmore" <emilypi at cohomolo.gy> wrote:

> Hello all,
> 
> I am pleased to announce the release of the group-theory package: a package aimed at implementing
> the theory of finite groups in a reasonably ergonomic, well-documented, and featureful way. It's
> hardly finished, but my co-maintainer, Reed Mullanix (@totbwf) and I thought this was a good mvp
> with which we could announce.
> 
> Contributions are very welcome, and I hope everyone enjoys.
> Cheers,
> Emily Pillmore

From worstla at gmail.com  Sun Dec  6 03:26:13 2020
From: worstla at gmail.com (Jim Blorg)
Date: Sat, 5 Dec 2020 22:26:13 -0500
Subject: [Haskell-cafe] Haskell on windows 7 without chocolatey?
Message-ID: <CAAYKvumnuaCKwFcgfsAT08GByQWD6S_mSGVWyFqQ_g7xj=wjyQ@mail.gmail.com>

Is there a way to install haskell on windows 7 manually via zip without all
the requirements for scripting?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201205/509e3e54/attachment.html>

From guthrie at miu.edu  Sun Dec  6 04:23:07 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Sun, 6 Dec 2020 04:23:07 +0000
Subject: [Haskell-cafe] Haskell on windows 7 without chocolatey?
In-Reply-To: <CAAYKvumnuaCKwFcgfsAT08GByQWD6S_mSGVWyFqQ_g7xj=wjyQ@mail.gmail.com>
References: <CAAYKvumnuaCKwFcgfsAT08GByQWD6S_mSGVWyFqQ_g7xj=wjyQ@mail.gmail.com>
Message-ID: <DM6PR03MB43312FFE3BA12800372083ABA1CF0@DM6PR03MB4331.namprd03.prod.outlook.com>

Same for W10 – PowerShell stops with some policy restrictions, and after a few gyrations – I wonder about a simpler method as in the past.


Dr. Gregory Guthrie
----------------------------------------------------------------

From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Jim Blorg
Sent: Saturday, December 5, 2020 9:26 PM
To: haskell-cafe at haskell.org
Subject: [Haskell-cafe] Haskell on windows 7 without chocolatey?

Is there a way to install haskell on windows 7 manually via zip without all the requirements for scripting?

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

From whosekiteneverfly at gmail.com  Sun Dec  6 04:39:19 2020
From: whosekiteneverfly at gmail.com (Yuji YAMAMOTO)
Date: Sun, 6 Dec 2020 13:39:19 +0900
Subject: [Haskell-cafe] Haskell on windows 7 without chocolatey?
In-Reply-To: <DM6PR03MB43312FFE3BA12800372083ABA1CF0@DM6PR03MB4331.namprd03.prod.outlook.com>
References: <CAAYKvumnuaCKwFcgfsAT08GByQWD6S_mSGVWyFqQ_g7xj=wjyQ@mail.gmail.com>
 <DM6PR03MB43312FFE3BA12800372083ABA1CF0@DM6PR03MB4331.namprd03.prod.outlook.com>
Message-ID: <CA+6J5GHuu5fWtOF2yHfLjkg4zdrNgBL=y=MkpRdvLhkJ0vgruA@mail.gmail.com>

Are you looking for this page?

https://www.haskell.org/ghc/download_ghc_8_10_2.html#windows64

The download URL
https://downloads.haskell.org/~ghc/8.10.2/ghc-8.10.2-x86_64-unknown-mingw32.tar.xz
is referred by the install script of Chocolatey.

2020年12月6日(日) 13:24 Gregory Guthrie <guthrie at miu.edu>:

> Same for W10 – PowerShell stops with some policy restrictions, and after a
> few gyrations – I wonder about a simpler method as in the past.
>
>
>
>
>
> Dr. Gregory Guthrie
>
> ----------------------------------------------------------------
>
>
>
> *From:* Haskell-Cafe <haskell-cafe-bounces at haskell.org> *On Behalf Of *Jim
> Blorg
> *Sent:* Saturday, December 5, 2020 9:26 PM
> *To:* haskell-cafe at haskell.org
> *Subject:* [Haskell-cafe] Haskell on windows 7 without chocolatey?
>
>
>
> Is there a way to install haskell on windows 7 manually via zip without
> all the requirements for scripting?
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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: https://twitter.com/igrep
GitHub: https://github.com/igrep
GitLab: https://gitlab.com/igrep
Facebook: http://www.facebook.com/igrep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201206/09b7ad15/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Mon Dec  7 13:23:13 2020
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 7 Dec 2020 14:23:13 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
	Haskell have?
Message-ID: <2337334d-68f6-aa38-9795-3755e4d7c641@htwk-leipzig.de>

>  very cool feature would be if I could select a program phrase
> and let it find /similar/ phrases, where a similarity metric
> could be edit-distance with respect to language tokens ...

I often wanted a tool that finds (nearly) duplicate AST sub-trees
in a large code base, and suggests refactorings.

Of course, in an IDE, it could alert me on-the-fly
that I'm typing some code that's already present elsewhere.

How might one go about implementing this?
Actual (approximate) sub-tree matching seems the easy part;
but I have no clear idea about whether this
should just use syntax, or needs types as well (my guess is: yes)
what libraries are there to provide the (annotated) ASTs, etc.

- J.W.

From dburke.gw at gmail.com  Mon Dec  7 13:32:32 2020
From: dburke.gw at gmail.com (Doug Burke)
Date: Mon, 7 Dec 2020 08:32:32 -0500
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <2337334d-68f6-aa38-9795-3755e4d7c641@htwk-leipzig.de>
References: <2337334d-68f6-aa38-9795-3755e4d7c641@htwk-leipzig.de>
Message-ID: <CALkjVLAcEGJLHV9PNESsuqWarbGXQ564zfJZB0k3uJ8cO8qXsQ@mail.gmail.com>

hlint does this to some extent (at least I have some copy-pasted code it
keeps on pleading me to remove duplication).

Doug

On Mon, Dec 7, 2020 at 8:24 AM Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> >  very cool feature would be if I could select a program phrase
> > and let it find /similar/ phrases, where a similarity metric
> > could be edit-distance with respect to language tokens ...
>
> I often wanted a tool that finds (nearly) duplicate AST sub-trees
> in a large code base, and suggests refactorings.
>
> Of course, in an IDE, it could alert me on-the-fly
> that I'm typing some code that's already present elsewhere.
>
> How might one go about implementing this?
> Actual (approximate) sub-tree matching seems the easy part;
> but I have no clear idea about whether this
> should just use syntax, or needs types as well (my guess is: yes)
> what libraries are there to provide the (annotated) ASTs, etc.
>
> - 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/20201207/6f1cb0d8/attachment.html>

From compl.yue at icloud.com  Mon Dec  7 13:45:19 2020
From: compl.yue at icloud.com (YueCompl)
Date: Mon, 7 Dec 2020 21:45:19 +0800
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CALkjVLAcEGJLHV9PNESsuqWarbGXQ564zfJZB0k3uJ8cO8qXsQ@mail.gmail.com>
References: <2337334d-68f6-aa38-9795-3755e4d7c641@htwk-leipzig.de>
 <CALkjVLAcEGJLHV9PNESsuqWarbGXQ564zfJZB0k3uJ8cO8qXsQ@mail.gmail.com>
Message-ID: <36AD6220-E974-44E0-B605-E9049C1EF301@icloud.com>

Speak of this detection by hlint, I can not figure out how I'm supposed to improve it for identical or nearly identical where clauses, e.g.

```log
Reduce duplication
Found:
	!eac = el'context eas
	diags = el'ctx'diags eac
	returnAsExpr = el'Exit eas exit $ EL'Expr xsrc

Why not:
  Combine with /xxx/Analyze.hs:741:7-27
hlint(Reduce duplication)
```

While yes, that's verbatim copy as of a where clause, but how to *combine* them?

```hs
    where
      !eac = el'context eas
      diags = el'ctx'diags eac
      returnAsExpr = el'Exit eas exit $ EL'Expr xsrc
```

Regards,
Compl


> On 2020-12-07, at 21:32, Doug Burke <dburke.gw at gmail.com> wrote:
> 
> 
> hlint does this to some extent (at least I have some copy-pasted code it keeps on pleading me to remove duplication).
> 
> Doug
> 
> On Mon, Dec 7, 2020 at 8:24 AM Johannes Waldmann <johannes.waldmann at htwk-leipzig.de <mailto:johannes.waldmann at htwk-leipzig.de>> wrote:
> >  very cool feature would be if I could select a program phrase
> > and let it find /similar/ phrases, where a similarity metric
> > could be edit-distance with respect to language tokens ...
> 
> I often wanted a tool that finds (nearly) duplicate AST sub-trees
> in a large code base, and suggests refactorings.
> 
> Of course, in an IDE, it could alert me on-the-fly
> that I'm typing some code that's already present elsewhere.
> 
> How might one go about implementing this?
> Actual (approximate) sub-tree matching seems the easy part;
> but I have no clear idea about whether this
> should just use syntax, or needs types as well (my guess is: yes)
> what libraries are there to provide the (annotated) ASTs, etc.
> 
> - 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 <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/20201207/28d31a9f/attachment.html>

From compl.yue at icloud.com  Mon Dec  7 14:09:25 2020
From: compl.yue at icloud.com (YueCompl)
Date: Mon, 7 Dec 2020 22:09:25 +0800
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell	have?
In-Reply-To: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
Message-ID: <48302E15-9F28-4031-A3B5-FFF506861134@icloud.com>

Some late, but I just remember that I'd been pondering with the idea that on foldable code regions (as VSCode / VisualStudio have implemented), some pragmas could better be used to specify relative font size and maybe even to shrink some regions into minified icons, then only expanded when clicked. 

I suggest this is valuable at times when corner case handling code grows much more verbose than the stem logic flow, as well as for boilerplate heavy codebases. The valuable attention of the reader should be firstly and foremost spent on stem logic flow, especially for newcomers to a large codebase, where bloated flow paths / regions can draw unreasonable amount of his/her attention.

Further more, the single source of actual syntax nodes, even cross scattered module files, could even be re-organized into multiple mission-specific views, serving different purposes such as quality-review, trouble-shooting, security auditing, impact-analysis (during refactoring), etc. etc.

Regards,
Compl


> On 2020-12-01, at 04:34, Gueven Bay via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
> Greetings,
> 
> Imagine that you can decide what functionality and features an
> Integrated Development Environment for Haskell should get. You can
> make this IDE with your wishlist similar in power as other IDEs for
> Java for example.
> 
> Now list as many features as you can, what would make the life of a
> Haskell developer as comfortable as possible!?
> 
> I am dying to know how this list of features at the end (of this
> thread) will look like.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 alexandre at moine.me  Mon Dec  7 14:33:37 2020
From: alexandre at moine.me (Alexandre Moine)
Date: Mon, 07 Dec 2020 14:33:37 +0000
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <2337334d-68f6-aa38-9795-3755e4d7c641@htwk-leipzig.de>
References: <2337334d-68f6-aa38-9795-3755e4d7c641@htwk-leipzig.de>
Message-ID: <baecac1e74bcffc1ace239cfe493403f@moine.me>

7 décembre 2020 14:25 "Johannes Waldmann" <johannes.waldmann at htwk-leipzig.de> a écrit:

> I often wanted a tool that finds (nearly) duplicate AST sub-trees
> in a large code base, and suggests refactorings.
> 
> Of course, in an IDE, it could alert me on-the-fly
> that I'm typing some code that's already present elsewhere.
> 
> How might one go about implementing this?
> Actual (approximate) sub-tree matching seems the easy part;
> but I have no clear idea about whether this
> should just use syntax, or needs types as well (my guess is: yes)
> what libraries are there to provide the (annotated) ASTs, etc.
> 
> - J.W.

Hi,

I developed last year a small tool for redundancy detection in OCaml called asak [1], which can be easily adapted for Haskell.

The idea is pretty simple: use an intermediate language of the compilation pipeline to normalize the code and remove sugar (for Haskell, one can take Core), inline everything, and hash the tree bottom-up (abstracting constants) keeping intermediates trees. Then you just compare hashs of trees against pre-computed hashs of, let's say, the whole Hackage ecosystem.

The technique is pretty efficient and scalable. I ran asak against the whole OPAM repository and got some results (like the detection of `map_opt` 140 times under 32 different names). There are some drawbacks: the code needs to be compiled down to Core and one has to maintain a database of available hashs, but the first one seems legitimate and the other inherent to any such tool.

I started developing a plugin editor for emacs, but never go further due to a lack of time.

Anyway, the approach is language-agnostic and could be easily adapted to Haskell. Moreover, I have an "inline everything" part which is not possible in OCaml (due to effects), and will be highly valuable in Haskell.

Best,

--
Alexandre Moine

[1]: https://github.com/nobrakal/asak

From simon at joyful.com  Mon Dec  7 19:18:14 2020
From: simon at joyful.com (Simon Michael)
Date: Mon, 7 Dec 2020 11:18:14 -0800
Subject: [Haskell-cafe] ANN: hledger-1.20
Message-ID: <9CCE70B1-975A-42D9-B474-43411DFFA329@joyful.com>

I'm pleased to announce hledger 1.20 ! Changes include:

- Strict mode
- check command
- rendering, speed, and valuation fixes.

https://hledger.org/release-notes has the full details.
Thanks to release contributors Stephen Morgan, Dmitry Astapov,
TANIGUCHI Kohei, and legrostdg.


hledger (http://hledger.org) is a robust, cross-platform, plain text
accounting tool, with command-line, terminal and web UIs. It is an
actively maintained, largely compatible reimplementation of Ledger CLI
with many improvements. You can use it to track money, time,
investments, cryptocurrencies, inventory and more.
See also the Plain Text Accounting site (http://plaintextaccounting.org).


http://hledger.org/download shows all the ways to install hledger on
mac, windows or unix (stack, cabal, brew, nix, CI binaries, your
package manager..). Or, run this bash script to install or upgrade to
the latest release:

$ curl -sO https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh
$ less hledger-install.sh   # security review
$ bash hledger-install.sh


New users, check out https://hledger.org/quickstart.

To get help, see http://hledger.org#help-feedback,
and join our chat channel via Freenode (#hledger, http://irc.hledger.org)
or Matrix (#freenode_#hledger:matrix.org, http://riot.hledger.org).
Beginners and experts, contributors, sponsors, and all feedback are most welcome!


Be safe and well,

-Simon


From andre at popovit.ch  Mon Dec  7 23:22:45 2020
From: andre at popovit.ch (=?UTF-8?Q?Andr=C3=A9_Popovitch?=)
Date: Mon, 7 Dec 2020 18:22:45 -0500
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
Message-ID: <CAKXguEnhOZ=EHrsoAgQg1wPBQF-GaefGZ1gAT25Yfsh_=eLG7A@mail.gmail.com>

One feature I've always wanted would be able to "manually inline" a
function. For example, if I have

    foo a = a + a
    bar = foo 3

I'd like to be able to right-click on the invocation of `foo` and select
some option to inline it, rewriting the file to read

    foo a = a + a
    bar = 3 + 3

I think this would make it simple to dive into an abstraction to see what's
really going on. For example, imagine a new user is confused by this
expression:

   Just 3 >> Just 4

They could right-click on `>>` to see that it is identical to:

    case Just 3 of
        Just _ -> Just 4
        Nothing -> Nothing


Which would allow them to easily see that this expression will always
evaluate to "Just 4" (and hopefully simplify it). Enlightened, they could
then hit ctrl-z to revert the code to its original state.

Haskell's purity and laziness makes it one of the only mainstream languages
where equational reasoning is really possible, so this feature would play
on Haskell's strengths and provide a feature that couldn't be replicated in
other languages' IDEs. It would also allow new users to more easily dive in
and understand certain abstractions (although how it would work in many
cases would be hard to determine).

On Mon, Nov 30, 2020 at 3:35 PM Gueven Bay via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Greetings,
>
> Imagine that you can decide what functionality and features an
> Integrated Development Environment for Haskell should get. You can
> make this IDE with your wishlist similar in power as other IDEs for
> Java for example.
>
> Now list as many features as you can, what would make the life of a
> Haskell developer as comfortable as possible!?
>
> I am dying to know how this list of features at the end (of this
> thread) will look like.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Andre Popovitch
989 627 4376
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201207/0578df1d/attachment.html>

From haskell-mail at maralorn.de  Tue Dec  8 00:34:05 2020
From: haskell-mail at maralorn.de (Malte Brandy)
Date: Tue, 8 Dec 2020 01:34:05 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CAKXguEnhOZ=EHrsoAgQg1wPBQF-GaefGZ1gAT25Yfsh_=eLG7A@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <CAKXguEnhOZ=EHrsoAgQg1wPBQF-GaefGZ1gAT25Yfsh_=eLG7A@mail.gmail.com>
Message-ID: <20201208003405.gah2hu7h2vaycth4@apollo>

Dear André,

On 20-12-07 18:22, André Popovitch wrote:
> One feature I've always wanted would be able to "manually inline" a
> function. For example, if I have
> 
>     foo a = a + a
>     bar = foo 3
> 
> I'd like to be able to right-click on the invocation of `foo` and select
> some option to inline it, rewriting the file to read
> 
>     foo a = a + a
>     bar = 3 + 3
> 
> I think this would make it simple to dive into an abstraction to see what's
> really going on. For example, imagine a new user is confused by this
> expression:
> 
>    Just 3 >> Just 4
> 
> They could right-click on `>>` to see that it is identical to:
> 
>     case Just 3 of
>         Just _ -> Just 4
>         Nothing -> Nothing
> 
> 
> Which would allow them to easily see that this expression will always
> evaluate to "Just 4" (and hopefully simplify it). Enlightened, they could
> then hit ctrl-z to revert the code to its original state.
> 
> Haskell's purity and laziness makes it one of the only mainstream languages
> where equational reasoning is really possible, so this feature would play
> on Haskell's strengths and provide a feature that couldn't be replicated in
> other languages' IDEs. It would also allow new users to more easily dive in
> and understand certain abstractions (although how it would work in many
> cases would be hard to determine).

I guess it's worth pointing out, that haskell-language-server (via using
retrie) has this feature since a few months. (At least in principle. I
personally haven‘t tested it much. But it hasn‘t failed me yet.)
The same also holds true for quite a number of the other wishes voiced
here.

Regards,
maralorn
-------------- 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/20201208/682afb02/attachment.sig>

From rae at richarde.dev  Tue Dec  8 03:50:30 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 8 Dec 2020 03:50:30 +0000
Subject: [Haskell-cafe] Help lead Haskell: Executive Director sought for
	Haskell Foundation
Message-ID: <010f01764078da35-f8ff6647-14b8-4af0-b45a-18a342697dd7-000000@us-east-2.amazonses.com>

Posting on behalf of the Haskell Foundation Working Group. Please forward widely!

--------

The Haskell Foundation is seeking an Executive Director. Please find the job description here: https://haskell.foundation/ <https://haskell.foundation/executive-director>ed-job-description <https://haskell.foundation/ed-job-description/>

The Haskell Foundation (HF) is an independent, non-profit organization dedicated to driving Haskell adoption and open-source development. 

HF seeks a full-time Executive Director (ED) to lead and develop the organization going forward. The ED is responsible for furthering the HF’s mission and vision, ensuring that resources are in place to accomplish its goals. The HF is supported by an active group of volunteers, and the ED will be a key focal point for that community, in addition to hiring support staff.

This is a salaried position. Salary will be commensurate with the experience, qualities, and location of the individual, and will also reflect the Foundation’s status as a non-profit organisation funded by donations.


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

From stefan.wehr at gmail.com  Tue Dec  8 08:55:07 2020
From: stefan.wehr at gmail.com (Stefan Wehr)
Date: Tue, 8 Dec 2020 09:55:07 +0100
Subject: [Haskell-cafe] Call for Participation: BOB 2021 (February 26, online,
 early-bird until Dec 31)
Message-ID: <CAJAdMdEa-sLSdfgFm9JVxs8gw+NVs4uTUHJXg+KVeLObnNkdzg@mail.gmail.com>

“What happens if we simply use what’s best?”

BOB Conference 2021
February 26, 2021, online (0100+UTC)
http://bobkonf.de/2021/

Program: http://bobkonf.de/2021/program.html
Registration: http://bobkonf.de/2021/registration.html
Keynote: Jeremy Gibbons

BOB conference is a place for developers, architects and decision-makers
to explore technologies beyond the mainstream in software development,
and to find the best tools available to software developers today. Our
goal is for all participants of BOB to return home with new insights
that enable them to improve their own software development
experience.

The program features 14 talks and 8 tutorials on current topics:

http://bobkonf.de/2021/program.html

The subject range includes functional programming, logic programming,
revision control, formal methods, mindfulness, event sourcing,
front-end development, and more.

Jeremy Gibbons will give the keynote talk.

BOB 2021 will take place online.  We are working towards fostering
lively exchange of exciting ideas and enable meaningful social
interactions.

Registration is open online:

http://bobkonf.de/2021/registration.html

The early-bird registration is €10 for a regular ticket, €5 for a
student ticket.  (If you need financial aid, let us know.)  We intend
to make this the most diverse, colorful, fun BOB ever!

NOTE: The early-bird rates expire on December 31, 2020!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201208/ca85415b/attachment.html>

From Andrew.Butterfield at scss.tcd.ie  Tue Dec  8 10:19:59 2020
From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield)
Date: Tue, 8 Dec 2020 10:19:59 +0000
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <CAKXguEnhOZ=EHrsoAgQg1wPBQF-GaefGZ1gAT25Yfsh_=eLG7A@mail.gmail.com>
References: <CAHonXRBYtyRtnWnw1Ah7WpKPNOJ86N728mgErs8gXUbL8atrxg@mail.gmail.com>
 <CAKXguEnhOZ=EHrsoAgQg1wPBQF-GaefGZ1gAT25Yfsh_=eLG7A@mail.gmail.com>
Message-ID: <BBF989D9-25F1-44AB-88D8-794B848E86BC@scss.tcd.ie>

That's an `iterate (+1)` from me!

I've just finished teaching my students about monads, and this facility would be really, really, useful....
(They're now engaged in a struggle with a monadic exercise ;-)

Regards,
  Andrew

> On 7 Dec 2020, at 23:22, André Popovitch <andre at popovit.ch> wrote:
> 
> One feature I've always wanted would be able to "manually inline" a function. For example, if I have
> 
>     foo a = a + a
>     bar = foo 3
> 
> I'd like to be able to right-click on the invocation of `foo` and select some option to inline it, rewriting the file to read 
> 
>     foo a = a + a
>     bar = 3 + 3
> 
> I think this would make it simple to dive into an abstraction to see what's really going on. For example, imagine a new user is confused by this expression:
>  
>    Just 3 >> Just 4
> 
> They could right-click on `>>` to see that it is identical to:
> 
>     case Just 3 of
>         Just _ -> Just 4
>         Nothing -> Nothing
> 
> 
> Which would allow them to easily see that this expression will always evaluate to "Just 4" (and hopefully simplify it). Enlightened, they could then hit ctrl-z to revert the code to its original state. 
> 
> Haskell's purity and laziness makes it one of the only mainstream languages where equational reasoning is really possible, so this feature would play on Haskell's strengths and provide a feature that couldn't be replicated in other languages' IDEs. It would also allow new users to more easily dive in and understand certain abstractions (although how it would work in many cases would be hard to determine).
> 
> On Mon, Nov 30, 2020 at 3:35 PM Gueven Bay via Haskell-Cafe <haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org>> wrote:
> Greetings,
> 
> Imagine that you can decide what functionality and features an
> Integrated Development Environment for Haskell should get. You can
> make this IDE with your wishlist similar in power as other IDEs for
> Java for example.
> 
> Now list as many features as you can, what would make the life of a
> Haskell developer as comfortable as possible!?
> 
> I am dying to know how this list of features at the end (of this
> thread) will look like.
> _______________________________________________
> 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.
> 
> 
> -- 
> Andre Popovitch
> 989 627 4376
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

--------------------------------------------------------------------
Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
Lero at TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
                         http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------

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

From P.Achten at cs.ru.nl  Tue Dec  8 15:59:06 2020
From: P.Achten at cs.ru.nl (Peter Achten)
Date: Tue, 8 Dec 2020 16:59:06 +0100
Subject: [Haskell-cafe] [TFP'21] second call for papers: Trends in
 Functional Programming 2021,
 18-19 February (online event with Lambda Days 2021 & TFPIE 2021)
Message-ID: <aab40092-d6f0-f441-b9bc-a55da08b8324@cs.ru.nl>

-------------------------------------------------------------------------
                      Second call for papers
         22nd Symposium on Trends in Functional Programming
                           tfp2021.org
-------------------------------------------------------------------------

Did you miss the deadline to submit a paper to Trends in Functional 
Programming
http://tfp2021.org/? No worries -- it's not too late!
Submission is open until January 15th 2021, for a presentation slot at 
the event
and post-symposium reviewing.

The symposium on Trends in Functional Programming (TFP) is an international
forum for researchers with interests in all aspects of functional 
programming,
taking a broad view of current and future trends in the area. It aspires 
to be
a lively environment for presenting the latest research results, and other
contributions.

* TFP offers a supportive reviewing process designed to help less 
experienced
   authors succeed, with two rounds of review, both before and after the
   symposium itself. Authors have an opportunity to address reviewers' 
concerns
   before final decisions on publication in the proceedings.

* TFP offers two "best paper" awards, the John McCarthy award for best 
paper,
   and the David Turner award for best student paper.

* TFP is co-located with Lambda Days in beautiful Krakow. Lambda Days is 
a vibrant
   developer conference with hundreds of attendees and a lively 
programme of talks on
   functional programming in practice. Due to the covid pandemic, the 
event is online
   with a lot of attention to interaction and getting to socialize with 
the community.


Important Dates
---------------

Submission deadline for pre-symposium review:   20th November, 2020  -- 
passed --
Submission deadline for draft papers:           15th January, 2021
Symposium dates:                                18-19th February, 2021

Visit http://tfp2021.org/ for more information.


From blamario at rogers.com  Tue Dec  8 18:16:09 2020
From: blamario at rogers.com (Mario)
Date: Tue, 8 Dec 2020 13:16:09 -0500
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <387165f3b38988de076a34462a1b9e61@jackkelly.name>
References: <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
Message-ID: <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>

On 2020-12-05 7:04 p.m., Jack Kelly via Haskell-Cafe wrote:
> Dunno what the answer is, but I wanted to flag it while your package is young and breaking changes are easy. I've been meaning to have a crack at moving the reflex patch-verse over to monoid-subclasses ( https://hackage.haskell.org/package/monoid-subclasses ), which I provides some the necessary tools with different names (patch reinvents MonoidNull, and I'm hoping that a subtraction-that-removes keys could be lawful for one of the Reductive/Cancellative classes).


I'm the author and maintainer of monoid-subclasses, and I'd accept a PR 
that adds InverseSemigroup without overly disturbing the existing 
classes. The whole purpose of the package, after all, is to support 
mathematical abstractions that are richer than semigroups but are not 
proper groups.



From olf at aatal-apotheke.de  Tue Dec  8 20:36:35 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Tue, 08 Dec 2020 21:36:35 +0100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
Message-ID: <b735a93c866e99e3395795b5a3292fafa56a4da4.camel@aatal-apotheke.de>

On 20-12-07 18:22, André Popovitch wrote:
> One feature I've always wanted would be able to "manually inline" a
> function. For example, if I have
> 
>     foo a = a + a
>     bar = foo 3
> 
> I'd like to be able to right-click on the invocation of `foo` and
> select
> some option to inline it, rewriting the file to read
> 
>     foo a = a + a
>     bar = 3 + 3
> 
> I think this would make it simple to dive into an abstraction to see
> what's
> really going on. For example, imagine a new user is confused by this
> expression:
> 
>    Just 3 >> Just 4
> 
> They could right-click on `>>` to see that it is identical to:
> 
>     case Just 3 of
>         Just _ -> Just 4
>         Nothing -> Nothing
> 
> 
> Which would allow them to easily see that this expression will always
> evaluate to "Just 4" (and hopefully simplify it). Enlightened, they
> could
> then hit ctrl-z to revert the code to its original state.
> 
> Haskell's purity and laziness makes it one of the only mainstream
> languages
> where equational reasoning is really possible, so this feature would
> play
> on Haskell's strengths and provide a feature that couldn't be
> replicated in
> other languages' IDEs. It would also allow new users to more easily
> dive in
> and understand certain abstractions (although how it would work in
> many
> cases would be hard to determine).

+1 for this. It is like a step-by-step evaluation/debugger but limited
to function calls at the syntactic level. I can image so many past
situations where this would have prevented lots of head-scratching. 
This hypothetical IDE feature might go well with a tree view where
inlining a function application is equivalent to expanding a level in a
tree (within the same source line number), like so:

Folded: [+] button appears on mouse over "foo".
   bar = foo[+] 3

Expanded: One code line now occupies two lines in the IDE window. [-]
button reverts code to previous state.
   bar = foo 3
         [-] 3 + 3

I've seen similar things in action in a demo implementation of [1,2].
Also great for teaching, I guess. 

Olaf

[1] https://www.cs.bham.ac.uk/~pbl/papers/functionalexplainsupp.pdf
[2] https://dl.acm.org/doi/10.1145/3110258


From jack at jackkelly.name  Wed Dec  9 10:43:37 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Wed, 09 Dec 2020 10:43:37 GMT
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
References: <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
Message-ID: <28c31eb62a34479f226e64adebcac70d@jackkelly.name>


December 9, 2020 4:16 AM, "Mario" <blamario at rogers.com> wrote:

> On 2020-12-05 7:04 p.m., Jack Kelly via Haskell-Cafe wrote:
> 
>> Dunno what the answer is, but I wanted to flag it while your package is young and breaking changes
>> are easy. I've been meaning to have a crack at moving the reflex patch-verse over to
>> monoid-subclasses ( https://hackage.haskell.org/package/monoid-subclasses ), which I provides some
>> the necessary tools with different names (patch reinvents MonoidNull, and I'm hoping that a
>> subtraction-that-removes keys could be lawful for one of the Reductive/Cancellative classes).
> 
> I'm the author and maintainer of monoid-subclasses, and I'd accept a PR that adds InverseSemigroup
> without overly disturbing the existing classes. The whole purpose of the package, after all, is to
> support mathematical abstractions that are richer than semigroups but are not proper groups.

Thanks for the offer. There are two things I want to sort out first:

1. I may have erred when suggesting InverseSemigroup; "inverting" a `Group g => Map k g` via `fmap invert` might admit nonunique inverses, which gives you an even weaker structure called a Regular Semigroup.

2. I want to see if I can make the behaviour I want fit the existing classes provided by `monoid-subclasses` (specifically `Cancellative` and maybe `Reductive` instances for types provided by `monoidal-containers`). It might be something like `instance (MonoidNull g, Group g, Commutative g, Ord k) => Reductive (MonoidalMap k g)`, where the reduction operation subtracts values at matching keys, pruning nulls. I need to at least write out the property tests to see if it might be sound.

Best,

-- Jack

From emilypi at cohomolo.gy  Wed Dec  9 19:05:59 2020
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Wed, 09 Dec 2020 19:05:59 +0000
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
References: <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
Message-ID: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>

Okay, I'm fully caffeinated and out of bed.

Correct me if I'm wrong here, because I've never seen anyone describe maps like this, but it seems to me that for an algebraic constraint `c`, `c g ⇒ Map k g` would be a `k`-graded c-structure, and we can think of algebraic operations applied to those `g` meaningfully in that sense. For example, an indexed-list where `Group a ⇒ [(Int, a)]` can be seen as a ℤ-graded group.

In your example, Jack, inversion is defined on a map by `fmap inverse ≣ inverse_k0 + inverse_k1 + … + inverse k_n`, componentwise for each key. So perhaps your problem here for maps, is equivalent to finding a nice indexed-group for structure for the types:

```

— | A functor indexed by a discrete category. Not to be confused with

-- indexed as in higher functor on functor ala Atkey's Outrageous Fortune.

— This is not the most general encoding.

—

class GradedFunctor f where

imap :: (i → a → b) → f i a → f i b

— Being a graded group requires that the "overall" structure be both an indexed functor,

— as well as a group, so that `t i g = g_i0 + … + giN` forms a group as well.

—
class (GradedFunctor t, Group (t i g), Group g)  ⇒ GradedGroup t i g where

ixinvert :: i→ t i g → t i g

```

Something along those lines.

Thoughts? I'm spitballing here.

Cheers,

Emily

On Wed, Dec 09, 2020 at 5:43 AM, < jack at jackkelly.name > wrote:

> 
> 
> 
> December 9, 2020 4:16 AM, "Mario" < blamario@ rogers. com (
> blamario at rogers.com ) > wrote:
> 
> 
>> 
>> 
>> On 2020-12-05 7:04 p.m., Jack Kelly via Haskell-Cafe wrote:
>> 
>> 
>>> 
>>> 
>>> Dunno what the answer is, but I wanted to flag it while your package is
>>> young and breaking changes are easy. I've been meaning to have a crack at
>>> moving the reflex patch-verse over to monoid-subclasses ( https:/ / hackage.
>>> haskell. org/ package/ monoid-subclasses (
>>> https://hackage.haskell.org/package/monoid-subclasses ) ), which I provides
>>> some the necessary tools with different names (patch reinvents MonoidNull,
>>> and I'm hoping that a subtraction-that-removes keys could be lawful for
>>> one of the Reductive/Cancellative classes).
>>> 
>>> 
>> 
>> 
>> 
>> I'm the author and maintainer of monoid-subclasses, and I'd accept a PR
>> that adds InverseSemigroup without overly disturbing the existing classes.
>> The whole purpose of the package, after all, is to support mathematical
>> abstractions that are richer than semigroups but are not proper groups.
>> 
>> 
> 
> 
> 
> Thanks for the offer. There are two things I want to sort out first:
> 
> 
> 
> 1. I may have erred when suggesting InverseSemigroup; "inverting" a `Group
> g => Map k g` via `fmap invert` might admit nonunique inverses, which
> gives you an even weaker structure called a Regular Semigroup.
> 
> 
> 
> 2. I want to see if I can make the behaviour I want fit the existing
> classes provided by `monoid-subclasses` (specifically `Cancellative` and
> maybe `Reductive` instances for types provided by `monoidal-containers`).
> It might be something like `instance (MonoidNull g, Group g, Commutative
> g, Ord k) => Reductive (MonoidalMap k g)`, where the reduction operation
> subtracts values at matching keys, pruning nulls. I need to at least write
> out the property tests to see if it might be sound.
> 
> 
> 
> Best,
> 
> 
> 
> -- Jack
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201209/ee9da17d/attachment.html>

From fumiexcel at gmail.com  Thu Dec 10 02:06:27 2020
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Thu, 10 Dec 2020 11:06:27 +0900
Subject: [Haskell-cafe] Enable -Wall by default?
Message-ID: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>

I mean literally. An article [0] reminded me of the fact that I enable
-Wall in 99% of time -- and most packages I use have it enabled too.
It's well known that -Wall doesn't enable* all *warnings, but a subset of
warnings that

* are well accepted by the community
* rarely produce false positives

Well, they look like good reasons to enable the warnings by default. Same
goes for -Wcompat, except that it is not as popular as -Wall. Seeing
potential problems when compiling code is far less of a pain than leaving
breakages unnoticed.

Am I missing some obvious reason not to do this?

[0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201210/dc87add6/attachment.html>

From david.feuer at gmail.com  Thu Dec 10 02:23:34 2020
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 9 Dec 2020 21:23:34 -0500
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
Message-ID: <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>

Yeah, I think you're missing something. -Wall is great for checking code
that's supposed to be "production ready", but it makes some pretty annoying
noise when you're deep in development. Probably the most annoying in that
context are unused binding warnings (yeah, I'm not using it yet because I'm
still writing it and/or other helpers), unused variable warnings (yeah,
that'll be used in some case I still need to write), and unused imports
(yeah, I've temporarily commented out the code that uses Foo, and I'm
pretty sure I'll be needing Bar before I'm done). In that setting, I'm much
more likely to want -Wincomplete-patterns (what do I still need to write)
and maybe -Wname-shadowing (so I won't have to go back and change a bunch
of names later) than full -Wall.

On Wed, Dec 9, 2020, 9:06 PM Fumiaki Kinoshita <fumiexcel at gmail.com> wrote:

> I mean literally. An article [0] reminded me of the fact that I enable
> -Wall in 99% of time -- and most packages I use have it enabled too.
> It's well known that -Wall doesn't enable* all *warnings, but a subset of
> warnings that
>
> * are well accepted by the community
> * rarely produce false positives
>
> Well, they look like good reasons to enable the warnings by default. Same
> goes for -Wcompat, except that it is not as popular as -Wall. Seeing
> potential problems when compiling code is far less of a pain than leaving
> breakages unnoticed.
>
> Am I missing some obvious reason not to do this?
>
> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201209/ef8f6eea/attachment.html>

From fumiexcel at gmail.com  Thu Dec 10 04:57:05 2020
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Thu, 10 Dec 2020 13:57:05 +0900
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
Message-ID: <CAATCwU=EVp-t2jox+R91zn5E5CX5GtC8-0UAVguDHdnL-gZwZA@mail.gmail.com>

I've been pretty comfortable with using -Wall from the beginning, but I see
the point. I think -Wall is still a good reminder to fix unused bindings,
imports etc.
How about having a flag that disables those warnings while in early
development? That would serve as a more explicit WIP marker.

2020年12月10日(木) 11:23 David Feuer <david.feuer at gmail.com>:

> Yeah, I think you're missing something. -Wall is great for checking code
> that's supposed to be "production ready", but it makes some pretty annoying
> noise when you're deep in development. Probably the most annoying in that
> context are unused binding warnings (yeah, I'm not using it yet because I'm
> still writing it and/or other helpers), unused variable warnings (yeah,
> that'll be used in some case I still need to write), and unused imports
> (yeah, I've temporarily commented out the code that uses Foo, and I'm
> pretty sure I'll be needing Bar before I'm done). In that setting, I'm much
> more likely to want -Wincomplete-patterns (what do I still need to write)
> and maybe -Wname-shadowing (so I won't have to go back and change a bunch
> of names later) than full -Wall.
>
> On Wed, Dec 9, 2020, 9:06 PM Fumiaki Kinoshita <fumiexcel at gmail.com>
> wrote:
>
>> I mean literally. An article [0] reminded me of the fact that I enable
>> -Wall in 99% of time -- and most packages I use have it enabled too.
>> It's well known that -Wall doesn't enable* all *warnings, but a subset
>> of warnings that
>>
>> * are well accepted by the community
>> * rarely produce false positives
>>
>> Well, they look like good reasons to enable the warnings by default. Same
>> goes for -Wcompat, except that it is not as popular as -Wall. Seeing
>> potential problems when compiling code is far less of a pain than leaving
>> breakages unnoticed.
>>
>> Am I missing some obvious reason not to do this?
>>
>> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20201210/af982362/attachment.html>

From ietf-dane at dukhovni.org  Thu Dec 10 05:16:41 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Dec 2020 00:16:41 -0500
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
Message-ID: <X9GvOeKhR9PdZZrC@straasha.imrryr.org>

On Wed, Dec 09, 2020 at 09:23:34PM -0500, David Feuer wrote:

> Yeah, I think you're missing something. -Wall is great for checking code
> that's supposed to be "production ready", but it makes some pretty annoying
> noise when you're deep in development. Probably the most annoying in that
> context are unused binding warnings (yeah, I'm not using it yet because I'm
> still writing it and/or other helpers), unused variable warnings (yeah,
> that'll be used in some case I still need to write), and unused imports
> (yeah, I've temporarily commented out the code that uses Foo, and I'm
> pretty sure I'll be needing Bar before I'm done). In that setting, I'm much
> more likely to want -Wincomplete-patterns (what do I still need to write)
> and maybe -Wname-shadowing (so I won't have to go back and change a bunch
> of names later) than full -Wall.

But since the proposal is about *defaults*, and a hypothetical
*default* "-Wall" can be explicitly disabled:

    $ ghci -Wall
    λ> foo :: Bool -> Int ; foo True = 1

    <interactive>:1:22: warning: [-Wincomplete-patterns]
        Pattern match(es) are non-exhaustive
        In an equation for ‘foo’: Patterns not matched: False
    λ>
    Leaving GHCi.

    ---

    $ ghci -Wall -Wno-all
    λ> foo :: Bool -> Int ; foo True = 1
    λ>
    Leaving GHCi.

the objections you raised don't necessarily rule the proposed default,
one would just need choose to use "-Wno-all" initially, and then later
turn it off.  

A more serious compatibility break would perhaps happen when one
specifies "-Werror", perhaps in combination with specific warnings to
enforce:

    $ ghci -Wall -Werror -Wno-all
    λ> 1 + 2
    3
    λ> foo :: Bool -> Int ; foo True = 1
    λ>
    Leaving GHCi.

    ---

    $ ghci -Wall -Werror
    λ> foo :: Bool -> Int ; foo True = 1

    <interactive>:1:22: error: [-Wincomplete-patterns, -Werror=incomplete-patterns]
        Pattern match(es) are non-exhaustive
        In an equation for ‘foo’: Patterns not matched: False
    λ> 1 + 2

    <interactive>:2:1: error: [-Wtype-defaults, -Werror=type-defaults]
        • Defaulting the following constraints to type ‘Integer’
            (Show a0) arising from a use of ‘print’ at <interactive>:2:1-5
            (Num a0) arising from a use of ‘it’ at <interactive>:2:1-5
        • In a stmt of an interactive GHCi command: print it
    λ>
    Leaving GHCi.

Here, adding an implicit "-Wall" stops code from compiling.  So
backwards-compatible behaviour might require "-Wall" to be explicit when
"-Werror" is specified.

Since my examples are using "ghci", I should note that for me, in
"ghci", I typically want no warnings, and "-Wall" would be a bit
of a nuisance.  But I can always alias (bash):
    
    ghci() { command ghci -v0 -Wno-all "$@"; }

And then no longer see the mostly pedantic "defaulting" warnings, or
whatever else gets in the way of quickly syntax-checking or evaluating
an expression.

-- 
    Viktor.

From godzbanebane at gmail.com  Thu Dec 10 07:50:41 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Thu, 10 Dec 2020 09:50:41 +0200
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
Message-ID: <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>

For me, the default is -Wall and the "production" version is also turning
on -Werror.

I'm +1 on this.

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

From kindaro at gmail.com  Thu Dec 10 11:23:42 2020
From: kindaro at gmail.com (Ignat Insarov)
Date: Thu, 10 Dec 2020 16:23:42 +0500
Subject: [Haskell-cafe] Do something about Cabal?
Message-ID: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>

# Do something about Cabal?

Hello.

Cabal is the second most used tool in Haskell after GHC. It has many
problems. It may be noticed that there is one and a half developers working on
it. This is clearly not enough to address these problems. I propose that this is
a good place to invest in.

### Problems I have in mind:

* Poor communication, lack of open source development process.

  The whole Cabal–Stack schism appears to be an outcome of poor
  communication. One of the leading developers of Cabal is even banned from
  participation somewhere in Stack circles.[1] Personally, I reported several
  issues to Cabal and every single time it resulted in sadness. Observe a
  vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
  there are fewer contributors ⇒ core developers are overworked.

  I have no hard evidence but it appears that presently, more people that strive
  to improve the Haskell build experience are outside the Cabal cabal than are
  inside.

* User experience is an afterthought.

  Cabal's user experience is horrifying. A collection of complaints is being
  compiled elsewhere.[2] There are also bugs being opened to Cabal because of
  this, requiring triage and therefore wasting the precious time of the few
  overworked developers. Stack is much more friendly — this shows by example
  that the user experience problem is not inherent and may be solved.

  It is ordinary to receive output like this:

  ```
  % cabal run example-executable
  Warning: The package list for 'hackage.haskell.org' is 84 days old.
  Run 'cabal update' to get the latest list of available packages.
  Resolving dependencies...
  cabal: Could not resolve dependencies:
  [__0] trying: example-0.1.0.6 (user goal)
  [__1] next goal: opaleye (dependency of example)
  [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
  config TODO requires ==0.6.7006.1)
  [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
  [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
  opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
  opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
  opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
  opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
  opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
  opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
  opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
  previous version to fail: excluded by constraint '^>=0.7' from example)
  [__1] fail (backjumping, conflict set: example, opaleye)
  After searching the rest of the dependency tree exhaustively, these were the
  goals I've had most trouble fulfilling: opaleye, example
  ```

  There are so many things that are wrong here. Even a sneaky _«to do»_
  remark. If you wonder, in this case the solution is to remove and re-generate
  `cabal.project.freeze`.

  Even the name of the program — it is actually _«cabal-install»_ — is
  incomprehensible, it should be re-branded to Cabal, which is how everyone
  calls it anyway.

* Features are not being introduced.

  There is no reason for two build tools to exist. The killer feature of Stack —
  snapshots — should be supported by Cabal. Possibly Cabal itself should be
  refactored and split so that there are separate tools for packaging, version
  resolution and human interaction — I do not know. But certainly the way things
  are presently is a waste of developer effort and a source of confusion for
  everyone.

### My proposition, in particular.

* Ask all the people that show compassion to the cause of a great Haskell build
  tool to unite and work together on a better Cabal. This includes the
  developers of Stack and everyone that expressed unhappiness with the current
  state of Cabal. These people should be seen as a blessing, not as an obstacle.
* Put in place a clear process for contributing and decision making, so that it
  does not come down to the privileged opinion of one of the core developers.
* Make a model of user experience that Cabal should conform to, and make
  conformance a priority. Surely there are among us people that know a thing or
  two about user experience — call for them to step forward. Every issue that
  stems from misunderstanding, re-assign to the model instead of closing.
* Merge the support of Stackage snapshots into Cabal. Ask the core developers of
  Stack to join the effort. Transition from Stack to Cabal should be one well
  discoverable command that just works.

I realize that this letter is largely an opinion piece. You can also see it as
an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
present. I do not insist that my vision is the best. But the present reality is
not the best vision either. I propose, foremost, that we work and fight for a
better future.

[1]: https://github.com/commercialhaskell/stackage/issues/4472
[2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal

From chilledfrogs at disroot.org  Thu Dec 10 11:42:15 2020
From: chilledfrogs at disroot.org (Allen Sobot)
Date: Thu, 10 Dec 2020 12:42:15 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
Message-ID: <67B43049-BDF9-4F4F-8C76-E484D8C8CFDF@disroot.org>

As a still (very) new Haskell user by many measures, indeed the little experience I had with Cabal isn't great overall in my view (honestly not a fan of Stack grabbing separate GHC instances though either unless I pass like 2 command-line flags, if there's a configuration option I'm not aware of I'd be grateful).

I had no clue about the communication issues etc. plaguing Cabal, that explains a bit...

In any case I'd like to try to contribute what I can to this effort, mainly to improve the UX which I agree is absolutely terrible in my humble opinion.

(Side note: I was informed on another mailing list that I may have some setting pertaining to forcing some kind of read receipt which is considered impolite on mailing lists, if this is still the case I apologize and I'm trying to determine what even is the precise issue or setting controlling it, at least on K-9 Mail and Neomutt)

On December 10, 2020 12:23:42 p.m. GMT+01:00, Ignat Insarov <kindaro at gmail.com> wrote:
># Do something about Cabal?
>
>Hello.
>
>Cabal is the second most used tool in Haskell after GHC. It has many
>problems. It may be noticed that there is one and a half developers working on
>it. This is clearly not enough to address these problems. I propose that this is
>a good place to invest in.
>
>### Problems I have in mind:
>
>* Poor communication, lack of open source development process.
>
>  The whole Cabal–Stack schism appears to be an outcome of poor
>  communication. One of the leading developers of Cabal is even banned from
>  participation somewhere in Stack circles.[1] Personally, I reported several
>  issues to Cabal and every single time it resulted in sadness. Observe a
>  vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
>  there are fewer contributors ⇒ core developers are overworked.
>
>  I have no hard evidence but it appears that presently, more people that strive
>  to improve the Haskell build experience are outside the Cabal cabal than are
>  inside.
>
>* User experience is an afterthought.
>
>  Cabal's user experience is horrifying. A collection of complaints is being
>  compiled elsewhere.[2] There are also bugs being opened to Cabal because of
>  this, requiring triage and therefore wasting the precious time of the few
>  overworked developers. Stack is much more friendly — this shows by example
>  that the user experience problem is not inherent and may be solved.
>
>  It is ordinary to receive output like this:
>
>  ```
>  % cabal run example-executable
>  Warning: The package list for 'hackage.haskell.org' is 84 days old.
>  Run 'cabal update' to get the latest list of available packages.
>  Resolving dependencies...
>  cabal: Could not resolve dependencies:
>  [__0] trying: example-0.1.0.6 (user goal)
>  [__1] next goal: opaleye (dependency of example)
>  [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
>  config TODO requires ==0.6.7006.1)
>  [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
>  [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
>  opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
>  opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
>  opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
>  opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
>  opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
>  opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
>  opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
>  previous version to fail: excluded by constraint '^>=0.7' from example)
>  [__1] fail (backjumping, conflict set: example, opaleye)
>  After searching the rest of the dependency tree exhaustively, these were the
>  goals I've had most trouble fulfilling: opaleye, example
>  ```
>
>  There are so many things that are wrong here. Even a sneaky _«to do»_
>  remark. If you wonder, in this case the solution is to remove and re-generate
>  `cabal.project.freeze`.
>
>  Even the name of the program — it is actually _«cabal-install»_ — is
>  incomprehensible, it should be re-branded to Cabal, which is how everyone
>  calls it anyway.
>
>* Features are not being introduced.
>
>  There is no reason for two build tools to exist. The killer feature of Stack —
>  snapshots — should be supported by Cabal. Possibly Cabal itself should be
>  refactored and split so that there are separate tools for packaging, version
>  resolution and human interaction — I do not know. But certainly the way things
>  are presently is a waste of developer effort and a source of confusion for
>  everyone.
>
>### My proposition, in particular.
>
>* Ask all the people that show compassion to the cause of a great Haskell build
>  tool to unite and work together on a better Cabal. This includes the
>  developers of Stack and everyone that expressed unhappiness with the current
>  state of Cabal. These people should be seen as a blessing, not as an obstacle.
>* Put in place a clear process for contributing and decision making, so that it
>  does not come down to the privileged opinion of one of the core developers.
>* Make a model of user experience that Cabal should conform to, and make
>  conformance a priority. Surely there are among us people that know a thing or
>  two about user experience — call for them to step forward. Every issue that
>  stems from misunderstanding, re-assign to the model instead of closing.
>* Merge the support of Stackage snapshots into Cabal. Ask the core developers of
>  Stack to join the effort. Transition from Stack to Cabal should be one well
>  discoverable command that just works.
>
>I realize that this letter is largely an opinion piece. You can also see it as
>an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
>present. I do not insist that my vision is the best. But the present reality is
>not the best vision either. I propose, foremost, that we work and fight for a
>better future.
>
>[1]: https://github.com/commercialhaskell/stackage/issues/4472
>[2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
>_______________________________________________
>Haskell-Cafe mailing list
>To (un)subscribe, modify options or view 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 fa-ml at ariis.it  Thu Dec 10 13:16:44 2020
From: fa-ml at ariis.it (Francesco Ariis)
Date: Thu, 10 Dec 2020 14:16:44 +0100
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
Message-ID: <20201210131644.GC902@extensa>

Il 10 dicembre 2020 alle 16:23 Ignat Insarov via hf-discuss ha scritto:
> * User experience is an afterthought.
>  […]
> * Features are not being introduced.

I am not a power user, but in the last years — from the
introduction of new- commands — I have enjoyed using cabal very much.
Also each time I download a new version I see small little things added
(a working v2-install, projects, etc.) and updated documentation.

>   There is no reason for two build tools to exist. The killer feature of Stack —
>   snapshots — should be supported by Cabal.

As far as I know, this is already possible today! [1]

>   Personally, I reported several
>   issues to Cabal and every single time it resulted in sadness.

The few time I interacted with cabal/hackage developers — admittedly for
low-complexity issues — they were helpful. In one case some prodding was
necessary (and way less than e.g. with my bank, a service I pay for)
—F

[1] https://github.com/fpco/stackage-server/issues/232
    see also https://github.com/erikd/jenga/
             https://hackage.haskell.org/package/stack2cabal

From compl.yue at icloud.com  Thu Dec 10 13:46:59 2020
From: compl.yue at icloud.com (YueCompl)
Date: Thu, 10 Dec 2020 21:46:59 +0800
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
Message-ID: <DA7649CD-7129-4C12-8AE4-F5A92EE44B67@icloud.com>

Personally, when working with Haskell, I miss very much the Gophers' pragmatic attitude in building projects from source, the redundancy of specifications is reduced to extreme where possible, then you usually only need to care about each individual source file. Even with recent [Go Modules](https://golang.org/ref/mod <https://golang.org/ref/mod>) mechanism, the norm is to edit source files then your `go.mod` file is maintained by tools automatically, you can fix it when auto-updates went wrong, but never have to maintain it yourself. Cabal's principle seems rather cautious in comparison, it worries about you be making mistakes to mis-express your intention by accident, so require warrant of your actions by supplying consistent information allover different places with possibly multiple pieces of submission containing redundant information. It is crucial to need 2 (or more) keys for a nuclear weapon launching panel to be triggerable, but building a project? I think we can take that a lot easier.

I suppose the really hard part of a modern build system is neither compiling/linking nor even project local dependency anymore, it is management of external dependencies now. I'm happy to see Cabal v2 took Nix as the example to follow, but yet there are still huge spaces for improvement in ergonomics respects. I don't expect Haskell/GHC to be that popular like JavaScript/NodeJS, [npm](https://www.npmjs.com/ <https://www.npmjs.com/>) in a sense may be too successful in ergonomics, that local disk capacity of a developer's machine becomes the sole bottleneck, but there are things definitely improvable after Nix style building modes, so I anticipate a Cabal v3 sooner than later.

Sincerely,
Compl


> On 2020-12-10, at 19:23, Ignat Insarov <kindaro at gmail.com> wrote:
> 
> # Do something about Cabal?
> 
> Hello.
> 
> Cabal is the second most used tool in Haskell after GHC. It has many
> problems. It may be noticed that there is one and a half developers working on
> it. This is clearly not enough to address these problems. I propose that this is
> a good place to invest in.
> 
> ### Problems I have in mind:
> 
> * Poor communication, lack of open source development process.
> 
>  The whole Cabal–Stack schism appears to be an outcome of poor
>  communication. One of the leading developers of Cabal is even banned from
>  participation somewhere in Stack circles.[1] Personally, I reported several
>  issues to Cabal and every single time it resulted in sadness. Observe a
>  vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
>  there are fewer contributors ⇒ core developers are overworked.
> 
>  I have no hard evidence but it appears that presently, more people that strive
>  to improve the Haskell build experience are outside the Cabal cabal than are
>  inside.
> 
> * User experience is an afterthought.
> 
>  Cabal's user experience is horrifying. A collection of complaints is being
>  compiled elsewhere.[2] There are also bugs being opened to Cabal because of
>  this, requiring triage and therefore wasting the precious time of the few
>  overworked developers. Stack is much more friendly — this shows by example
>  that the user experience problem is not inherent and may be solved.
> 
>  It is ordinary to receive output like this:
> 
>  ```
>  % cabal run example-executable
>  Warning: The package list for 'hackage.haskell.org' is 84 days old.
>  Run 'cabal update' to get the latest list of available packages.
>  Resolving dependencies...
>  cabal: Could not resolve dependencies:
>  [__0] trying: example-0.1.0.6 (user goal)
>  [__1] next goal: opaleye (dependency of example)
>  [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
>  config TODO requires ==0.6.7006.1)
>  [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
>  [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
>  opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
>  opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
>  opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
>  opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
>  opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
>  opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
>  opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
>  previous version to fail: excluded by constraint '^>=0.7' from example)
>  [__1] fail (backjumping, conflict set: example, opaleye)
>  After searching the rest of the dependency tree exhaustively, these were the
>  goals I've had most trouble fulfilling: opaleye, example
>  ```
> 
>  There are so many things that are wrong here. Even a sneaky _«to do»_
>  remark. If you wonder, in this case the solution is to remove and re-generate
>  `cabal.project.freeze`.
> 
>  Even the name of the program — it is actually _«cabal-install»_ — is
>  incomprehensible, it should be re-branded to Cabal, which is how everyone
>  calls it anyway.
> 
> * Features are not being introduced.
> 
>  There is no reason for two build tools to exist. The killer feature of Stack —
>  snapshots — should be supported by Cabal. Possibly Cabal itself should be
>  refactored and split so that there are separate tools for packaging, version
>  resolution and human interaction — I do not know. But certainly the way things
>  are presently is a waste of developer effort and a source of confusion for
>  everyone.
> 
> ### My proposition, in particular.
> 
> * Ask all the people that show compassion to the cause of a great Haskell build
>  tool to unite and work together on a better Cabal. This includes the
>  developers of Stack and everyone that expressed unhappiness with the current
>  state of Cabal. These people should be seen as a blessing, not as an obstacle.
> * Put in place a clear process for contributing and decision making, so that it
>  does not come down to the privileged opinion of one of the core developers.
> * Make a model of user experience that Cabal should conform to, and make
>  conformance a priority. Surely there are among us people that know a thing or
>  two about user experience — call for them to step forward. Every issue that
>  stems from misunderstanding, re-assign to the model instead of closing.
> * Merge the support of Stackage snapshots into Cabal. Ask the core developers of
>  Stack to join the effort. Transition from Stack to Cabal should be one well
>  discoverable command that just works.
> 
> I realize that this letter is largely an opinion piece. You can also see it as
> an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
> present. I do not insist that my vision is the best. But the present reality is
> not the best vision either. I propose, foremost, that we work and fight for a
> better future.
> 
> [1]: https://github.com/commercialhaskell/stackage/issues/4472
> [2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201210/9e5ad018/attachment.html>

From kindaro at gmail.com  Thu Dec 10 14:06:31 2020
From: kindaro at gmail.com (Ignat Insarov)
Date: Thu, 10 Dec 2020 19:06:31 +0500
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <20201210131644.GC902@extensa>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
Message-ID: <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>

Thanks Francesco. I have also been using Cabal since a long time ago.
There is no question that some great things get done in Cabal. Mostly,
Cabal does what it says on the box, and this is why I propose to
improve it and not, say, move to Stack. But you may see that many
people prefer the latter — this seems even more weird since, as you
illuminate, Cabal can already interoperate with Stackage, so it is
strictly more featureful. _(As far as I follow, Stack still has poor
support for Backpack and sub-package build targets.)_

However, even in the light of the links you provide, we still cannot
say that Cabal supports Stackage. You say:

> >   There is no reason for two build tools to exist. The killer feature of Stack —
> >   snapshots — should be supported by Cabal.
>
> As far as I know, this is already possible today! [1]
>
> [1] https://github.com/fpco/stackage-server/issues/232
>     see also https://github.com/erikd/jenga/
>              https://hackage.haskell.org/package/stack2cabal

Heading to that link, the closing message says:

> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.

So, something is not working. Reading in more detail, there is
evidently a disagreement between the core developers of Cabal and
Stack. And as I understand, it has not been addressed ever since! This
is exactly an example of the kind of communication problems that I
alluded to in my first letter. Also, as far as I can see, there has
been zero effort from the Cabal team to integrate these other tools
that you point to.

From jho.xray at gmail.com  Thu Dec 10 14:17:39 2020
From: jho.xray at gmail.com (J Ho)
Date: Thu, 10 Dec 2020 15:17:39 +0100
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
Message-ID: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>

What's wrong with Stack though? Works like a charm in all our projects, and
with Nix integration takes care of the external c-libs etc dependencies
quite nicely.

On Thu, Dec 10, 2020 at 3:07 PM Ignat Insarov <kindaro at gmail.com> wrote:

> Thanks Francesco. I have also been using Cabal since a long time ago.
> There is no question that some great things get done in Cabal. Mostly,
> Cabal does what it says on the box, and this is why I propose to
> improve it and not, say, move to Stack. But you may see that many
> people prefer the latter — this seems even more weird since, as you
> illuminate, Cabal can already interoperate with Stackage, so it is
> strictly more featureful. _(As far as I follow, Stack still has poor
> support for Backpack and sub-package build targets.)_
>
> However, even in the light of the links you provide, we still cannot
> say that Cabal supports Stackage. You say:
>
> > >   There is no reason for two build tools to exist. The killer feature
> of Stack —
> > >   snapshots — should be supported by Cabal.
> >
> > As far as I know, this is already possible today! [1]
> >
> > [1] https://github.com/fpco/stackage-server/issues/232
> >     see also https://github.com/erikd/jenga/
> >              https://hackage.haskell.org/package/stack2cabal
>
> Heading to that link, the closing message says:
>
> > I've added a warning about the lack of support for revisions in
> cabal.config in f9632d7. Closing.
>
> So, something is not working. Reading in more detail, there is
> evidently a disagreement between the core developers of Cabal and
> Stack. And as I understand, it has not been addressed ever since! This
> is exactly an example of the kind of communication problems that I
> alluded to in my first letter. Also, as far as I can see, there has
> been zero effort from the Cabal team to integrate these other tools
> that you point to.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201210/f95529a0/attachment.html>

From kovanikov at gmail.com  Thu Dec 10 15:02:37 2020
From: kovanikov at gmail.com (Dmitrii Kovanikov)
Date: Thu, 10 Dec 2020 15:02:37 +0000
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
Message-ID: <CAMdbBiGQO7gTNh2k4p5urQBuFELHb+JnB+8hxx4m6OXhjG7qvg@mail.gmail.com>

Thanks, Ignat for bringing this issue! This is indeed a problem in the
Haskell community and ecosystem at the moment, and we can't just ignore it
if we want to improve things.

Every Haskell developer uses the build tool. This is a crucial piece of
development toolchain. That's why it's sad if a core tool is maintained
only by a single person, maintainers are not willing to have more
open-minded discussions regarding some user-requested features or a tool
have poor UX. In my vision, everyone should be welcome to open issues to a
build tool and contribute to it as everyone will benefit from improvements.
And it's a pity that some people have a negative experience with this
process which drives contributors away. I'm following the Cabal issue
tracker, so I notice from time to time some not friendly behaviour towards
its users.

In the same spirit, having multiple build tools leads to duplication of
effort for fixing the same problems and implementing the same features.
Writing a build tool requires a colossal amount of effort and time. Not to
mention that supporting both build tools is an enormous job as well.

* If your project builds with Cabal, it's not guaranteed to build with
Stack (at least you need to write stack.yaml).
* If your project builds with Stack, it's not guaranteed to build with
Cabal (you may need to specify upper and lower bounds).

Thus, every maintainer must spend a lot of time maintaining support for
both build tools if they want to provide good UX for everyone. I'm doing
this for multiple years, and it's a troublesome process, but I do believe
that thinking about users first is the way forward. This effort seems
redundant in a theoretical world where Haskell has a single, core,
official, open-sourced build tool managed by the community.

> I have enjoyed using cabal very much

I'm also using Cabal for my personal projects, but this doesn't mean there
are no problems. I learned to circumvent build tools pitfalls and survive
in the ocean of incomprehensible errors, but I'm already in the middle of
the ocean, and I don't want to stop swimming. Beginners, who are just
staying on the coast, might not want to go into it at all.

Best,
Dmitrii



On Thu, 10 Dec 2020 at 14:06, Ignat Insarov via hf-discuss <
hf-discuss at haskell.org> wrote:

> Thanks Francesco. I have also been using Cabal since a long time ago.
> There is no question that some great things get done in Cabal. Mostly,
> Cabal does what it says on the box, and this is why I propose to
> improve it and not, say, move to Stack. But you may see that many
> people prefer the latter — this seems even more weird since, as you
> illuminate, Cabal can already interoperate with Stackage, so it is
> strictly more featureful. _(As far as I follow, Stack still has poor
> support for Backpack and sub-package build targets.)_
>
> However, even in the light of the links you provide, we still cannot
> say that Cabal supports Stackage. You say:
>
> > >   There is no reason for two build tools to exist. The killer feature
> of Stack —
> > >   snapshots — should be supported by Cabal.
> >
> > As far as I know, this is already possible today! [1]
> >
> > [1] https://github.com/fpco/stackage-server/issues/232
> >     see also https://github.com/erikd/jenga/
> >              https://hackage.haskell.org/package/stack2cabal
>
> Heading to that link, the closing message says:
>
> > I've added a warning about the lack of support for revisions in
> cabal.config in f9632d7. Closing.
>
> So, something is not working. Reading in more detail, there is
> evidently a disagreement between the core developers of Cabal and
> Stack. And as I understand, it has not been addressed ever since! This
> is exactly an example of the kind of communication problems that I
> alluded to in my first letter. Also, as far as I can see, there has
> been zero effort from the Cabal team to integrate these other tools
> that you point to.
> _______________________________________________
> hf-discuss mailing list
> hf-discuss at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201210/f979ae97/attachment.html>

From rae at richarde.dev  Thu Dec 10 19:50:04 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 10 Dec 2020 19:50:04 +0000
Subject: [Haskell-cafe] [HF-discuss]  Do something about Cabal?
In-Reply-To: <67B43049-BDF9-4F4F-8C76-E484D8C8CFDF@disroot.org>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <67B43049-BDF9-4F4F-8C76-E484D8C8CFDF@disroot.org>
Message-ID: <010f01764e341294-7a0a53b6-ee76-4330-979c-a0dad7a7c113-000000@us-east-2.amazonses.com>

In my view, a lack of communication like the one highlighted here is exactly what the Haskell Foundation hopes to improve. It's still being bootstrapped, so don't expect any action soon, but I would hope for forward motion by the springtime.

Of course, the HF needs all of us to be the best foundation it can -- so please consider nominating yourself for a board position (https://haskell.foundation/board-nominations/) and/or applying for the executive director (full-time, salaried) position (https://haskell.foundation/ed-job-description/)! In either role, you could have direct impact on moving this all forward.

Richard

> On Dec 10, 2020, at 6:42 AM, Allen Sobot via hf-discuss <hf-discuss at haskell.org> wrote:
> 
> As a still (very) new Haskell user by many measures, indeed the little experience I had with Cabal isn't great overall in my view (honestly not a fan of Stack grabbing separate GHC instances though either unless I pass like 2 command-line flags, if there's a configuration option I'm not aware of I'd be grateful).
> 
> I had no clue about the communication issues etc. plaguing Cabal, that explains a bit...
> 
> In any case I'd like to try to contribute what I can to this effort, mainly to improve the UX which I agree is absolutely terrible in my humble opinion.
> 
> (Side note: I was informed on another mailing list that I may have some setting pertaining to forcing some kind of read receipt which is considered impolite on mailing lists, if this is still the case I apologize and I'm trying to determine what even is the precise issue or setting controlling it, at least on K-9 Mail and Neomutt)
> 
> On December 10, 2020 12:23:42 p.m. GMT+01:00, Ignat Insarov <kindaro at gmail.com <mailto:kindaro at gmail.com>> wrote:
>> # Do something about Cabal?
>> 
>> Hello.
>> 
>> Cabal is the second most used tool in Haskell after GHC. It has many
>> problems. It may be noticed that there is one and a half developers working on
>> it. This is clearly not enough to address these problems. I propose that this is
>> a good place to invest in.
>> 
>> ### Problems I have in mind:
>> 
>> * Poor communication, lack of open source development process.
>> 
>> The whole Cabal–Stack schism appears to be an outcome of poor
>> communication. One of the leading developers of Cabal is even banned from
>> participation somewhere in Stack circles.[1] Personally, I reported several
>> issues to Cabal and every single time it resulted in sadness. Observe a
>> vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
>> there are fewer contributors ⇒ core developers are overworked.
>> 
>> I have no hard evidence but it appears that presently, more people that strive
>> to improve the Haskell build experience are outside the Cabal cabal than are
>> inside.
>> 
>> * User experience is an afterthought.
>> 
>> Cabal's user experience is horrifying. A collection of complaints is being
>> compiled elsewhere.[2] There are also bugs being opened to Cabal because of
>> this, requiring triage and therefore wasting the precious time of the few
>> overworked developers. Stack is much more friendly — this shows by example
>> that the user experience problem is not inherent and may be solved.
>> 
>> It is ordinary to receive output like this:
>> 
>> ```
>> % cabal run example-executable
>> Warning: The package list for 'hackage.haskell.org' is 84 days old.
>> Run 'cabal update' to get the latest list of available packages.
>> Resolving dependencies...
>> cabal: Could not resolve dependencies:
>> [__0] trying: example-0.1.0.6 (user goal)
>> [__1] next goal: opaleye (dependency of example)
>> [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
>> config TODO requires ==0.6.7006.1)
>> [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
>> [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
>> opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
>> opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
>> opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
>> opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
>> opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
>> opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
>> opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
>> previous version to fail: excluded by constraint '^>=0.7' from example)
>> [__1] fail (backjumping, conflict set: example, opaleye)
>> After searching the rest of the dependency tree exhaustively, these were the
>> goals I've had most trouble fulfilling: opaleye, example
>> ```
>> 
>> There are so many things that are wrong here. Even a sneaky _«to do»_
>> remark. If you wonder, in this case the solution is to remove and re-generate
>> `cabal.project.freeze`.
>> 
>> Even the name of the program — it is actually _«cabal-install»_ — is
>> incomprehensible, it should be re-branded to Cabal, which is how everyone
>> calls it anyway.
>> 
>> * Features are not being introduced.
>> 
>> There is no reason for two build tools to exist. The killer feature of Stack —
>> snapshots — should be supported by Cabal. Possibly Cabal itself should be
>> refactored and split so that there are separate tools for packaging, version
>> resolution and human interaction — I do not know. But certainly the way things
>> are presently is a waste of developer effort and a source of confusion for
>> everyone.
>> 
>> ### My proposition, in particular.
>> 
>> * Ask all the people that show compassion to the cause of a great Haskell build
>> tool to unite and work together on a better Cabal. This includes the
>> developers of Stack and everyone that expressed unhappiness with the current
>> state of Cabal. These people should be seen as a blessing, not as an obstacle.
>> * Put in place a clear process for contributing and decision making, so that it
>> does not come down to the privileged opinion of one of the core developers.
>> * Make a model of user experience that Cabal should conform to, and make
>> conformance a priority. Surely there are among us people that know a thing or
>> two about user experience — call for them to step forward. Every issue that
>> stems from misunderstanding, re-assign to the model instead of closing.
>> * Merge the support of Stackage snapshots into Cabal. Ask the core developers of
>> Stack to join the effort. Transition from Stack to Cabal should be one well
>> discoverable command that just works.
>> 
>> I realize that this letter is largely an opinion piece. You can also see it as
>> an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
>> present. I do not insist that my vision is the best. But the present reality is
>> not the best vision either. I propose, foremost, that we work and fight for a
>> better future.
>> 
>> [1]: https://github.com/commercialhaskell/stackage/issues/4472
>> [2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
>> _______________________________________________
>> 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.
> _______________________________________________
> hf-discuss mailing list
> hf-discuss at haskell.org <mailto:hf-discuss at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss <https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201210/563bfedd/attachment.html>

From trebla at vex.net  Thu Dec 10 19:46:21 2020
From: trebla at vex.net (Albert Y. C. Lai)
Date: Thu, 10 Dec 2020 14:46:21 -0500
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
 <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
Message-ID: <2562d911-ca23-54ae-7b86-34271df37062@vex.net>

-1 from me.  I vote for the status quo.

0. I believe that it really comes down to a vote (as opposed to settling 
by technical merit).  My work habit (which stems from my personality) is 
going to be the opposite of many people's, and vice versa.  Every 
"technical merit" cited on this issue is conditional on accepting a 
certain personality.  So yes it has to come down to a vote.  I'm OK if I 
happen to be in the minority.

1. -Wall warnings have almost zero correletion with my mistakes.  (See? 
my personality dictates what mistakes I make. YMMV.)

An example is unused binds.  My unused binds are intentional, thank you 
very much.  I make unused binds because it's future-proof---perhaps I 
will actually use it in the next version?  Editing from

(p, _q) = f x

to

(p, q) = f x

produces noise in diffs and commits, no?  Some of you are against noisy 
diffs and commits, no?  Then embrace unused binds!

2. In fact, I go so far as adding -fdefer-type-errors during the first 
99% of a development cycle.  Why?  Because ghci is so much more 
informative when :load succeeds.  Tab completion works.  :type works. 
Asking for where a local variable is defined works.  Asking for the type 
of an arbitrary subexpression works.  (I use those features via emacs 
haskell-mode or dante, of course.)  Would be a pity to throw that all 
away just for unfinished code.  Hell, to finish the unfinished code, I 
need those ghci features.  90% of the people who think they need a 
Haskell IDE, they just need this, -fdefer-type-errors and a low-tech 
editor plugin that actually knows what ghci offers.

-fdefer-type-errors still gives me compile-time warnings for what should 
be static errors.  I am not losing any information.  Clearly, I don't 
consider my job done until all-clear.  Just let me do my job.


On 2020-12-10 2:50 a.m., Georgi Lyubenov wrote:
> For me, the default is -Wall and the "production" version is also 
> turning on -Werror.
> 
> I'm +1 on this.
> 
> =======
> Georgi
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
> 

From jack at jackkelly.name  Thu Dec 10 21:07:00 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Thu, 10 Dec 2020 21:07:00 GMT
Subject: [Haskell-cafe] [HF-discuss]  Do something about Cabal?
In-Reply-To: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
Message-ID: <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>


Both tools have deficiencies, but looking at the "10 year overnight success" that is the recent step-change in the quality of Haskell's Language Server Protocol support, I am hopeful for the future. The answer is not as simple as "just use stack" or "just use cabal-install". I do not want to kick off a build-tool flamewar, but neither cabal-install nor stack are magical Christmas lands where everything is perfect. Here are a collection of objections to/my frustrations with stack, which is why "just use stack" isn't an answer to the problem:

- Can't do GHCjs
- Seems to like mass-rebuilding my work projects if I breathe on them the wrong way
- Has its own way of doing everything that's slightly different (different command set, different ways of specifying build targets)
- Fails to give me a REPL if it can't load all of a target's files first (I'm not sure exactly what's going on here, but when using dante, stack will blow up if the project contains a type error somewhere. Which is unhelpful when trying to get interactive editor support to resolve said type errors! Dante driving cabal does not have this problem. Extremely frustrating.)
- Haskell programmers tend to end up coding to the lowest common subset of features across build tools. This held back adoption of backpack, which is sad.
- hpack-by-default pushes another reinvention of basic haskell tooling, and does so with YAML, which is a file format that gets worse the more you understand it. (I expect its defenders will say this is just providing an option, but from my experience onboarding new Hackage uploaders, many people do not realise that hpack is optional.)
- Many stack projects do not provide bounds on dependencies, relying on getting exact versions from LTS. This may be defensible for applications that sit at the leaves of a dependency graph, but less so for libraries. Accurate bound information is one of the reasons LTS build plans can be easily constructed, and tooling that encourages sloppy bounds feels to me like it encourages taking without giving back to the shared resource (the common set of libraries on Hackage with well-understood bounds).
- What is casa.fpcomplete.com, and why was its downtime causing CI failures in my projects? What does stack talk to that domain about?

HTH,

-- Jack

December 11, 2020 12:17 AM, "J Ho via hf-discuss" <hf-discuss at haskell.org> wrote:

> What's wrong with Stack though? Works like a charm in all our projects, and with Nix integration
> takes care of the external c-libs etc dependencies quite nicely.
> 
> On Thu, Dec 10, 2020 at 3:07 PM Ignat Insarov <kindaro at gmail.com> wrote:
> 
>> Thanks Francesco. I have also been using Cabal since a long time ago.
>> There is no question that some great things get done in Cabal. Mostly,
>> Cabal does what it says on the box, and this is why I propose to
>> improve it and not, say, move to Stack. But you may see that many
>> people prefer the latter — this seems even more weird since, as you
>> illuminate, Cabal can already interoperate with Stackage, so it is
>> strictly more featureful. _(As far as I follow, Stack still has poor
>> support for Backpack and sub-package build targets.)_
>> 
>> However, even in the light of the links you provide, we still cannot
>> say that Cabal supports Stackage. You say:
>> 
>>>> There is no reason for two build tools to exist. The killer feature of Stack —
>>>> snapshots — should be supported by Cabal.
>>> 
>>> As far as I know, this is already possible today! [1]
>>> 
>>> [1] https://github.com/fpco/stackage-server/issues/232
>>> see also https://github.com/erikd/jenga/
>>> https://hackage.haskell.org/package/stack2cabal
>> 
>> Heading to that link, the closing message says:
>> 
>>> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.
>> 
>> So, something is not working. Reading in more detail, there is
>> evidently a disagreement between the core developers of Cabal and
>> Stack. And as I understand, it has not been addressed ever since! This
>> is exactly an example of the kind of communication problems that I
>> alluded to in my first letter. Also, as far as I can see, there has
>> been zero effort from the Cabal team to integrate these other tools
>> that you point to.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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 jo at durchholz.org  Thu Dec 10 21:49:56 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Thu, 10 Dec 2020 22:49:56 +0100
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
 <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
 <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
Message-ID: <b47992b8-33ef-fa55-794a-997adab4f07f@durchholz.org>

I generally agree that a lot is subjective, but I believe this one is not:

Am 10.12.20 um 20:46 schrieb Albert Y. C. Lai:
> I make unused binds because it's future-proof---perhaps I 
> will actually use it in the next version?  Editing from
> 
> (p, _q) = f x
> 
> to
> 
> (p, q) = f x
> 
> produces noise in diffs and commits, no?

No, that's not noise, it's a reminder that _q is now being used.
Sure, there will also be other changes in the function's body. Still, a 
single-change noise isn't much concern.

Well okay. If your diff tool does only by-line diffs and not by-word or 
by-character diffs, then yeah it's annoying.
This used to be a serious problem a view years ago. Not anymore today 
I'd say, word diffs are pretty commonplace nowadays.

> Some of you are against noisy 
> diffs and commits, no?  Then embrace unused binds!

Noise in the always-the-same place isn't much of a hassle actually.
At some point I even started to notice the *absence* of some noise and 
got alerted to a mistake.

YMMV :-)

> 2. In fact, I go so far as adding -fdefer-type-errors during the first 
> 99% of a development cycle.  Why?  Because ghci is so much more 
> informative when :load succeeds.

Will -Wall prevent :load?
If not, this particular argument is beside the point.

Just my 2 cents.

Regards,
Jo

From zachi at baharav.org  Thu Dec 10 21:55:06 2020
From: zachi at baharav.org (Zachi Baharav)
Date: Thu, 10 Dec 2020 13:55:06 -0800
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using Haskell)
Message-ID: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>

Dear mighty Haskell list,

I am a high-school teacher in the US (California, Palo Alto). We have an
advanced CS course that students can take after completing the AP-CS-A (in
Java). This is usually Juniors and Seniors, after at least 2 or 3 courses
of coding (Python+Java). Traditionally, I've done a potpourri of subjects,
mostly search algorithms as applied to 'games'. Of course a little bit of
data-structure comes in, and each year we did some 'other' interesting
subject (like halftoning, barcodes, and so on) and investigated and
implemented algorithms there.

THIS year, for the second half, I would like us to do
Functional-Programming. From what I have seen, my students over the years
tend to write more and more convoluted codes, electing first to search on
stackOverFlow for some similar pattern, rather than think and find a
concise and clean solution. I think FP would supply them with a new way of
thinking, which will help with whatever they will write later on.

I've been coding with Haskell for about 7 years, so feel ok leading the
class.

The question: I have many books on Haskell (i think 'all', but who knows.
Haskell, Real world Haskell, Learn you a haskell for great good,
programming in haskell, and many more).
--->  I am looking for something more hands-on and 'fun' for HS students.
may i say the buzzword 'project based', or maybe better 'problem based' for
our case.
Something that I could teach a little, and then we can solve a bunch of
problems, and teach a little more, and so on.

It doesn't have to be a Book!!  Just an outline of a course someone did
with associated bunch of problems would be awesome. We have 18 weeks in a
semester. My thought right now (if I don't find anything) is to relyon
Euler project early problems. These are often clean and simple in Haskell.
Or otherwise some CSES problems (which we've done in Java).

Ok, long enough email.

If you have material and can share here, great!
If you have material and want to reach out privately, please do (
zbaharav at kehillah.org).
If you have a good pointer, that would be appreciated.

Thanks in advance for any help!
   Zachi
(Dr. Zachi Baharav, HS teacher  (after 20 years in Industry and academia))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201210/5b3d5a80/attachment-0001.html>

From ietf-dane at dukhovni.org  Thu Dec 10 22:53:05 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Dec 2020 17:53:05 -0500
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
Message-ID: <X9Km0RF/1RLrQ72U@straasha.imrryr.org>

On Thu, Dec 10, 2020 at 04:23:42PM +0500, Ignat Insarov wrote:

> * User experience is an afterthought.

I don't think that's fair. Making/keeping the simple things easy,
without making the complex things impossible is always a challenge. 

Yes, starting a hello-world project should admittedly be one command
with fewer required options.  Presently, it is:

    $ mkdir hello
    $ cd hello
    $ cabal init --cabal-version=2.4 --license=NONE -p helloworld

but this is not the primary barrier to Cabal's usability.

Like many a tool that has evolved over decades, and supports backwards
compatible historical practices, Cabal exposes more complexity and rough
edges than much more recent toolchains that don't share than burden.

Give me Cabal over Debian packages any day...

>   Cabal's user experience is horrifying. 

It is likely that use of strident terms like "horrifying" does not
further the kind of community building that this message aims to
achieve. :-(

Indeed cabal was fairly intimidating when I started out, and for a long
time I used stack.  More recently I've switched to cabal, as a more
flexible power tool.  And yet some workflows, e.g. involving internal
libraries, custom builds, code generation, doctest integration, ...
remain challenging to figure out.  On the whole, I've seen much progress
over the last few years.

>   It is ordinary to receive output like this:
> 
>   cabal: Could not resolve dependencies:

I would posit that this is the main obstacle facing most users, and is
largely not Cabal's fault.  Rather it is a key property of the Hackage
ecosystem that libraries can and do make incompatible changes across
major version bumps, and that when one chooses a sufficiently new GHC
or elects a sufficiently new feature of some library, the rest of the
ecosystem may not yet be manifestly compatible with that choice.

Stack side-steps the problem by freezing the compiler, base and most
dependencies.  This is often convenient, but is not always what you
want.

I don't see a high likelihood of a second community effort that produces
LTS-style snapshots for cabal, nor that the Cabal and stack teams goals
will align sufficiently to make the snapshot definitions a shared
resource.  Perhaps I'm too cynical, but I think that's the realistic
assessment.

> ### My proposition, in particular.
> 
> * Ask all the people that show compassion to the cause of a great Haskell build
>   tool to unite and work together on a better Cabal. This includes the
>   developers of Stack and everyone that expressed unhappiness with the current
>   state of Cabal. These people should be seen as a blessing, not as an obstacle.

This post seems unlikely to lead to that outcome...  It has probably
already started off on the wrong foot, by being more strident than
constructive.

It all probability reuniting development efforts that have parted ways
is not possible.  All that can happen is that some, but ideally not all
will wither away.  Nobody has succeeded in reuniting NetBSD, OpenBSD and
FreeBSD.  Not to mention the many Linux distributions, screen vs. tmux,
GCC vs. LLVM, KDE vs. Gnome, ...

More realistically, contributors to Cabal willing to devote time and
energy to improving it will add the features that they care about most.
Perhaps now and then someone will step up to *fund* development of some
crucial feature that no volunteer is likely to build on their own
accord.  It all largely boils down to resources, and the fact that
volunteers will work on what most interests them, and there's no
benevolent dictator able to set a global agenda.

-- 
    Viktor.

From trebla at vex.net  Thu Dec 10 23:06:44 2020
From: trebla at vex.net (Albert Y. C. Lai)
Date: Thu, 10 Dec 2020 18:06:44 -0500
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <b47992b8-33ef-fa55-794a-997adab4f07f@durchholz.org>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
 <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
 <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
 <b47992b8-33ef-fa55-794a-997adab4f07f@durchholz.org>
Message-ID: <d6381b4d-104a-6585-6a47-b377d3758f6e@vex.net>

On 2020-12-10 4:49 p.m., Joachim Durchholz wrote:
> Will -Wall prevent :load?
> If not, this particular argument is beside the point.

-Wall will hide the few warnings I need in the haystack of a lot of 
warnings I don't need.

From guthrie at miu.edu  Thu Dec 10 23:08:42 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Thu, 10 Dec 2020 23:08:42 +0000
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
 Haskell)
In-Reply-To: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
Message-ID: <DM6PR03MB43312A5A4CEEFCE28C7EB074A1CB0@DM6PR03MB4331.namprd03.prod.outlook.com>

Nice situation and goal.

I have seen several nice books in Python which make programming and problem solving fun – perhaps you coud adapt one of them, but code in Python – end up with a book for further reuse! Or just use the basic tone and approach.

“Impractical Python: Projects Playful Programming Activities to Make You Smarter”
“Playful Programming - Python at Home”



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

From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Zachi Baharav
Sent: Thursday, December 10, 2020 3:55 PM
To: Haskell Cafe <haskell-cafe at haskell.org>
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using Haskell)

Dear mighty Haskell list,

I am a high-school teacher in the US (California, Palo Alto). We have an advanced CS course that students can take after completing the AP-CS-A (in Java). This is usually Juniors and Seniors, after at least 2 or 3 courses of coding (Python+Java). Traditionally, I've done a potpourri of subjects, mostly search algorithms as applied to 'games'. Of course a little bit of data-structure comes in, and each year we did some 'other' interesting subject (like halftoning, barcodes, and so on) and investigated and implemented algorithms there.

THIS year, for the second half, I would like us to do Functional-Programming. From what I have seen, my students over the years tend to write more and more convoluted codes, electing first to search on stackOverFlow for some similar pattern, rather than think and find a concise and clean solution. I think FP would supply them with a new way of thinking, which will help with whatever they will write later on.

I've been coding with Haskell for about 7 years, so feel ok leading the class.

The question: I have many books on Haskell (i think 'all', but who knows.  Haskell, Real world Haskell, Learn you a haskell for great good, programming in haskell, and many more).
--->  I am looking for something more hands-on and 'fun' for HS students. may i say the buzzword 'project based', or maybe better 'problem based' for our case.
Something that I could teach a little, and then we can solve a bunch of problems, and teach a little more, and so on.

It doesn't have to be a Book!!  Just an outline of a course someone did with associated bunch of problems would be awesome. We have 18 weeks in a semester. My thought right now (if I don't find anything) is to relyon Euler project early problems. These are often clean and simple in Haskell.  Or otherwise some CSES problems (which we've done in Java).

Ok, long enough email.

If you have material and can share here, great!
If you have material and want to reach out privately, please do (zbaharav at kehillah.org<mailto:zbaharav at kehillah.org>).
If you have a good pointer, that would be appreciated.

Thanks in advance for any help!
   Zachi
(Dr. Zachi Baharav, HS teacher  (after 20 years in Industry and academia))







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

From trebla at vex.net  Thu Dec 10 23:58:28 2020
From: trebla at vex.net (Albert Y. C. Lai)
Date: Thu, 10 Dec 2020 18:58:28 -0500
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
 Haskell)
In-Reply-To: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
Message-ID: <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>

I think that the 99 Haskell Problems are an easy source of short exercises.

https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems

For longer, well-motivated problems, I think of the long-running 
examples in textbooks, for example the Countdown chapter in Hutton's 
Programming in Haskell.

If you can find/borrow Lawrence Paulson's ML for The Working Programmer, 
it has a list of suggested projects near the end.  Don't worry about how 
that book is on ML rather than Haskell, most of its exercises and 
projects are good for Haskell too.  In fact, enjoy this sentence from 
the book: "This sort of thing is easier in Haskell". :)

And now a dark turn---every silver lining has tarnish.

FP does not change people from writing convoluted borrowed code to 
original simple code.  I saw this in my students, their only difference 
from your dis they are in university.  Everything you said about having 
gone through Python and Java, fishing for answers on Stackoverflow, and 
making a mess, is just as true of my students.  And to think that 
they're university students, yes.

In fact, it may be even worse, now that recursion is compulsory.  People 
distrust recursion, they will think up all kinds of crazy schemes to 
micromanage code execution, rather than just letting recursion do its job.

In fact, even worse when the language is Haskell instead of SML and 
OCaml, because of "how do I print debugging output?"


On 2020-12-10 4:55 p.m., Zachi Baharav wrote:
> Dear mighty Haskell list,
> 
> I am a high-school teacher in the US (California, Palo Alto). We have an 
> advanced CS course that students can take after completing the AP-CS-A 
> (in Java). This is usually Juniors and Seniors, after at least 2 or 3 
> courses of coding (Python+Java). Traditionally, I've done a potpourri of 
> subjects, mostly search algorithms as applied to 'games'. Of course a 
> little bit of data-structure comes in, and each year we did some 'other' 
> interesting subject (like halftoning, barcodes, and so on) and 
> investigated and implemented algorithms there.
> 
> THIS year, for the second half, I would like us to do 
> Functional-Programming. From what I have seen, my students over the 
> years tend to write more and more convoluted codes, electing first to 
> search on stackOverFlow for some similar pattern, rather than think and 
> find a concise and clean solution. I think FP would supply them with a 
> new way of thinking, which will help with whatever they will write later on.
> 
> I've been coding with Haskell for about 7 years, so feel ok leading the 
> class.
> 
> The question: I have many books on Haskell (i think 'all', but who 
> knows.  Haskell, Real world Haskell, Learn you a haskell for great good, 
> programming in haskell, and many more).
> --->  I am looking for something more hands-on and 'fun' for HS 
> students. may i say the buzzword 'project based', or maybe better 
> 'problem based' for our case.
> Something that I could teach a little, and then we can solve a bunch of 
> problems, and teach a little more, and so on.
> 
> It doesn't have to be a Book!!  Just an outline of a course someone did 
> with associated bunch of problems would be awesome. We have 18 weeks in 
> a semester. My thought right now (if I don't find anything) is to relyon 
> Euler project early problems. These are often clean and simple in 
> Haskell.  Or otherwise some CSES problems (which we've done in Java).
> 
> Ok, long enough email.
> 
> If you have material and can share here, great!
> If you have material and want to reach out privately, please do 
> (zbaharav at kehillah.org <mailto:zbaharav at kehillah.org>).
> If you have a good pointer, that would be appreciated.
> 
> Thanks in advance for any help!
>     Zachi
> (Dr. Zachi Baharav, HS teacher  (after 20 years in Industry and academia))
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
> 


From lemming at henning-thielemann.de  Fri Dec 11 00:07:15 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 11 Dec 2020 01:07:15 +0100 (CET)
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
 Haskell)
In-Reply-To: <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
Message-ID: <alpine.DEB.2.20.2012110104030.8596@sputnik>


On Thu, 10 Dec 2020, Albert Y. C. Lai wrote:

> In fact, it may be even worse, now that recursion is compulsory.  People 
> distrust recursion, they will think up all kinds of crazy schemes to 
> micromanage code execution, rather than just letting recursion do its job.

My experience is that students see in the first lession how recursion 
works and then stop learning new concepts. They keep coding every 'map', 
'filter' and 'foldl' manually as recursion. So recursion looks to me as 
funtional programming's GOTO, and if it is tail recursive, it actually is 
one.

From monkleyon at gmail.com  Fri Dec 11 00:44:23 2020
From: monkleyon at gmail.com (MarLinn)
Date: Fri, 11 Dec 2020 01:44:23 +0100
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <CAATCwU=EVp-t2jox+R91zn5E5CX5GtC8-0UAVguDHdnL-gZwZA@mail.gmail.com>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <CAATCwU=EVp-t2jox+R91zn5E5CX5GtC8-0UAVguDHdnL-gZwZA@mail.gmail.com>
Message-ID: <6b296877-8de6-42cd-0f62-2157c00ad920@gmail.com>

While I do get many of the points mentioned in this thread, I don't see 
a reason to change a default.

Because

     A) you can set your own default with magic .ghci files, and

     B) there's so much more to a well-set-up development $HOME than 
just a -Wall and a big (editor) window.

In fact quite a few of the different problems mentioned in this thread 
can be solved with a bit of tinkering.
Here is my setup as an example:

My main companion .ghci file lives with me in my $HOME. When I take it 
for walkies it runs a few others (~/.ghc/macros) to set prompts and 
default editor, to import lambdabot and hoogle, and to setup a few other 
niceties, but it also contains these two key lines:

	:set -Wall -fdefer-typed-holes -fwarn-tabs -fwarn-incomplete-uni-patterns -fwarn-incomplete-record-updates -fwarn-identities -fwarn-hi-shadowing -Wredundant-constraints
	:seti -XTemplateHaskell -XQuasiQuotes -XUnicodeSyntax -XTupleSections

There's that -Wall. I have forgotten what half of the others mean, but 
they sort of accumulated over time.

Now you might say those are too many warnings. Yes. I want all of these 
warnings when I'm finalizing a module, but not while I'm still working 
on a new one.
And what's with those extensions?

Well, I also have a default set of language extensions I almost always 
want, both in ghci and my files. And I was tired of re-typing the same 
old imports, too. So I made several templates. A tiny bit of Haskell 
scripting magic turns them into a fresh new module whenever I want to 
start a new one.

Here's one of those templates:

------------------------------------------------------------------------

	#! /usr/bin/env runghc
	{-# OPTIONS_GHC -fno-warn-unused-imports #-}
	{-# LANGUAGE
	    UnicodeSyntax
	  , OverloadedStrings
	  , TupleSections
	  , RecordWildCards
	  , MultiWayIf
	  , LambdaCase
	  #-}
	
	module §name§
	  where
	
	import           Control.Applicative
	import           Control.Arrow
	import           Control.Monad
	import           Data.Monoid
	import           Data.Either
	import           Data.Function
	import           Data.List
	import           Data.Maybe
	import           Data.Foldable
	import           Data.Traversable
	import           Data.Map.Strict         ( Map )
	import qualified Data.Map.Strict  as Map
	import           Data.Set                ( Set )
	import qualified Data.Set         as Set

------------------------------------------------------------------------

In fact when I say "Haskell scripting magic", I mean "Haskell scripting 
magic that's got its own ghci command, defined in the .ghci file".

So when I want a new module, I simply say

	:create Example
	:l Example.hs
	:e

And off I go.

When I'm done with the module I remove that one -fno-warn and start 
cleaning up.
I said those where /too/ many warnings for me, not /way/ too many 
warnings, right?

Is this a set of warnings or extension everyone wants? Absolutely not. 
Is it time to prune this to adapt to changed GHC defaults? Probably. 
Should I rework this some day to use an actual templating library like 
ginger instead of my own quickly-cobbled-together mess? Maybe. And it 
should probably also adapt to the project structure by looking into 
.cabal files. But for now, it works great for my use cases and coding style.

Don't get me wrong, changing the default might still be a good idea. But 
I also don't see a reason to be bothered by it.

Cheers.


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

From trebla at vex.net  Fri Dec 11 00:47:03 2020
From: trebla at vex.net (Albert Y. C. Lai)
Date: Thu, 10 Dec 2020 19:47:03 -0500
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
 Haskell)
In-Reply-To: <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
Message-ID: <733b9f1f-ff99-1743-9765-052d5b2b53ae@vex.net>

On 2020-12-10 6:58 p.m., Albert Y. C. Lai wrote:
> In fact, even worse when the language is Haskell instead of SML and 
> OCaml, because of "how do I print debugging output?"

Speaking of which, this is my debugging output tutorial:

http://www.vex.net/~trebla/haskell/tracing.html

Students seeing that early won't have to go through the rabbit hole of 
Googling for "how to print in haskell" (beginners can't know upfront 
that the correct Googling is "how to debug print in haskell") and 
getting very distracted.

From asm13243546 at gmail.com  Fri Dec 11 02:56:32 2020
From: asm13243546 at gmail.com (=?UTF-8?B?w4FsdmFybyBNxIF0aGVz?=)
Date: Thu, 10 Dec 2020 21:56:32 -0500
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <6b296877-8de6-42cd-0f62-2157c00ad920@gmail.com>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <CAATCwU=EVp-t2jox+R91zn5E5CX5GtC8-0UAVguDHdnL-gZwZA@mail.gmail.com>
 <6b296877-8de6-42cd-0f62-2157c00ad920@gmail.com>
Message-ID: <CAAZLhTcd9ft+huupVmOqmL=4b7fqFB-JiGkhvExk4xCByGmR0A@mail.gmail.com>

Peanut gallery:

Agreed strongly support non-change and, thank you everyone for this
incredibly useful discussion.

Given that, I think I can still briefly extend the initial question without
changing it by asking,

What actually happens in simplest clear terms, when one fidgets a compiler
flag?

Thank you. Hoping not to re-unlurk.

Btw each off-list is me just to clarify.

On Thu, Dec 10, 2020, 7:46 PM MarLinn <monkleyon at gmail.com> wrote:

> While I do get many of the points mentioned in this thread, I don't see a
> reason to change a default.
>
> Because
>
>     A) you can set your own default with magic .ghci files, and
>
>     B) there's so much more to a well-set-up development $HOME than just a
> -Wall and a big (editor) window.
>
> In fact quite a few of the different problems mentioned in this thread can
> be solved with a bit of tinkering.
> Here is my setup as an example:
>
> My main companion .ghci file lives with me in my $HOME. When I take it for
> walkies it runs a few others (~/.ghc/macros) to set prompts and default
> editor, to import lambdabot and hoogle, and to setup a few other niceties,
> but it also contains these two key lines:
>
> 	:set -Wall -fdefer-typed-holes -fwarn-tabs -fwarn-incomplete-uni-patterns -fwarn-incomplete-record-updates -fwarn-identities -fwarn-hi-shadowing -Wredundant-constraints
> 	:seti -XTemplateHaskell -XQuasiQuotes -XUnicodeSyntax -XTupleSections
>
> There's that -Wall. I have forgotten what half of the others mean, but
> they sort of accumulated over time.
>
> Now you might say those are too many warnings. Yes. I want all of these
> warnings when I'm finalizing a module, but not while I'm still working on a
> new one.
> And what's with those extensions?
>
> Well, I also have a default set of language extensions I almost always
> want, both in ghci and my files. And I was tired of re-typing the same old
> imports, too. So I made several templates. A tiny bit of Haskell scripting
> magic turns them into a fresh new module whenever I want to start a new one.
>
> Here's one of those templates:
> ------------------------------
>
> 	#! /usr/bin/env runghc
> 	{-# OPTIONS_GHC -fno-warn-unused-imports #-}
> 	{-# LANGUAGE
> 	    UnicodeSyntax
> 	  , OverloadedStrings
> 	  , TupleSections
> 	  , RecordWildCards
> 	  , MultiWayIf
> 	  , LambdaCase
> 	  #-}
> 	
> 	module §name§
> 	  where
> 	
> 	import           Control.Applicative
> 	import           Control.Arrow
> 	import           Control.Monad
> 	import           Data.Monoid
> 	import           Data.Either
> 	import           Data.Function
> 	import           Data.List
> 	import           Data.Maybe
> 	import           Data.Foldable
> 	import           Data.Traversable
> 	import           Data.Map.Strict         ( Map )
> 	import qualified Data.Map.Strict  as Map
> 	import           Data.Set                ( Set )
> 	import qualified Data.Set         as Set
>
> ------------------------------
>
> In fact when I say "Haskell scripting magic", I mean "Haskell scripting
> magic that's got its own ghci command, defined in the .ghci file".
>
> So when I want a new module, I simply say
>
> 	:create Example
> 	:l Example.hs
> 	:e
>
> And off I go.
>
> When I'm done with the module I remove that one -fno-warn and start
> cleaning up.
> I said those where *too* many warnings for me, not *way* too many
> warnings, right?
>
> Is this a set of warnings or extension everyone wants? Absolutely not. Is
> it time to prune this to adapt to changed GHC defaults? Probably. Should I
> rework this some day to use an actual templating library like ginger
> instead of my own quickly-cobbled-together mess? Maybe. And it should
> probably also adapt to the project structure by looking into .cabal files.
> But for now, it works great for my use cases and coding style.
>
> Don't get me wrong, changing the default might still be a good idea. But I
> also don't see a reason to be bothered by it.
>
> Cheers.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201210/e07e1546/attachment.html>

From david.feuer at gmail.com  Fri Dec 11 03:02:42 2020
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 10 Dec 2020 22:02:42 -0500
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <d6381b4d-104a-6585-6a47-b377d3758f6e@vex.net>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
 <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
 <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
 <b47992b8-33ef-fa55-794a-997adab4f07f@durchholz.org>
 <d6381b4d-104a-6585-6a47-b377d3758f6e@vex.net>
Message-ID: <CAMgWh9t3i6L6=2TaShydn9D7r1HwkkCNZN4xdnxgW4NNKWp-Zw@mail.gmail.com>

Yes, this exactly. Different people have different opinions about which
warnings they want in the midst of hacking, but many of us, at least, don't
want the potential firehose of -Wall. For one thing, temporarily commenting
out even a single function can potentially throw up dozens of warnings for
unused bindings and unused constructors.

On Thu, Dec 10, 2020, 6:07 PM Albert Y. C. Lai <trebla at vex.net> wrote:

> On 2020-12-10 4:49 p.m., Joachim Durchholz wrote:
> > Will -Wall prevent :load?
> > If not, this particular argument is beside the point.
>
> -Wall will hide the few warnings I need in the haystack of a lot of
> warnings I don't need.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201210/9eb3b671/attachment.html>

From guthrie at miu.edu  Fri Dec 11 03:45:28 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Fri, 11 Dec 2020 03:45:28 +0000
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
 Haskell)
In-Reply-To: <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
Message-ID: <DM6PR03MB4331731F808291483F13EFA7A1CA0@DM6PR03MB4331.namprd03.prod.outlook.com>

This may be superfluous in this forum, but my suggestion for a good approach to the copying/searching problem is to have students first make a pseudo-code design of a solution, and then build small parts of that algorithm, and then incrementally assemble them into a solution.

That way they wouldn't find an online solution which matches their individual pre-submitted components, and it emphasizes the constructive (compositional) nature of modular software good practice, and how well FP supports that.

One can then give incremental changes to the functional requirements, which impact some of the components, but not the overall composed design.

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

-----Original Message-----
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Albert Y. C. Lai
Sent: Thursday, December 10, 2020 5:58 PM
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Teaching High-School one-semester FP (using Haskell)

I think that the 99 Haskell Problems are an easy source of short exercises.

https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems

For longer, well-motivated problems, I think of the long-running examples in textbooks, for example the Countdown chapter in Hutton's Programming in Haskell.

If you can find/borrow Lawrence Paulson's ML for The Working Programmer, it has a list of suggested projects near the end.  Don't worry about how that book is on ML rather than Haskell, most of its exercises and projects are good for Haskell too.  In fact, enjoy this sentence from the book: "This sort of thing is easier in Haskell". :)

And now a dark turn---every silver lining has tarnish.

FP does not change people from writing convoluted borrowed code to original simple code.  I saw this in my students, their only difference from your dis they are in university.  Everything you said about having gone through Python and Java, fishing for answers on Stackoverflow, and making a mess, is just as true of my students.  And to think that they're university students, yes.

In fact, it may be even worse, now that recursion is compulsory.  People distrust recursion, they will think up all kinds of crazy schemes to micromanage code execution, rather than just letting recursion do its job.

In fact, even worse when the language is Haskell instead of SML and OCaml, because of "how do I print debugging output?"


On 2020-12-10 4:55 p.m., Zachi Baharav wrote:
> Dear mighty Haskell list,
> 
> I am a high-school teacher in the US (California, Palo Alto). We have an 
> advanced CS course that students can take after completing the AP-CS-A 
> (in Java). This is usually Juniors and Seniors, after at least 2 or 3 
> courses of coding (Python+Java). Traditionally, I've done a potpourri of 
> subjects, mostly search algorithms as applied to 'games'. Of course a 
> little bit of data-structure comes in, and each year we did some 'other' 
> interesting subject (like halftoning, barcodes, and so on) and 
> investigated and implemented algorithms there.
> 
> THIS year, for the second half, I would like us to do 
> Functional-Programming. From what I have seen, my students over the 
> years tend to write more and more convoluted codes, electing first to 
> search on stackOverFlow for some similar pattern, rather than think and 
> find a concise and clean solution. I think FP would supply them with a 
> new way of thinking, which will help with whatever they will write later on.
> 
> I've been coding with Haskell for about 7 years, so feel ok leading the 
> class.
> 
> The question: I have many books on Haskell (i think 'all', but who 
> knows.  Haskell, Real world Haskell, Learn you a haskell for great good, 
> programming in haskell, and many more).
> --->  I am looking for something more hands-on and 'fun' for HS 
> students. may i say the buzzword 'project based', or maybe better 
> 'problem based' for our case.
> Something that I could teach a little, and then we can solve a bunch of 
> problems, and teach a little more, and so on.
> 
> It doesn't have to be a Book!!  Just an outline of a course someone did 
> with associated bunch of problems would be awesome. We have 18 weeks in 
> a semester. My thought right now (if I don't find anything) is to relyon 
> Euler project early problems. These are often clean and simple in 
> Haskell.  Or otherwise some CSES problems (which we've done in Java).
> 
> Ok, long enough email.
> 
> If you have material and can share here, great!
> If you have material and want to reach out privately, please do 
> (zbaharav at kehillah.org <mailto:zbaharav at kehillah.org>).
> If you have a good pointer, that would be appreciated.
> 
> Thanks in advance for any help!
>     Zachi
> (Dr. Zachi Baharav, HS teacher  (after 20 years in Industry and academia))
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 jo at durchholz.org  Fri Dec 11 05:15:07 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 11 Dec 2020 06:15:07 +0100
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <d6381b4d-104a-6585-6a47-b377d3758f6e@vex.net>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
 <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
 <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
 <b47992b8-33ef-fa55-794a-997adab4f07f@durchholz.org>
 <d6381b4d-104a-6585-6a47-b377d3758f6e@vex.net>
Message-ID: <4515611f-907c-a0e2-8c92-fc395db9ca65@durchholz.org>

Am 11.12.20 um 00:06 schrieb Albert Y. C. Lai:
> On 2020-12-10 4:49 p.m., Joachim Durchholz wrote:
>> Will -Wall prevent :load?
>> If not, this particular argument is beside the point.
> 
> -Wall will hide the few warnings I need in the haystack of a lot of 
> warnings I don't need.

You said

 > Because ghci is so much more informative when :load succeeds.

which struck a cognitive dissonance in me, so my question still is: Will 
a warning from -Wall prevent :load from succeeding?

Regards,
Jo

From jo at durchholz.org  Fri Dec 11 05:30:21 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 11 Dec 2020 06:30:21 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <X9Km0RF/1RLrQ72U@straasha.imrryr.org>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <X9Km0RF/1RLrQ72U@straasha.imrryr.org>
Message-ID: <91cd16a2-c47f-baf9-087a-6e2a38b24295@durchholz.org>

Am 10.12.20 um 23:53 schrieb Viktor Dukhovni:
> It all probability reuniting development efforts that have parted ways
> is not possible.  All that can happen is that some, but ideally not all
> will wither away.  Nobody has succeeded in reuniting NetBSD, OpenBSD and
> FreeBSD.  Not to mention the many Linux distributions, screen vs. tmux,
> GCC vs. LLVM, KDE vs. Gnome, ...

Ah, that's a bit of survivor bias. Forked libraries and tools re-join 
all the time.
It's not the standard outcome, of course, but I read reports of such 
rejoins often enough that I'd consider the phrase "all that can happen" 
to be too strong to applicable.

Regards,
Jo

From compl.yue at icloud.com  Fri Dec 11 08:15:15 2020
From: compl.yue at icloud.com (YueCompl)
Date: Fri, 11 Dec 2020 16:15:15 +0800
Subject: [Haskell-cafe] [HF-discuss]  Do something about Cabal?
In-Reply-To: <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
Message-ID: <887B1DEB-2611-4C3D-A0B1-AC93840B64DD@icloud.com>

Just my 2 cents of thoughts, no tool can be perfect, as human individuals. If the Haskell ecosystem can be considered a public asset of all users, contributors, it is not wise for us as the stakeholders to be adverse  of competition. Just imagine the government allowing a single military contractor to monopolize a whole category of weapons, what would come after?

Innovation and advancing comes after competition, why shouldn't we embrace that wrt the tooling of Haskell? Duplication in efforts is a relative smaller problem IMHO.

Sincerely,
Compl


> On 2020-12-11, at 05:07, Jack Kelly via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
> 
> Both tools have deficiencies, but looking at the "10 year overnight success" that is the recent step-change in the quality of Haskell's Language Server Protocol support, I am hopeful for the future. The answer is not as simple as "just use stack" or "just use cabal-install". I do not want to kick off a build-tool flamewar, but neither cabal-install nor stack are magical Christmas lands where everything is perfect. Here are a collection of objections to/my frustrations with stack, which is why "just use stack" isn't an answer to the problem:
> 
> - Can't do GHCjs
> - Seems to like mass-rebuilding my work projects if I breathe on them the wrong way
> - Has its own way of doing everything that's slightly different (different command set, different ways of specifying build targets)
> - Fails to give me a REPL if it can't load all of a target's files first (I'm not sure exactly what's going on here, but when using dante, stack will blow up if the project contains a type error somewhere. Which is unhelpful when trying to get interactive editor support to resolve said type errors! Dante driving cabal does not have this problem. Extremely frustrating.)
> - Haskell programmers tend to end up coding to the lowest common subset of features across build tools. This held back adoption of backpack, which is sad.
> - hpack-by-default pushes another reinvention of basic haskell tooling, and does so with YAML, which is a file format that gets worse the more you understand it. (I expect its defenders will say this is just providing an option, but from my experience onboarding new Hackage uploaders, many people do not realise that hpack is optional.)
> - Many stack projects do not provide bounds on dependencies, relying on getting exact versions from LTS. This may be defensible for applications that sit at the leaves of a dependency graph, but less so for libraries. Accurate bound information is one of the reasons LTS build plans can be easily constructed, and tooling that encourages sloppy bounds feels to me like it encourages taking without giving back to the shared resource (the common set of libraries on Hackage with well-understood bounds).
> - What is casa.fpcomplete.com, and why was its downtime causing CI failures in my projects? What does stack talk to that domain about?
> 
> HTH,
> 
> -- Jack
> 
> December 11, 2020 12:17 AM, "J Ho via hf-discuss" <hf-discuss at haskell.org> wrote:
> 
>> What's wrong with Stack though? Works like a charm in all our projects, and with Nix integration
>> takes care of the external c-libs etc dependencies quite nicely.
>> 
>> On Thu, Dec 10, 2020 at 3:07 PM Ignat Insarov <kindaro at gmail.com> wrote:
>> 
>>> Thanks Francesco. I have also been using Cabal since a long time ago.
>>> There is no question that some great things get done in Cabal. Mostly,
>>> Cabal does what it says on the box, and this is why I propose to
>>> improve it and not, say, move to Stack. But you may see that many
>>> people prefer the latter — this seems even more weird since, as you
>>> illuminate, Cabal can already interoperate with Stackage, so it is
>>> strictly more featureful. _(As far as I follow, Stack still has poor
>>> support for Backpack and sub-package build targets.)_
>>> 
>>> However, even in the light of the links you provide, we still cannot
>>> say that Cabal supports Stackage. You say:
>>> 
>>>>> There is no reason for two build tools to exist. The killer feature of Stack —
>>>>> snapshots — should be supported by Cabal.
>>>> 
>>>> As far as I know, this is already possible today! [1]
>>>> 
>>>> [1] https://github.com/fpco/stackage-server/issues/232
>>>> see also https://github.com/erikd/jenga/
>>>> https://hackage.haskell.org/package/stack2cabal
>>> 
>>> Heading to that link, the closing message says:
>>> 
>>>> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.
>>> 
>>> So, something is not working. Reading in more detail, there is
>>> evidently a disagreement between the core developers of Cabal and
>>> Stack. And as I understand, it has not been addressed ever since! This
>>> is exactly an example of the kind of communication problems that I
>>> alluded to in my first letter. Also, as far as I can see, there has
>>> been zero effort from the Cabal team to integrate these other tools
>>> that you point to.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view 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 immanuel.litzroth at gmail.com  Fri Dec 11 09:31:23 2020
From: immanuel.litzroth at gmail.com (Immanuel Litzroth)
Date: Fri, 11 Dec 2020 10:31:23 +0100
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <887B1DEB-2611-4C3D-A0B1-AC93840B64DD@icloud.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <887B1DEB-2611-4C3D-A0B1-AC93840B64DD@icloud.com>
Message-ID: <CAM1nAcwpjgHpb6OJuwOJSKeGz-13WYi0GYKoDW+s7dY36nvcZA@mail.gmail.com>

I found the whole cabal experience confusing and not well documented.
I kept finding blogs online
that were not working anymore in my version of cabal ('cabal sandbox
init', 'cabal init --sandbox'...) when looking
for advice. I still don't understand the whole v1-build, v2-build,
new-build and build...
The manual doesn't seem to have a decent conceptual overview of what
the tool should do (e.g. an explanation
of what sandboxing is supposed to achieve, or the 4 build command versions).
Several of the links on this page https://www.haskell.org/cabal/  are dead
https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/
or refer to old versions:
https://wiki.haskell.org/Upgrading_packages

This should not be construed as a critique of what has been achieved,
but as honest feedback
of my experience.
> Innovation and advancing comes after competition, why shouldn't we embrace that wrt the tooling of Haskell? Duplication in efforts is a relative smaller problem IMHO.
Well the competition has "go build" and cargo...
And duplication of effort is a problem when there's not enough
resources for even one decent build tool
Immanuel

From luke_lau at icloud.com  Fri Dec 11 09:32:57 2020
From: luke_lau at icloud.com (Luke Lau)
Date: Fri, 11 Dec 2020 09:32:57 +0000
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
Message-ID: <1F8EAAA7-FECC-465A-863C-ED8089C8726A@icloud.com>

haskell-language-server recently got some basic integration with the retrie plugin, and can offer to do folding and unfolding: https://github.com/haskell/haskell-language-server/pull/266

Luke Lau

From spam at scientician.net  Fri Dec 11 09:50:37 2020
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 11 Dec 2020 10:50:37 +0100
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
Message-ID: <rqvfdd$265$1@ciao.gmane.io>

On 10/12/2020 22.07, Jack Kelly via Haskell-Cafe wrote:
> 
> Both tools have deficiencies, but looking at the "10 year overnight success" that is the recent step-change in the quality of Haskell's Language Server Protocol support, I am hopeful for the future. The answer is not as simple as "just use stack" or "just use cabal-install". I do not want to kick off a build-tool flamewar, but neither cabal-install nor stack are magical Christmas lands where everything is perfect. Here are a collection of objections to/my frustrations with stack, which is why "just use stack" isn't an answer to the problem:
> 
[--snip--]

Absolutely agreed that there is currently to "Right Answer"(TM) wrt.
Cabal or Stack. They do different things well/badly. Until we get a tool
that can do everything the schism will probably remain.

(And that's not even talking about issues like technical debt in each of
the code bases, etc.)

Anyway, just wanted to comment on a couple of points:

> - hpack-by-default pushes another reinvention of basic haskell tooling, and does so with YAML, which is a file format that gets worse the more you understand it. (I expect its defenders will say this is just providing an option, but from my experience onboarding new Hackage uploaders, many people do not realise that hpack is optional.)

My problem here is that Cabal hasn't provided some very useful the
features that YAML does out of the box, namely the ability to define
arbitrary snippets of package configuration and to refer to them from
multiple places. Examples:

If I maintain a cohesive set of 5 packages, I need to duplicate various
bits and bobs of information in 5 different places:

  - author info, license info
  - ghc options (I like to use identical options for all my packages in
a 'set')
  - dependency version ranges(!)

in 5 different cabal files. This is tedious at best and outright wrong
at worst (inconsistent version bounds). YAML lets me avoid that
annoyance -- yes, using entities and entity refs is a hackish way to do
it, but it *works*.

In no way am I advocating for YAML specifically. IMO, it's absurdly
complex to cater for the needs of <1% of its users. However, I do wish
Cabal could use some standardized format with similar capabilites for
avoiding duplication in a full *generic* way.

My problem with the cabal file format is that is basically entirely
ad-hoc, esp. wrt. what I can avoid repeating over and over.

(Dhall could work here since you can at least do inclusions and reuse in
a generic way. Plus it has fully defined semantics plus implementations
in at least a couple of langauges, Haskell and Scala.)

> - Many stack projects do not provide bounds on dependencies, relying on getting exact versions from LTS. This may be defensible for applications that sit at the leaves of a dependency graph, but less so for libraries. Accurate bound information is one of the reasons LTS build plans can be easily constructed, and tooling that encourages sloppy bounds feels to me like it encourages taking without giving back to the shared resource (the common set of libraries on Hackage with well-understood bounds).

I posit that at least a *part* of the problem here is tedium for
maintainers (see above), but while we're at it: I'm not sure manually
maintaining bounds is at all scalable nor particularly "correct" (for
lower bounds, esp.) unless one is *super*-vigilant about what bits of a
dependency are *actually* in use.

FWIW, I do try to do this for my packages, but I'm very confident that
all of my packages probably have misleading lower bounds.

It seems to me that some automated tooling is needed here, e.g. to try
building/testing with e.g. all deps at the lower bound, all deps at the
highest bound, etc.

Regards,


From ollie at ocharles.org.uk  Fri Dec 11 09:56:09 2020
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Fri, 11 Dec 2020 09:56:09 +0000
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <rqvfdd$265$1@ciao.gmane.io>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
Message-ID: <6ed06a1d-9a61-4153-b94d-18f0caedd02e@www.fastmail.com>

On Fri, 11 Dec 2020, at 9:50 AM, Bardur Arantsson wrote:
> (Dhall could work here since you can at least do inclusions and reuse in
> a generic way. Plus it has fully defined semantics plus implementations
> in at least a couple of langauges, Haskell and Scala.)

Psst https://hackage.haskell.org/package/dhall-to-cabal :)

I think the missing piece here is making a frontend that transparently turns Dhall to Cabal syntax and runs cabal-install, so you don't have to keep regenerating files.

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

From spam at scientician.net  Fri Dec 11 10:07:38 2020
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 11 Dec 2020 11:07:38 +0100
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <6ed06a1d-9a61-4153-b94d-18f0caedd02e@www.fastmail.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
 <6ed06a1d-9a61-4153-b94d-18f0caedd02e@www.fastmail.com>
Message-ID: <rqvgdf$2sh$1@ciao.gmane.io>

On 11/12/2020 10.56, Oliver Charles wrote:
> On Fri, 11 Dec 2020, at 9:50 AM, Bardur Arantsson wrote:
>> (Dhall could work here since you can at least do inclusions and reuse in
>> a generic way. Plus it has fully defined semantics plus implementations
>> in at least a couple of langauges, Haskell and Scala.)
> 
> Psst https://hackage.haskell.org/package/dhall-to-cabal
> <https://hackage.haskell.org/package/dhall-to-cabal> :)
> 

Yes, thank for pointing that out :). I think I actually tried it at one
point, but it was way to immature at the time... must have slipped my
mind since then.

IIRC my major problem at the time I tried it, it was also *really* slow.
I mean "minutes" rather than "seconds" slow.

I think that may have been due to performance problems in the Haskell
implementation of Dhall, so hopefully it's not an issue these days.

(It might also have been PEBKAC on my part, it's all a bit fuzzy...)

> I think the missing piece here is making a frontend that transparently
> turns Dhall to Cabal syntax and runs cabal-install, so you don't ha ve
> to keep regenerating files.
> 

That would be nice, but for large-scale adoption I think it probably
needs to actually be an *official* format and perhaps even be upstreamed
so that it gets maintained along with the Cabal format. (To account for
things that change semi-often like extension names, new cabal settings,
and whatnot.) Plus to know that it will be maintained well into the future.

Thanks for working on it, btw. Might give it a shop when I get tired of
hpack/YAML :).

Regards,


From ollie at ocharles.org.uk  Fri Dec 11 10:17:23 2020
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Fri, 11 Dec 2020 10:17:23 +0000
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <rqvgdf$2sh$1@ciao.gmane.io>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
 <6ed06a1d-9a61-4153-b94d-18f0caedd02e@www.fastmail.com>
 <rqvgdf$2sh$1@ciao.gmane.io>
Message-ID: <673cb17c-8746-4915-a046-31307df50267@www.fastmail.com>

On Fri, 11 Dec 2020, at 10:07 AM, Bardur Arantsson wrote:
> On 11/12/2020 10.56, Oliver Charles wrote:
> > On Fri, 11 Dec 2020, at 9:50 AM, Bardur Arantsson wrote:
> >> (Dhall could work here since you can at least do inclusions and reuse in
> >> a generic way. Plus it has fully defined semantics plus implementations
> >> in at least a couple of langauges, Haskell and Scala.)
> > 
> > Psst https://hackage.haskell.org/package/dhall-to-cabal
> > <https://hackage.haskell.org/package/dhall-to-cabal> :)
> > 
> 
> Yes, thank for pointing that out :). I think I actually tried it at one
> point, but it was way to immature at the time... must have slipped my
> mind since then.
> 
> IIRC my major problem at the time I tried it, it was also *really* slow.
> I mean "minutes" rather than "seconds" slow.
> 
> I think that may have been due to performance problems in the Haskell
> implementation of Dhall, so hopefully it's not an issue these days.

Yes, it was due to performance problems with Dhall itself. This project actually helped act as a benchmark for us to improve Dhall. I think things should be much better now. I have unfortunately all-but-abandoned the project because there are no users, including myself. But it's still there and I think there's still a lot of useful work there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201211/5335b574/attachment.html>

From Andrew.Butterfield at scss.tcd.ie  Fri Dec 11 10:23:18 2020
From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield)
Date: Fri, 11 Dec 2020 10:23:18 +0000
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
 Haskell)
Message-ID: <835DE4F9-112A-4DB8-A447-56F0AE0B3171@scss.tcd.ie>

Dear all

> On 11 Dec 2020, at 00:07, Henning Thielemann <lemming at henning-thielemann.de> wrote:

.... stuff elided

> So recursion looks to me as funtional programming's GOTO, and if it is tail recursive, it actually is one.

Yes, but it's "GOTO considered beneficial"  ;-)

Thanks to Zachi for asking the original question - I've already seen lots more ideas for me to chase up for my course!

Regards, and Happy Holidays,

  Andrew

> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
--------------------------------------------------------------------
Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
Lero at TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
                         http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------


From alexey.raga at gmail.com  Fri Dec 11 10:28:09 2020
From: alexey.raga at gmail.com (Alexey Raga)
Date: Fri, 11 Dec 2020 21:28:09 +1100
Subject: [Haskell-cafe] What features should an (fictitious) IDE for
 Haskell have?
In-Reply-To: <1F8EAAA7-FECC-465A-863C-ED8089C8726A@icloud.com>
References: <1F8EAAA7-FECC-465A-863C-ED8089C8726A@icloud.com>
Message-ID: <CACf4mn_MiZUTajOcZLABy3n7462o_q9OisyBj2Otbg9LNOvYaw@mail.gmail.com>

Managing modules in `.cabal` file is probably one of the most awaited
features from my side :)

Best Regards,
Alexey Raga


On Fri, Dec 11, 2020 at 8:34 PM Luke Lau via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> haskell-language-server recently got some basic integration with the
> retrie plugin, and can offer to do folding and unfolding:
> https://github.com/haskell/haskell-language-server/pull/266
>
> Luke Lau
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201211/c819aa31/attachment.html>

From agocorona at gmail.com  Fri Dec 11 10:35:37 2020
From: agocorona at gmail.com (Alberto G. Corona)
Date: Fri, 11 Dec 2020 11:35:37 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
Message-ID: <CAArEJmY8=KCsFqLiQVOYDYw8FaL+GU3J0cf1JiFM5cYM9EFx5g@mail.gmail.com>

I played some time ago with a "brute force" building tool which starts only
from the includes of the main source file. It tried to find the packages
for these modules using the google search service to search in Hackage,
download the package sources from Hackage and added the packages  as
options to the ghc -ipackage1 ipackage2   command line, recursively. If
some error happened I tried with the files of an older version for the
package that produced the error, by parsing the GHC errors. It failed at
some C import libraries but at this moment it can be switched to build in
cabal or stack mode for that package/module.

I write this just in case this gives some ideas to someone to go along
these lines.

Much of that is what Cabal does anyway, but constrained by the limits
imposed by the *.cabal files in the packages. But the machinery is there
Perhaps Cabal could have a --bruteforce  option?

El jue, 10 dic 2020 a las 12:25, Ignat Insarov (<kindaro at gmail.com>)
escribió:

> # Do something about Cabal?
>
> Hello.
>
> Cabal is the second most used tool in Haskell after GHC. It has many
> problems. It may be noticed that there is one and a half developers
> working on
> it. This is clearly not enough to address these problems. I propose that
> this is
> a good place to invest in.
>
> ### Problems I have in mind:
>
> * Poor communication, lack of open source development process.
>
>   The whole Cabal–Stack schism appears to be an outcome of poor
>   communication. One of the leading developers of Cabal is even banned from
>   participation somewhere in Stack circles.[1] Personally, I reported
> several
>   issues to Cabal and every single time it resulted in sadness. Observe a
>   vicious circle: core developers are overworked ⇒ they are being
> unfriendly ⇒
>   there are fewer contributors ⇒ core developers are overworked.
>
>   I have no hard evidence but it appears that presently, more people that
> strive
>   to improve the Haskell build experience are outside the Cabal cabal than
> are
>   inside.
>
> * User experience is an afterthought.
>
>   Cabal's user experience is horrifying. A collection of complaints is
> being
>   compiled elsewhere.[2] There are also bugs being opened to Cabal because
> of
>   this, requiring triage and therefore wasting the precious time of the few
>   overworked developers. Stack is much more friendly — this shows by
> example
>   that the user experience problem is not inherent and may be solved.
>
>   It is ordinary to receive output like this:
>
>   ```
>   % cabal run example-executable
>   Warning: The package list for 'hackage.haskell.org' is 84 days old.
>   Run 'cabal update' to get the latest list of available packages.
>   Resolving dependencies...
>   cabal: Could not resolve dependencies:
>   [__0] trying: example-0.1.0.6 (user goal)
>   [__1] next goal: opaleye (dependency of example)
>   [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from
> project
>   config TODO requires ==0.6.7006.1)
>   [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
>   [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0,
> opaleye-0.6.7004.2,
>   opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
>   opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
>   opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
>   opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
>   opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1,
> opaleye-0.3,
>   opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
>   opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that
> caused the
>   previous version to fail: excluded by constraint '^>=0.7' from example)
>   [__1] fail (backjumping, conflict set: example, opaleye)
>   After searching the rest of the dependency tree exhaustively, these were
> the
>   goals I've had most trouble fulfilling: opaleye, example
>   ```
>
>   There are so many things that are wrong here. Even a sneaky _«to do»_
>   remark. If you wonder, in this case the solution is to remove and
> re-generate
>   `cabal.project.freeze`.
>
>   Even the name of the program — it is actually _«cabal-install»_ — is
>   incomprehensible, it should be re-branded to Cabal, which is how everyone
>   calls it anyway.
>
> * Features are not being introduced.
>
>   There is no reason for two build tools to exist. The killer feature of
> Stack —
>   snapshots — should be supported by Cabal. Possibly Cabal itself should be
>   refactored and split so that there are separate tools for packaging,
> version
>   resolution and human interaction — I do not know. But certainly the way
> things
>   are presently is a waste of developer effort and a source of confusion
> for
>   everyone.
>
> ### My proposition, in particular.
>
> * Ask all the people that show compassion to the cause of a great Haskell
> build
>   tool to unite and work together on a better Cabal. This includes the
>   developers of Stack and everyone that expressed unhappiness with the
> current
>   state of Cabal. These people should be seen as a blessing, not as an
> obstacle.
> * Put in place a clear process for contributing and decision making, so
> that it
>   does not come down to the privileged opinion of one of the core
> developers.
> * Make a model of user experience that Cabal should conform to, and make
>   conformance a priority. Surely there are among us people that know a
> thing or
>   two about user experience — call for them to step forward. Every issue
> that
>   stems from misunderstanding, re-assign to the model instead of closing.
> * Merge the support of Stackage snapshots into Cabal. Ask the core
> developers of
>   Stack to join the effort. Transition from Stack to Cabal should be one
> well
>   discoverable command that just works.
>
> I realize that this letter is largely an opinion piece. You can also see
> it as
> an _«ideal piece»_. Without an ideal, without a vision, we are stuck with
> the
> present. I do not insist that my vision is the best. But the present
> reality is
> not the best vision either. I propose, foremost, that we work and fight
> for a
> better future.
>
> [1]: https://github.com/commercialhaskell/stackage/issues/4472
> [2]:
> https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



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

From jack at jackkelly.name  Fri Dec 11 11:38:23 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Fri, 11 Dec 2020 11:38:23 GMT
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <rqvfdd$265$1@ciao.gmane.io>
References: <rqvfdd$265$1@ciao.gmane.io>
 <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
Message-ID: <de5799c021cb26550e179dc1fd7d8c97@jackkelly.name>


December 11, 2020 7:50 PM, "Bardur Arantsson" <spam at scientician.net> wrote:

> On 10/12/2020 22.07, Jack Kelly via Haskell-Cafe wrote:
>
>> [snip]
>
> Absolutely agreed that there is currently to "Right Answer"(TM) wrt.
> Cabal or Stack. They do different things well/badly. Until we get a tool
> that can do everything the schism will probably remain.
> 
> (And that's not even talking about issues like technical debt in each of
> the code bases, etc.)

I'm glad my message was taken in the right way.

> My problem here is that Cabal hasn't provided some very useful the
> features that YAML does out of the box, namely the ability to define
> arbitrary snippets of package configuration and to refer to them from
> multiple places. Examples:
> 
> If I maintain a cohesive set of 5 packages, I need to duplicate various
> bits and bobs of information in 5 different places:
> 
> [snip things that really should be DRY'd up by a modern build tool]

While it does not solve the problem you have in full, common stanzas can at least help you de-duplicate ghc-options settings within a package. https://cabal.readthedocs.io/en/latest/cabal-package.html?#common-stanzas

A possible solution: allow cabal.project to set common entries across multiple packages, and have `cabal sdist` write them into the cabal file that goes into the tarball? This is just me spitballing, so there are probably problems that I haven't considered.

> This is tedious at best and outright wrong
> at worst (inconsistent version bounds).
> In no way am I advocating for YAML specifically.
> (Dhall could work here since you can at least do inclusions and reuse in
> a generic way. Plus it has fully defined semantics plus implementations
> in at least a couple of langauges, Haskell and Scala.)

I see that Oliver has already mentioned dhall-to-cabal . I'm a fan, but I'd be worried about bootstrappability if it became the main language of the main build tool.

>> - Many stack projects do not provide bounds on dependencies
> I posit that at least a *part* of the problem here is tedium for
> maintainers (see above), but while we're at it: I'm not sure manually
> maintaining bounds is at all scalable nor particularly "correct" (for
> lower bounds, esp.) unless one is *super*-vigilant about what bits of a
> dependency are *actually* in use.
> 
> FWIW, I do try to do this for my packages, but I'm very confident that
> all of my packages probably have misleading lower bounds.
> 
> It seems to me that some automated tooling is needed here, e.g. to try
> building/testing with e.g. all deps at the lower bound, all deps at the
> highest bound, etc.

No doubt. The only way to have a hope of doing this is with a CI matrix. https://github.com/haskell-CI/haskell-ci used to get some of the way there, but Travis CI recently yanked the rug out from under FOSS projects. I believe there is active work to make that repo support other CI systems. (More hands would probably help.)

A possible compromise for bounds: use ^>= bounds, raising the lower bound when you either a) need something from a new version, or b) move to a new major version? If you remain open to metadata revisions that relax the lower bound if needed, that might be OK? Again, spitballing, and I expect some kind soul to point out the flaws in this plan.

Best,

-- Jack

From speykious at gmail.com  Fri Dec 11 12:21:50 2020
From: speykious at gmail.com (Speykious)
Date: Fri, 11 Dec 2020 13:21:50 +0100
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
	Haskell)
In-Reply-To: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
Message-ID: <CA+0ksyafHctuxwsNd7Zcfw8uWhXSQ989yckK_-7XP_TjpVf+QA@mail.gmail.com>

OK, I realized that I forgot to reply all...
Really sorry about that! Here's a duplicate of my mail for everyone to see.

Hello,

I am a CS student in second year of bachelor's and a big fan of Haskell.
Currently in our courses, we learn about functional programming with OCaml,
which I believe to be a poor choice as an introduction in the paradigm. But
I learned about Haskell before all that mainly thanks to the internet, and
particularly YouTube which has some great audio-visual content for Haskell.

Thus, I have several ideas for projects that your students could do,
inspired and taken from various places, mainly the internet:

- implement a JSON parser (from scratch, without Parsec). Indeed, parsing
is a very functional process, and Haskell makes it way easier to do than
other languages as a consequence, especially with the use of typeclasses
and operators from the standard library.
The idea could be applied for other data formats such as YAML, TOML, or
even XML, although some are more difficult to implement than others.

- generate .wav files, a.k.a make music from scratch. There is a great
YouTube channel called Tsoding, and it has some truly amazing content. This
is where I got this idea from.
https://youtu.be/FYTZkE5BZ-0
By the way, he also implemented a JSON parser from scratch in Haskell and
made a video about it.

- create a library for ANSI color codes in the terminal, functions like
green, red and bold to color strings. This is how I started practicing
Haskell, and it gave me a good grasp at functional concepts such as
currying and function composition.

- Solve problems from the Advent of Code 2020 in Haskell. Some of them, and
I'm thinking particularly about day 7, seem to be very recursive problems;
but overall, I believe it will also help them to get their mind around
using maps, filters and folds instead of imperative loops. I also remember
seeing that somewhere, some professors already literally made their exam
question be something like "solve day X of the Advent of Code 20XX", which
I found to be hilarious and amazing!

- Besides the Advent of Code, there are also online challenging sites for
general coding, like Codewars.

I hope that my ideas have been useful and/or interesting. If I have any
other ones, I'll post them here.
As a last note, I'd like to share a YouTube channel: Philipp Hagenlocher,
who created a series entitles Haskell for Imperative Programmers, and which
aims at, well, explain Haskell for Imperative Programmers, as Haskell being
purely functional is a very powerful feature but difficult to grasp for
people who come from imperative programming languages (like I do).
https://youtube.com/channel/UC3xdLFFsqG701QAyGJIPT1g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201211/c34d771e/attachment.html>

From tittoassini at gmail.com  Fri Dec 11 12:48:20 2020
From: tittoassini at gmail.com (Pasqualino "Titto" Assini)
Date: Fri, 11 Dec 2020 13:48:20 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <de5799c021cb26550e179dc1fd7d8c97@jackkelly.name>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name> <rqvfdd$265$1@ciao.gmane.io>
 <de5799c021cb26550e179dc1fd7d8c97@jackkelly.name>
Message-ID: <CAGJQFvg+c-M_0o5Mbfm=pF8hWWcdSXio9sv1=XDVxz+9qtBknQ@mail.gmail.com>

I always wondered: do we need a package management system at all?

Putting aside for a second the problem of interfacing with C or other
external dependencies.

What about a system where every source file is automatically annotated with
a unique hash and all the required LANGUAGE extensions.


For example:

-- State explicitly any non-standard language extension
{-# LANGUAGE MultiParamTypeClasses ,PatternSynonyms ,RankNTypes #-}

-- Add to the module name its hash (calculated on its source contents,
ignoring comments)
module App.Main.K306f1981b41c

-- Import a module, specifying the exact version
import Data.Maybe.K306f1981823d

....

main: ...


Finally, we publish it on a shared content addressable system (hackage
like).


This module is in fact now a stand-alone mini-package that can be easily
built as it states all its dependencies in a non-ambiguous way:

lookMaNoPackages run App.Main.K306f1981b41c


The nice thing is that it could be done in a
completely backwards-compatible way, as it doesn't require any change to
the language itself.

And a modern tool like haskell-language-server could automate the
hashing/annotations making it convenient to use.

Would this work?


       titto


Il giorno ven 11 dic 2020 alle ore 12:40 Jack Kelly via Haskell-Cafe <
haskell-cafe at haskell.org> ha scritto:

>
> December 11, 2020 7:50 PM, "Bardur Arantsson" <spam at scientician.net>
> wrote:
>
> > On 10/12/2020 22.07, Jack Kelly via Haskell-Cafe wrote:
> >
> >> [snip]
> >
> > Absolutely agreed that there is currently to "Right Answer"(TM) wrt.
> > Cabal or Stack. They do different things well/badly. Until we get a tool
> > that can do everything the schism will probably remain.
> >
> > (And that's not even talking about issues like technical debt in each of
> > the code bases, etc.)
>
> I'm glad my message was taken in the right way.
>
> > My problem here is that Cabal hasn't provided some very useful the
> > features that YAML does out of the box, namely the ability to define
> > arbitrary snippets of package configuration and to refer to them from
> > multiple places. Examples:
> >
> > If I maintain a cohesive set of 5 packages, I need to duplicate various
> > bits and bobs of information in 5 different places:
> >
> > [snip things that really should be DRY'd up by a modern build tool]
>
> While it does not solve the problem you have in full, common stanzas can
> at least help you de-duplicate ghc-options settings within a package.
> https://cabal.readthedocs.io/en/latest/cabal-package.html?#common-stanzas
>
> A possible solution: allow cabal.project to set common entries across
> multiple packages, and have `cabal sdist` write them into the cabal file
> that goes into the tarball? This is just me spitballing, so there are
> probably problems that I haven't considered.
>
> > This is tedious at best and outright wrong
> > at worst (inconsistent version bounds).
> > In no way am I advocating for YAML specifically.
> > (Dhall could work here since you can at least do inclusions and reuse in
> > a generic way. Plus it has fully defined semantics plus implementations
> > in at least a couple of langauges, Haskell and Scala.)
>
> I see that Oliver has already mentioned dhall-to-cabal . I'm a fan, but
> I'd be worried about bootstrappability if it became the main language of
> the main build tool.
>
> >> - Many stack projects do not provide bounds on dependencies
> > I posit that at least a *part* of the problem here is tedium for
> > maintainers (see above), but while we're at it: I'm not sure manually
> > maintaining bounds is at all scalable nor particularly "correct" (for
> > lower bounds, esp.) unless one is *super*-vigilant about what bits of a
> > dependency are *actually* in use.
> >
> > FWIW, I do try to do this for my packages, but I'm very confident that
> > all of my packages probably have misleading lower bounds.
> >
> > It seems to me that some automated tooling is needed here, e.g. to try
> > building/testing with e.g. all deps at the lower bound, all deps at the
> > highest bound, etc.
>
> No doubt. The only way to have a hope of doing this is with a CI matrix.
> https://github.com/haskell-CI/haskell-ci used to get some of the way
> there, but Travis CI recently yanked the rug out from under FOSS projects.
> I believe there is active work to make that repo support other CI systems.
> (More hands would probably help.)
>
> A possible compromise for bounds: use ^>= bounds, raising the lower bound
> when you either a) need something from a new version, or b) move to a new
> major version? If you remain open to metadata revisions that relax the
> lower bound if needed, that might be OK? Again, spitballing, and I expect
> some kind soul to point out the flaws in this plan.
>
> Best,
>
> -- Jack
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Pasqualino "Titto" Assini
http://networkpolitics.svbtle.com
http://quid2.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201211/12c797cc/attachment.html>

From cdsmith at gmail.com  Fri Dec 11 12:55:07 2020
From: cdsmith at gmail.com (Chris Smith)
Date: Fri, 11 Dec 2020 07:55:07 -0500
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
	Haskell)
In-Reply-To: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
Message-ID: <CAPq5Pv+=nR0LQ7dTzQO9ytNCr-R9_2yFHt5XiN+cKNrOt7QYKw@mail.gmail.com>

Hi Zachi,

This is a really interesting project, and related to things I'm working
on.  Regardless of whether you take my advice, I'm very interested in
hearing how it goes.  Teaching Haskell at younger ages is something I care
deeply about.

Over the last nine years or so, I have built a web-based platform called
CodeWorld, which you might find useful for your class.  CodeWorld provides
two things:

- A way to get your students started quickly and easily in class, without
waiting for them to install GHC, Cabal/Stack, etc.
- An easy graphics and UI library with a purely functional style.  This
architecture, known by various crowds as "functional MVC", "the universe
model" (by the Racket community), "Glossy programs" (by Haskellers), or
most of "the Elm architecture" (by the Elm community) is a real gem of
functional programming education, and lets your students experience
declarative programming and build cooI things easily, without needing to
get bogged down in stuff like I/O, recursion, etc.

Putting these things together, I typically get 13-year-olds to write their
first working Haskell program and make creative choices about it on the
first day of school.

There are two ways to use CodeWorld:

1. https://code.world/haskell is basically Haskell in the web browser,
along with the purely functional graphics library
<https://hackage.haskell.org/package/codeworld-api> mentioned above.  A large
number of widely used Haskell packages
<https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal#L14>
are available for import, as well.

2. https://code.world is the same thing, but also using an educational
dialect of the language that I have found to be much easier for absolute
beginners to pick up and work with.  The main changes from standard Haskell
are that type classes are completely removed, all library functions are
uncurried, the compiler rejects certain error-prone things students do by
accident, and many of the error messages are rewritten.  The drawback,
though, is that while the code your students would write here is compiled
by GHC(JS), it's not "ordinary" Haskell, so your students wouldn't be able
to rely on other random learning resources from the Internet or use most
existing third-party libraries.  In their place, there is a somewhat
involved online Guide that introduces the language and standard
library, and both I myself and LSU's Gordon Cain Center have produced
different learning materials for ages ~ 13-17 years, tailored for this
educational dialect.  Happy to chat more or get you in touch with people
from the LSU team, if you are interested in going that route.

If CodeWorld isn't right for your class and you would prefer more
traditional Haskell tooling, I still recommend adopting the same graphics
architecture, and one way to do so is to use Gloss
<https://hackage.haskell.org/package/gloss>, a very well-known Haskell
implementation that's been around for ages and is widely used for
education, graphics demos, and more.

Let me know, and good luck!

Chris Smith

On Thu, Dec 10, 2020 at 4:59 PM Zachi Baharav <zachi at baharav.org> wrote:

> Dear mighty Haskell list,
>
> I am a high-school teacher in the US (California, Palo Alto). We have an
> advanced CS course that students can take after completing the AP-CS-A (in
> Java). This is usually Juniors and Seniors, after at least 2 or 3 courses
> of coding (Python+Java). Traditionally, I've done a potpourri of subjects,
> mostly search algorithms as applied to 'games'. Of course a little bit of
> data-structure comes in, and each year we did some 'other' interesting
> subject (like halftoning, barcodes, and so on) and investigated and
> implemented algorithms there.
>
> THIS year, for the second half, I would like us to do
> Functional-Programming. From what I have seen, my students over the years
> tend to write more and more convoluted codes, electing first to search on
> stackOverFlow for some similar pattern, rather than think and find a
> concise and clean solution. I think FP would supply them with a new way of
> thinking, which will help with whatever they will write later on.
>
> I've been coding with Haskell for about 7 years, so feel ok leading the
> class.
>
> The question: I have many books on Haskell (i think 'all', but who knows.
> Haskell, Real world Haskell, Learn you a haskell for great good,
> programming in haskell, and many more).
> --->  I am looking for something more hands-on and 'fun' for HS students.
> may i say the buzzword 'project based', or maybe better 'problem based' for
> our case.
> Something that I could teach a little, and then we can solve a bunch of
> problems, and teach a little more, and so on.
>
> It doesn't have to be a Book!!  Just an outline of a course someone did
> with associated bunch of problems would be awesome. We have 18 weeks in a
> semester. My thought right now (if I don't find anything) is to relyon
> Euler project early problems. These are often clean and simple in Haskell.
> Or otherwise some CSES problems (which we've done in Java).
>
> Ok, long enough email.
>
> If you have material and can share here, great!
> If you have material and want to reach out privately, please do (
> zbaharav at kehillah.org).
> If you have a good pointer, that would be appreciated.
>
> Thanks in advance for any help!
>    Zachi
> (Dr. Zachi Baharav, HS teacher  (after 20 years in Industry and academia))
>
>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201211/328adb69/attachment.html>

From speykious at gmail.com  Fri Dec 11 13:13:06 2020
From: speykious at gmail.com (Speykious)
Date: Fri, 11 Dec 2020 14:13:06 +0100
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
	Haskell)
In-Reply-To: <CAPq5Pv+=nR0LQ7dTzQO9ytNCr-R9_2yFHt5XiN+cKNrOt7QYKw@mail.gmail.com>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <CAPq5Pv+=nR0LQ7dTzQO9ytNCr-R9_2yFHt5XiN+cKNrOt7QYKw@mail.gmail.com>
Message-ID: <CA+0ksyaZ1+Ng3X5OB9aOhT18A1z6EfOr-kMRKxnRRociLGCbyw@mail.gmail.com>

Speaking about playground websites, I also know about https://repl.it/
which allows to write code and run it for several languages, including
Haskell. The great thing about this is that people can team up and see each
other modify the code in real time, which is perfect for student projects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201211/5f5e5cab/attachment.html>

From david.feuer at gmail.com  Fri Dec 11 13:21:19 2020
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 11 Dec 2020 08:21:19 -0500
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
	Haskell)
In-Reply-To: <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
Message-ID: <CAMgWh9sKiOj9wF6iR=oqs-PUR0z9_N+DVDuckCdZL0HnU+2HVw@mail.gmail.com>

On Thu, Dec 10, 2020, 6:58 PM Albert Y. C. Lai <trebla at vex.net> wrote:

> I think that the 99 Haskell Problems are an easy source of short exercises.
>

I think the 99 Haskell problems are mostly a *terrible* source of short
exercises. The problem is that they're exercises translated from Prolog and
Lisp. Some of them need substantial "translation" to even make sense in a
typed language. Others are problems designed to highlight features Haskell
doesn't have. Anyone looking to that list for inspiration will have to do a
*lot* of weeding to get something suitable for beginning students, and will
probably miss out on the opportunity to use more appropriate problems.

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

From jack at jackkelly.name  Fri Dec 11 13:25:01 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Fri, 11 Dec 2020 13:25:01 GMT
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
References: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
 <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
Message-ID: <805909cb81151c4722e6f7997c3dec17@jackkelly.name>


December 10, 2020 5:05 AM, "Emily Pillmore" <emilypi at cohomolo.gy> wrote:

> Correct me if I'm wrong here, because I've never seen anyone describe maps like this, but it seems
> to me that for an algebraic constraint `c`, `c g ⇒ Map k g` would be a `k`-graded c-structure, and
> we can think of algebraic operations applied to those `g` meaningfully in that sense. For example,
> an indexed-list where `Group a ⇒ [(Int, a)]` can be seen as a ℤ-graded group.
> 
> In your example, Jack, inversion is defined on a map by `fmap inverse ≣ inverse_k0 + inverse_k1 + …
> + inverse k_n`, componentwise for each key. So perhaps your problem here for maps, is equivalent to
> finding a nice indexed-group for structure for the types:
> 
> ```
> — | A functor indexed by a discrete category. Not to be confused with
> -- indexed as in higher functor on functor ala Atkey's Outrageous Fortune.
> — This is not the most general encoding.
> —
> 
> class GradedFunctor f where
>   imap :: (i → a → b) → f i a → f i b
> — Being a graded group requires that the "overall" structure be both an indexed functor,
> — as well as a group, so that `t i g = g_i0 + … + giN` forms a group as well.

I don't have the algebra knowledge to follow what you just wrote, but this class smells like FunctorWithIndex from `lens`, but I don't know how principled that class is.

My problem with maps is that if I want to stay with Group and the obvious elementwise inversion, I don't have a good answer for distinguishing `mempty` values at a particular key, vs the key not being present at all.

However, I'm quite confident that elementwise inversion gives you an Inverse Semigroup because inverses are unique. (I had previously mentioned that I thought you only had a Regular Semigroup, but I think that was an error.) The reason I believe this is that you can't make up "additional" inverses by adding mappings from some `k => mempty`. The type system stops you from choosing any particular `k`, and even if you could, you fail the requirement that `x <> inverse x <> x = x`

-- Jack

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Fri Dec 11 13:54:57 2020
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Fri, 11 Dec 2020 13:54:57 +0000
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAM1nAcwpjgHpb6OJuwOJSKeGz-13WYi0GYKoDW+s7dY36nvcZA@mail.gmail.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <887B1DEB-2611-4C3D-A0B1-AC93840B64DD@icloud.com>
 <CAM1nAcwpjgHpb6OJuwOJSKeGz-13WYi0GYKoDW+s7dY36nvcZA@mail.gmail.com>
Message-ID: <20201211135457.GL4433@cloudinit-builder>

On Fri, Dec 11, 2020 at 10:31:23AM +0100, Immanuel Litzroth wrote:
> I found the whole cabal experience confusing and not well documented.
> I kept finding blogs online
> that were not working anymore in my version of cabal

If you find outdated Haskell-related documentation please report it at

    https://github.com/tomjaguarpaw/tilapia/issues/new

and I shall try to do something about it.

Tom

From yasu at yasuaki.com  Fri Dec 11 10:09:19 2020
From: yasu at yasuaki.com (Yasuaki Kudo)
Date: Fri, 11 Dec 2020 19:09:19 +0900
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <6ed06a1d-9a61-4153-b94d-18f0caedd02e@www.fastmail.com>
References: <6ed06a1d-9a61-4153-b94d-18f0caedd02e@www.fastmail.com>
Message-ID: <2FA607DE-B662-4143-AB28-CBD409F5E85E@yasuaki.com>

Hi!

I have not done any serious programming in Haskell (although at some point I would love to 😄) , I am interested in this topic, because this is one of the first obstacles of using it...

I wonder if it's possible to appropriate GNU Guix as the distribution channel of many libraries.

I heard it is now an experimental package in Debian😄 https://packages.debian.org/experimental/guix

(FYI - After experimenting with both NixOS and Guix recently and I decided to favor Guix - but I notice Stack already has Integration with Nix?)

And here is the Guix packaging guide I found for Python
https://guix.gnu.org/manual/en/html_node/Python-Modules.html

Cheers,
Yasu


> On Dec 11, 2020, at 18:57, Oliver Charles <ollie at ocharles.org.uk> wrote:
> 
> 
>> On Fri, 11 Dec 2020, at 9:50 AM, Bardur Arantsson wrote:
>> (Dhall could work here since you can at least do inclusions and reuse in
>> a generic way. Plus it has fully defined semantics plus implementations
>> in at least a couple of langauges, Haskell and Scala.)
> 
> Psst https://hackage.haskell.org/package/dhall-to-cabal :)
> 
> I think the missing piece here is making a frontend that transparently turns Dhall to Cabal syntax and runs cabal-install, so you don't have to keep regenerating files.
> 
> Ollie
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201211/8ddbcb2e/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Fri Dec 11 15:09:38 2020
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Fri, 11 Dec 2020 15:09:38 +0000
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <20201211135457.GL4433@cloudinit-builder>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <887B1DEB-2611-4C3D-A0B1-AC93840B64DD@icloud.com>
 <CAM1nAcwpjgHpb6OJuwOJSKeGz-13WYi0GYKoDW+s7dY36nvcZA@mail.gmail.com>
 <20201211135457.GL4433@cloudinit-builder>
Message-ID: <20201211150938.GP4433@cloudinit-builder>

On Fri, Dec 11, 2020 at 01:54:57PM +0000, Tom Ellis wrote:
> On Fri, Dec 11, 2020 at 10:31:23AM +0100, Immanuel Litzroth wrote:
> > I found the whole cabal experience confusing and not well documented.
> > I kept finding blogs online
> > that were not working anymore in my version of cabal
> 
> If you find outdated Haskell-related documentation please report it at
> 
>     https://github.com/tomjaguarpaw/tilapia/issues/new

And on that point, I am tracking your particular issue with
https://www.haskell.org/cabal/ as

https://github.com/tomjaguarpaw/tilapia/issues/44

Tom

From jo at durchholz.org  Fri Dec 11 15:24:06 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 11 Dec 2020 16:24:06 +0100
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <rqvfdd$265$1@ciao.gmane.io>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
Message-ID: <bce4f7ee-5328-d521-3282-96c82016b236@durchholz.org>

Am 11.12.20 um 10:50 schrieb Bardur Arantsson:
> FWIW, I do try to do this for my packages, but I'm very confident that
> all of my packages probably have misleading lower bounds.
> 
> It seems to me that some automated tooling is needed here, e.g. to try
> building/testing with e.g. all deps at the lower bound, all deps at the
> highest bound, etc.

With indirect dependencies, you can run into combinatorial explosion 
problems (number of combinations is roughly exponential with dependency 
chain length, give or take a few orders of magnitude).

Just something to keep in mind when discussing design alternatives.
(I don't know what designs would even make sense, or what kinds of 
metadata would be available to help guide version selection.)

Regards,
Jo

From spam at scientician.net  Fri Dec 11 15:52:23 2020
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 11 Dec 2020 16:52:23 +0100
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <bce4f7ee-5328-d521-3282-96c82016b236@durchholz.org>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
 <bce4f7ee-5328-d521-3282-96c82016b236@durchholz.org>
Message-ID: <rr04jn$5ma$1@ciao.gmane.io>

On 11/12/2020 16.24, Joachim Durchholz wrote:
> Am 11.12.20 um 10:50 schrieb Bardur Arantsson:
>> FWIW, I do try to do this for my packages, but I'm very confident that
>> all of my packages probably have misleading lower bounds.
>>
>> It seems to me that some automated tooling is needed here, e.g. to try
>> building/testing with e.g. all deps at the lower bound, all deps at the
>> highest bound, etc.
> 
> With indirect dependencies, you can run into combinatorial explosion
> problems (number of combinations is roughly exponential with dependency
> chain length, give or take a few orders of magnitude).
> 
> Just something to keep in mind when discussing design alternatives.
> (I don't know what designs would even make sense, or what kinds of
> metadata would be available to help guide version selection.)
> 

Indeed, it's a difficult problem with no obvious solution, but given the
combinatorial explosion issue, it's probably better to (somehow) leave
it up to a computer to explore that space rather than humans. :)

Regards,


From fa-ml at ariis.it  Fri Dec 11 16:44:59 2020
From: fa-ml at ariis.it (Francesco Ariis)
Date: Fri, 11 Dec 2020 17:44:59 +0100
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
 Haskell)
In-Reply-To: <CAMgWh9sKiOj9wF6iR=oqs-PUR0z9_N+DVDuckCdZL0HnU+2HVw@mail.gmail.com>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
 <CAMgWh9sKiOj9wF6iR=oqs-PUR0z9_N+DVDuckCdZL0HnU+2HVw@mail.gmail.com>
Message-ID: <20201211164459.GB11918@extensa>

Il 11 dicembre 2020 alle 08:21 David Feuer ha scritto:
> I think the 99 Haskell problems are mostly a *terrible* source of short
> exercises. The problem is that they're exercises translated from Prolog and
> Lisp. Some of them need substantial "translation" to even make sense in a
> typed language. Others are problems designed to highlight features Haskell
> doesn't have. Anyone looking to that list for inspiration will have to do a
> *lot* of weeding to get something suitable for beginning students, and will
> probably miss out on the opportunity to use more appropriate problems.

Big smile.  When I started out, 99 Haskell problems were so useful to me;
easy enough to tackle them myself, lots of idiomatic solutions on the wiki
to check how things were properly done.

Some of them required additional bending to fit the problem into Haskell
way of doing things; only now I realise this was not a clever choice by
the editor but a consequence of the translation.

From jo at durchholz.org  Fri Dec 11 17:00:53 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 11 Dec 2020 18:00:53 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAGJQFvg+c-M_0o5Mbfm=pF8hWWcdSXio9sv1=XDVxz+9qtBknQ@mail.gmail.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
 <de5799c021cb26550e179dc1fd7d8c97@jackkelly.name>
 <CAGJQFvg+c-M_0o5Mbfm=pF8hWWcdSXio9sv1=XDVxz+9qtBknQ@mail.gmail.com>
Message-ID: <f35faee2-57ab-1225-7757-ed86bb0f1e2b@durchholz.org>

Am 11.12.20 um 13:48 schrieb Pasqualino "Titto" Assini:
> I always wondered: do we need a package management system at all?

The main reason package management became a thing is indirect dependencies.

Without package management: Pick up a dependency, manually hunt down 
everything that it depends on, then get the dependencies' dependencies, 
and you never know how many are there to come.
Lather, rinse, repeat with every update. Sometimes you'll need a 
completely new set of indirect dependencies after an update.

With package management, you specify the package you need and the 
package manager will do the rest.
It should also tell you what it pulled in.
If it's worth anything, you can tell it to use different dependencies; 
it's not a silver bullet that will solve your dependency 
incompatibilities for you, but it will give you a reasonable first 
approximation.

> What about a system where every source file is automatically annotated 
> with a unique hash and all the required LANGUAGE extensions.

Hashes are... difficult.

What you really want is a hash of the API you're using, possibly 
including nonfunctional properties. Problem is that it's really hard to 
even define the section of the API that you need - probably an unsolved 
problem, actually.

That's why people find semantic versioning so important.
Usually, you have some global namespace where legal entities reside 
(Java did something that turned out to be pretty smart: domain names are 
per-entity anyway), with each entity assigning module names within their 
namespace.
E.g. the owner of com.company manages com.company.module1, 
com.company.module2, etc.
A module is identified by (sub)domain name and version number, throw in 
some recommendations about how to apply semantic versioning, and people 
will stop using those modules that don't have a good versioning policy 
anyway... and you're done.

It's not perfect, but it works.

(Hashes are overspecific, and they don't help with the relationship 
between version 1.2 and 1.2.2 of a module.)

(Disclaimer: This is from the perspective of the Java ecosystem, 
slightly generalized. Semantic versioning may be less of an issue for 
functional languages than it has been and will be for imperative ones, 
so I don't expect this to carry over 1:1.)

From trebla at vex.net  Fri Dec 11 18:37:56 2020
From: trebla at vex.net (Albert Y. C. Lai)
Date: Fri, 11 Dec 2020 13:37:56 -0500
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <CAM1nAcwpjgHpb6OJuwOJSKeGz-13WYi0GYKoDW+s7dY36nvcZA@mail.gmail.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <887B1DEB-2611-4C3D-A0B1-AC93840B64DD@icloud.com>
 <CAM1nAcwpjgHpb6OJuwOJSKeGz-13WYi0GYKoDW+s7dY36nvcZA@mail.gmail.com>
Message-ID: <9bedfabc-5e4e-f514-696e-8e76ec063827@vex.net>

The correct URL to the up-to-date cabal user guide, since a couple of 
years ago or more, is:

cabal.readthedocs.io

In principle, someone could and should make a copy at 
www.haskell.org/cabal, but I don't know why it hasn't happened. Would be 
nice.

cabal sandboxing is being phased out.  Every blog on cabal sandboxing is 
out of date by definition.  Don't bother.

If your version of cabal-install is >= 3.0, when you issue "build" "run" 
etc they already mean v2-build, v2-run, etc.  I refer you to the correct 
up-to-date cabal user guide, chapter 5 "nix-style local builds", for its 
model.

I would not recommend spending time on the v1 model, unless you're a 
historian.

"new-" was a transitional alias to "v2-" during a past transitional 
period that can be safely ignored (unless you're a historian).

(Historians will remind me that the plan was, one day in the future, 
when the cabal devs introduce a 3rd model, the "new-" prefix will be 
revived again, this time aliasing to the 3rd model.  I say that people 
are so happy with the current 2nd model that it won't happen.)


On 2020-12-11 4:31 a.m., Immanuel Litzroth wrote:
> I found the whole cabal experience confusing and not well documented.
> I kept finding blogs online
> that were not working anymore in my version of cabal ('cabal sandbox
> init', 'cabal init --sandbox'...) when looking
> for advice. I still don't understand the whole v1-build, v2-build,
> new-build and build...
> The manual doesn't seem to have a decent conceptual overview of what
> the tool should do (e.g. an explanation
> of what sandboxing is supposed to achieve, or the 4 build command versions).
> Several of the links on this page https://www.haskell.org/cabal/  are dead
> https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/
> or refer to old versions:
> https://wiki.haskell.org/Upgrading_packages
> 
> This should not be construed as a critique of what has been achieved,
> but as honest feedback
> of my experience.
>> Innovation and advancing comes after competition, why shouldn't we embrace that wrt the tooling of Haskell? Duplication in efforts is a relative smaller problem IMHO.
> Well the competition has "go build" and cargo...
> And duplication of effort is a problem when there's not enough
> resources for even one decent build tool
> Immanuel
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 michael at orlitzky.com  Fri Dec 11 19:38:28 2020
From: michael at orlitzky.com (Michael Orlitzky)
Date: Fri, 11 Dec 2020 14:38:28 -0500
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <rr04jn$5ma$1@ciao.gmane.io>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
 <bce4f7ee-5328-d521-3282-96c82016b236@durchholz.org>
 <rr04jn$5ma$1@ciao.gmane.io>
Message-ID: <72400ec3-09f5-2ba9-1c3d-0cffb1c4d765@orlitzky.com>

On 12/11/20 10:52 AM, Bardur Arantsson wrote:
> 
> Indeed, it's a difficult problem with no obvious solution, but given the
> combinatorial explosion issue, it's probably better to (somehow) leave
> it up to a computer to explore that space rather than humans. :)
> 

I'm reminded of the headline from this Onion article:

https://www.theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1819576527

To fix dependency hell, you need only not cause it in the first place. 
You have to standardize the language and a useful bit of code that you 
dub the "standard library." Then anyone writing serious software in your 
language has to be careful not to break API compatibility, and to use 
semantic/libtool versioning when doing so is unavoidable. That's an O(n 
= number of packages) algorithm for detecting breakage because instead 
of detecting it in every consumer, you're _indicating_ it once.

This is what separates languages that a few people use to write software 
for themselves from the languages that a lot of people use to write 
software for others. If you don't cause yourself these problems in the 
first place, then you don't need a not-invented-here package manager, 
because you can pick up Nix or Gentoo prefix or Anaconda or whatever and 
simply plug it in. The same is true of build systems.

On the other hand, if you want to do something that you shouldn't be 
doing in the first place (living in Antarctica, climbing Mt. Everest, 
using a language that breaks itself on Tuesdays, etc.) then specialized 
tools are often necessary to bring the level of difficulty down from 
"impossible" to merely "really stupid."

From lemming at henning-thielemann.de  Fri Dec 11 19:48:07 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 11 Dec 2020 20:48:07 +0100 (CET)
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <72400ec3-09f5-2ba9-1c3d-0cffb1c4d765@orlitzky.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name> <rqvfdd$265$1@ciao.gmane.io>
 <bce4f7ee-5328-d521-3282-96c82016b236@durchholz.org>
 <rr04jn$5ma$1@ciao.gmane.io>
 <72400ec3-09f5-2ba9-1c3d-0cffb1c4d765@orlitzky.com>
Message-ID: <alpine.DEB.2.20.2012112046380.5971@sputnik>


On Fri, 11 Dec 2020, Michael Orlitzky wrote:

> To fix dependency hell, you need only not cause it in the first place. 
> You have to standardize the language and a useful bit of code that you 
> dub the "standard library." Then anyone writing serious software in your 
> language has to be careful not to break API compatibility, and to use 
> semantic/libtool versioning when doing so is unavoidable. That's an O(n 
> = number of packages) algorithm for detecting breakage because instead 
> of detecting it in every consumer, you're _indicating_ it once.

Isn't this, what we are doing currently? When developing a library we try 
to stay within a major version range as long as possible, but if we need a 
breaking change, we increase the major version and have to adapt depending 
packages.

From michael at orlitzky.com  Fri Dec 11 20:10:07 2020
From: michael at orlitzky.com (Michael Orlitzky)
Date: Fri, 11 Dec 2020 15:10:07 -0500
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <alpine.DEB.2.20.2012112046380.5971@sputnik>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
 <bce4f7ee-5328-d521-3282-96c82016b236@durchholz.org>
 <rr04jn$5ma$1@ciao.gmane.io>
 <72400ec3-09f5-2ba9-1c3d-0cffb1c4d765@orlitzky.com>
 <alpine.DEB.2.20.2012112046380.5971@sputnik>
Message-ID: <e747b47c-afaf-b662-8280-3cb0f9418744@orlitzky.com>

On 12/11/20 2:48 PM, Henning Thielemann wrote:
> 
> On Fri, 11 Dec 2020, Michael Orlitzky wrote:
> 
>> To fix dependency hell, you need only not cause it in the first place.
>> You have to standardize the language and a useful bit of code that you
>> dub the "standard library." Then anyone writing serious software in your
>> language has to be careful not to break API compatibility, and to use
>> semantic/libtool versioning when doing so is unavoidable. That's an O(n
>> = number of packages) algorithm for detecting breakage because instead
>> of detecting it in every consumer, you're _indicating_ it once.
> 
> Isn't this, what we are doing currently? When developing a library we try
> to stay within a major version range as long as possible, but if we need a
> breaking change, we increase the major version and have to adapt depending
> packages.
> 

Some Haskell packages are pretty good in that regard, but my list was in 
order of importance. There is no such thing as "Haskell" nowadays, only 
"what GHC is doing this week," and the same goes for the simulacrum of a 
standard library that we call "base". The fact that, say, Cryptonite, is 
maintained intelligently is not as helpful when you consider that the 
words the author has written can change their meanings at any time.

From migmit at gmail.com  Fri Dec 11 20:26:40 2020
From: migmit at gmail.com (MigMit)
Date: Fri, 11 Dec 2020 21:26:40 +0100
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <e747b47c-afaf-b662-8280-3cb0f9418744@orlitzky.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
 <bce4f7ee-5328-d521-3282-96c82016b236@durchholz.org>
 <rr04jn$5ma$1@ciao.gmane.io>
 <72400ec3-09f5-2ba9-1c3d-0cffb1c4d765@orlitzky.com>
 <alpine.DEB.2.20.2012112046380.5971@sputnik>
 <e747b47c-afaf-b662-8280-3cb0f9418744@orlitzky.com>
Message-ID: <2A53D63D-4C29-4EA3-BEA9-FC6BBC2CF748@gmail.com>

Thank you. That's exactly how I feel lately, but I couldn't phrase with that level of precision.

> On 11 Dec 2020, at 21:10, Michael Orlitzky <michael at orlitzky.com> wrote:
> 
> There is no such thing as "Haskell" nowadays, only "what GHC is doing this week,"


From tittoassini at gmail.com  Sat Dec 12 12:08:30 2020
From: tittoassini at gmail.com (Pasqualino "Titto" Assini)
Date: Sat, 12 Dec 2020 13:08:30 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <f35faee2-57ab-1225-7757-ed86bb0f1e2b@durchholz.org>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name> <rqvfdd$265$1@ciao.gmane.io>
 <de5799c021cb26550e179dc1fd7d8c97@jackkelly.name>
 <CAGJQFvg+c-M_0o5Mbfm=pF8hWWcdSXio9sv1=XDVxz+9qtBknQ@mail.gmail.com>
 <f35faee2-57ab-1225-7757-ed86bb0f1e2b@durchholz.org>
Message-ID: <CAGJQFvgXW3751qQ9_kUWE_xPT5eJGm1aN7LXXoe=KzaaOx-PJQ@mail.gmail.com>

I don't actually see the problem in producing a hash of the API you use.

It is simply the hash of the list of your imports.

Is this overspecific? In the sense that it is more restrictive than it
could be?

Yes, but at least you get reproducibility and a permanently working build.

Semantic versioning sounds good in theory and often works in practice, but
you are relying on the goodwill and the precision of the library maintainer
when both of these qualities are in short supply.

The advantage of using module-level hashes is that you:
* Avoid mistakes due to incorrect semantic versioning
* Get maximum flexibility, as you are exploding the 'package cage' and
accessing every file individually
* Avoid a lot of 'false incompatibilities', when for example you would like
to access a new version of a module in an upgraded package but you can't
upgrade because you depend on another package that declares to be
compatible only with the previous version of the package you want to
upgrade to even when it's not actually using the new module you are
interested in at all.

The inconvenience of hashes is that they are cumbersome to manage by hand,
but this can be automated.


In fact, the question is not really semantic versioning vs hash-versioning.
Both can be used at the module level as well as to the package level.

The question is if we can simplify the dependency management problem by
"going smaller", moving from a bunch of related modules (a package) as a
unit of code exchange to a single module.

In principle one could even go smaller, considering every function or data
type [1] as an independently sharable entity.

So, what is the optimal 'size' for code sharing: package, module, or entity?


Best,

            titto



[1]
This actually make a lot of sense if you are interested in cross-language
interoperability, see https://github.com/Quid2/zm for an example.

Il giorno ven 11 dic 2020 alle ore 18:02 Joachim Durchholz <jo at durchholz.org>
ha scritto:

> Am 11.12.20 um 13:48 schrieb Pasqualino "Titto" Assini:
> > I always wondered: do we need a package management system at all?
>
> The main reason package management became a thing is indirect dependencies.
>
> Without package management: Pick up a dependency, manually hunt down
> everything that it depends on, then get the dependencies' dependencies,
> and you never know how many are there to come.
> Lather, rinse, repeat with every update. Sometimes you'll need a
> completely new set of indirect dependencies after an update.
>
> With package management, you specify the package you need and the
> package manager will do the rest.
> It should also tell you what it pulled in.
> If it's worth anything, you can tell it to use different dependencies;
> it's not a silver bullet that will solve your dependency
> incompatibilities for you, but it will give you a reasonable first
> approximation.
>
> > What about a system where every source file is automatically annotated
> > with a unique hash and all the required LANGUAGE extensions.
>
> Hashes are... difficult.
>
> What you really want is a hash of the API you're using, possibly
> including nonfunctional properties. Problem is that it's really hard to
> even define the section of the API that you need - probably an unsolved
> problem, actually.
>
> That's why people find semantic versioning so important.
> Usually, you have some global namespace where legal entities reside
> (Java did something that turned out to be pretty smart: domain names are
> per-entity anyway), with each entity assigning module names within their
> namespace.
> E.g. the owner of com.company manages com.company.module1,
> com.company.module2, etc.
> A module is identified by (sub)domain name and version number, throw in
> some recommendations about how to apply semantic versioning, and people
> will stop using those modules that don't have a good versioning policy
> anyway... and you're done.
>
> It's not perfect, but it works.
>
> (Hashes are overspecific, and they don't help with the relationship
> between version 1.2 and 1.2.2 of a module.)
>
> (Disclaimer: This is from the perspective of the Java ecosystem,
> slightly generalized. Semantic versioning may be less of an issue for
> functional languages than it has been and will be for imperative ones,
> so I don't expect this to carry over 1:1.)
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Pasqualino "Titto" Assini
http://networkpolitics.svbtle.com
http://quid2.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201212/33d8e598/attachment.html>

From lemming at henning-thielemann.de  Sat Dec 12 12:20:41 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 12 Dec 2020 13:20:41 +0100 (CET)
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAGJQFvgXW3751qQ9_kUWE_xPT5eJGm1aN7LXXoe=KzaaOx-PJQ@mail.gmail.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name> <rqvfdd$265$1@ciao.gmane.io>
 <de5799c021cb26550e179dc1fd7d8c97@jackkelly.name>
 <CAGJQFvg+c-M_0o5Mbfm=pF8hWWcdSXio9sv1=XDVxz+9qtBknQ@mail.gmail.com>
 <f35faee2-57ab-1225-7757-ed86bb0f1e2b@durchholz.org>
 <CAGJQFvgXW3751qQ9_kUWE_xPT5eJGm1aN7LXXoe=KzaaOx-PJQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2012121316310.7114@sputnik>


On Sat, 12 Dec 2020, Pasqualino "Titto" Assini wrote:

> I don't actually see the problem in producing a hash of the API you use.
> It is simply the hash of the list of your imports.
> 
> Is this overspecific? In the sense that it is more restrictive than it could be?

How do you address with a hash that added identifiers in an imported 
module do not harm if you import qualified or explicitly?

How do you address changed type of an imported variable?

From tittoassini at gmail.com  Sat Dec 12 13:06:04 2020
From: tittoassini at gmail.com (Pasqualino "Titto" Assini)
Date: Sat, 12 Dec 2020 14:06:04 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <alpine.DEB.2.20.2012121316310.7114@sputnik>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name> <rqvfdd$265$1@ciao.gmane.io>
 <de5799c021cb26550e179dc1fd7d8c97@jackkelly.name>
 <CAGJQFvg+c-M_0o5Mbfm=pF8hWWcdSXio9sv1=XDVxz+9qtBknQ@mail.gmail.com>
 <f35faee2-57ab-1225-7757-ed86bb0f1e2b@durchholz.org>
 <CAGJQFvgXW3751qQ9_kUWE_xPT5eJGm1aN7LXXoe=KzaaOx-PJQ@mail.gmail.com>
 <alpine.DEB.2.20.2012121316310.7114@sputnik>
Message-ID: <CAGJQFvhW0dpbqysWYHABXvEwpv+bun2kWC0DJ1jywfgOF9-Wdg@mail.gmail.com>

Il giorno sab 12 dic 2020 alle ore 13:20 Henning Thielemann <
lemming at henning-thielemann.de> ha scritto:

>
> On Sat, 12 Dec 2020, Pasqualino "Titto" Assini wrote:
>
> > I don't actually see the problem in producing a hash of the API you use.
> > It is simply the hash of the list of your imports.
> >
> > Is this overspecific? In the sense that it is more restrictive than it
> could be?
>
> How do you address with a hash that added identifiers in an imported
> module do not harm if you import qualified or explicitly?
>
> How do you address changed type of an imported variable?


The hash is obviously calculated on a normalised version of the module.

As part of this normalisation step, all references to external definitions
are fully qualified.

And it is impossible to import a variable with a changed type, because if
the type had changed so would have its definition and therefore the hash of
the imported module.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201212/56d53806/attachment.html>

From jo at durchholz.org  Sat Dec 12 14:22:03 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Sat, 12 Dec 2020 15:22:03 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAGJQFvhW0dpbqysWYHABXvEwpv+bun2kWC0DJ1jywfgOF9-Wdg@mail.gmail.com>
References: <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <rqvfdd$265$1@ciao.gmane.io>
 <de5799c021cb26550e179dc1fd7d8c97@jackkelly.name>
 <CAGJQFvg+c-M_0o5Mbfm=pF8hWWcdSXio9sv1=XDVxz+9qtBknQ@mail.gmail.com>
 <f35faee2-57ab-1225-7757-ed86bb0f1e2b@durchholz.org>
 <CAGJQFvgXW3751qQ9_kUWE_xPT5eJGm1aN7LXXoe=KzaaOx-PJQ@mail.gmail.com>
 <alpine.DEB.2.20.2012121316310.7114@sputnik>
 <CAGJQFvhW0dpbqysWYHABXvEwpv+bun2kWC0DJ1jywfgOF9-Wdg@mail.gmail.com>
Message-ID: <39cb4235-e672-13c3-81f6-f22bf17878e8@durchholz.org>

> The hash is obviously calculated on a normalised version of the module.
> 
> As part of this normalisation step, all references to external 
> definitions are fully qualified.
> 
> And it is impossible to import a variable with a changed type, 
> because if the type had changed so would have its definition and 
> therefore the hash of the imported module.

The normalization is actually the important point here.
It's easy to come up with something that works reasonably, for some 
definition of "reasonably".

Normalization can be too narrow (throw away relevant information) or too 
wide (leave in irrelevant information).
Problem is, it's the library user that defines what parts of a library 
are of interest to the use case.
Or, more specifically: What parts of a library's *semantics*.

Most users care only about specific properties of the library functions 
they use.
E.g. for a function that returns a list, some care about order and some 
don't.
Some stuff may not even be properly expressible, like side-channel data 
leakage in a crypto hash function, or legal constraints you don't want 
to care about but have to.
More on the programming sides, type bounds may become tighter or less 
tight. And even a less tight type bound can cause trouble (because your 
code might have to deal with less tight type bounds on results, for 
example - or you might be in a situation where you want to allow your 
own callers to pass in looser-constrained data - or maybe you do not 
want that because your own code depends on these bounds). And sometimes 
the type bounds need to be explicit because type inference isn't good 
enough, so you can't fully leave that to automation.

So... hashes are good for checking for equality, but you want to express 
inequalities, otherwise your clients will have to recheck the full API 
with every upgrade.
(Sure, with Haskell, this is much less of a problem than usual. But it 
won't go away.)

From emilypi at cohomolo.gy  Sun Dec 13 03:49:54 2020
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Sun, 13 Dec 2020 03:49:54 +0000
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <805909cb81151c4722e6f7997c3dec17@jackkelly.name>
References: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
 <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
 <805909cb81151c4722e6f7997c3dec17@jackkelly.name>
Message-ID: <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>

Actually, I was planning on implementing it with `FunctorWithIndex` lmao 😂

> 
> but I don't know how principled that class is.
> 
> 

I haven't thought about this in depth enough to triple check this, but I do think the class is principled. My mental model for it is "structures that can be decomposed in terms of graded objects ( https://ncatlab.org/nlab/show/graded+set ) ",  that is, `FunctorWithIndex` is a functor `C^J → D` from the category of J-graded objects of C to some other category `D`. Such a functor should take a mapping of graded objects `i → (a → b)` to a mapping `f a → f b` in D. This gets you the signature described in the class:   `imap :: (i → a → b) → (f a → f b)`.

> 
> My problem with maps is that if I want to stay with Group and the obvious
> elementwise inversion, I don't have a good answer for distinguishing
> `mempty` values at a particular key, vs the key not being present at all.
> 
> 

This brings up a good point about sparsity. It's probably a good idea from a resource perspective to consider inserting mempty as he identity on the structure, and it raises an interesting point about how often you should simplify by delete mempty elements if you don't conflate it. Either way, I think you'll be forced to pick up an additional `Eq` constraint on the values, which may not be ideal.

> 
> The reason I believe this is that you can't make up "additional" inverses
> by adding mappings from some `k => mempty`. The type system stops you from
> choosing any particular `k`, and even if you could, you fail the
> requirement that `x <> inverse x <> x = x`
> 
> 

Do you mind expanding on this? i don't quite get what you're saying here.

Cheers,

E

On Fri, Dec 11, 2020 at 8:25 AM, < jack at jackkelly.name > wrote:

> 
> 
> 
> December 10, 2020 5:05 AM, "Emily Pillmore" < emilypi@ cohomolo. gy (
> emilypi at cohomolo.gy ) > wrote:
> 
> 
>> 
>> 
>> Correct me if I'm wrong here, because I've never seen anyone describe maps
>> like this, but it seems to me that for an algebraic constraint `c`, `c g ⇒
>> Map k g` would be a `k`-graded c-structure, and we can think of algebraic
>> operations applied to those `g` meaningfully in that sense. For example,
>> an indexed-list where `Group a ⇒ [(Int, a)]` can be seen as a ℤ-graded
>> group.
>> 
>> 
>> 
>> In your example, Jack, inversion is defined on a map by `fmap inverse ≣
>> inverse_k0 + inverse_k1 + …
>> + inverse k_n`, componentwise for each key. So perhaps your problem here
>> for maps, is equivalent to finding a nice indexed-group for structure for
>> the types:
>> 
>> 
>> 
>> ```
>> — | A functor indexed by a discrete category. Not to be confused with
>> -- indexed as in higher functor on functor ala Atkey's Outrageous Fortune.
>> 
>> — This is not the most general encoding.
>> —
>> 
>> 
>> 
>> class GradedFunctor f where
>> imap :: (i → a → b) → f i a → f i b
>> — Being a graded group requires that the "overall" structure be both an
>> indexed functor,
>> — as well as a group, so that `t i g = g_i0 + … + giN` forms a group as
>> well.
>> 
>> 
> 
> 
> 
> I don't have the algebra knowledge to follow what you just wrote, but this
> class smells like FunctorWithIndex from `lens`, but I don't know how
> principled that class is.
> 
> 
> 
> My problem with maps is that if I want to stay with Group and the obvious
> elementwise inversion, I don't have a good answer for distinguishing
> `mempty` values at a particular key, vs the key not being present at all.
> 
> 
> 
> However, I'm quite confident that elementwise inversion gives you an
> Inverse Semigroup because inverses are unique. (I had previously mentioned
> that I thought you only had a Regular Semigroup, but I think that was an
> error.) The reason I believe this is that you can't make up "additional"
> inverses by adding mappings from some `k => mempty`. The type system stops
> you from choosing any particular `k`, and even if you could, you fail the
> requirement that `x <> inverse x <> x = x`
> 
> 
> 
> -- Jack
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201213/61a32f1c/attachment.html>

From carter.schonwald at gmail.com  Sun Dec 13 05:19:18 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 13 Dec 2020 00:19:18 -0500
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>
References: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
 <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
 <805909cb81151c4722e6f7997c3dec17@jackkelly.name>
 <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>
Message-ID: <CAHYVw0zmxXhVDcsMgL4ZOCpoC3qqoPx+hcOu0PuzEZAss3STCA@mail.gmail.com>

Having a decidable equality seems important for reasoning about groups.  Or
computing on representations thereof.

On Sat, Dec 12, 2020 at 10:52 PM Emily Pillmore <emilypi at cohomolo.gy> wrote:

> Actually, I was planning on implementing it with `FunctorWithIndex` lmao [image:
> 😂]
>
> but I don't know how principled that class is.
>
>
> I haven't thought about this in depth enough to triple check this, but I
> do think the class is principled. My mental model for it is "structures
> that can be decomposed in terms of graded objects
> <https://ncatlab.org/nlab/show/graded+set>",  that is, `FunctorWithIndex`
> is a functor `C^J → D` from the category of J-graded objects of C to some
> other category `D`. Such a functor should take a mapping of graded objects
> `i → (a → b)` to a mapping `f a → f b` in D. This gets you the signature
> described in the class:   `imap :: (i → a → b) → (f a → f b)`.
>
> My problem with maps is that if I want to stay with Group and the obvious
> elementwise inversion, I don't have a good answer for distinguishing
> `mempty` values at a particular key, vs the key not being present at all.
>
>
> This brings up a good point about sparsity. It's probably a good idea from
> a resource perspective to consider inserting mempty as he identity on the
> structure, and it raises an interesting point about how often you should
> simplify by delete mempty elements if you don't conflate it. Either way, I
> think you'll be forced to pick up an additional `Eq` constraint on the
> values, which may not be ideal.
>
> The reason I believe this is that you can't make up "additional" inverses
> by adding mappings from some `k => mempty`. The type system stops you from
> choosing any particular `k`, and even if you could, you fail the
> requirement that `x <> inverse x <> x = x`
>
>
> Do you mind expanding on this? i don't quite get what you're saying here.
>
> Cheers,
> E
>
>
>
>
>
>
>
>
> On Fri, Dec 11, 2020 at 8:25 AM, <jack at jackkelly.name> wrote:
>
>> December 10, 2020 5:05 AM, "Emily Pillmore" <emilypi at cohomolo.gy> wrote:
>>
>> Correct me if I'm wrong here, because I've never seen anyone describe
>> maps like this, but it seems to me that for an algebraic constraint `c`, `c
>> g ⇒ Map k g` would be a `k`-graded c-structure, and we can think of
>> algebraic operations applied to those `g` meaningfully in that sense. For
>> example, an indexed-list where `Group a ⇒ [(Int, a)]` can be seen as a
>> ℤ-graded group.
>>
>> In your example, Jack, inversion is defined on a map by `fmap inverse ≣
>> inverse_k0 + inverse_k1 + …
>> + inverse k_n`, componentwise for each key. So perhaps your problem here
>> for maps, is equivalent to finding a nice indexed-group for structure for
>> the types:
>>
>> ```
>> — | A functor indexed by a discrete category. Not to be confused with
>> -- indexed as in higher functor on functor ala Atkey's Outrageous
>> Fortune.
>> — This is not the most general encoding.
>> —
>>
>> class GradedFunctor f where
>> imap :: (i → a → b) → f i a → f i b
>> — Being a graded group requires that the "overall" structure be both an
>> indexed functor,
>> — as well as a group, so that `t i g = g_i0 + … + giN` forms a group as
>> well.
>>
>> I don't have the algebra knowledge to follow what you just wrote, but
>> this class smells like FunctorWithIndex from `lens`, but I don't know how
>> principled that class is.
>>
>> My problem with maps is that if I want to stay with Group and the obvious
>> elementwise inversion, I don't have a good answer for distinguishing
>> `mempty` values at a particular key, vs the key not being present at all.
>>
>> However, I'm quite confident that elementwise inversion gives you an
>> Inverse Semigroup because inverses are unique. (I had previously mentioned
>> that I thought you only had a Regular Semigroup, but I think that was an
>> error.) The reason I believe this is that you can't make up "additional"
>> inverses by adding mappings from some `k => mempty`. The type system stops
>> you from choosing any particular `k`, and even if you could, you fail the
>> requirement that `x <> inverse x <> x = x`
>>
>> -- Jack
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201213/1581487b/attachment.html>

From ietf-dane at dukhovni.org  Sun Dec 13 05:39:58 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 13 Dec 2020 00:39:58 -0500
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <CAHYVw0zmxXhVDcsMgL4ZOCpoC3qqoPx+hcOu0PuzEZAss3STCA@mail.gmail.com>
References: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
 <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
 <805909cb81151c4722e6f7997c3dec17@jackkelly.name>
 <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>
 <CAHYVw0zmxXhVDcsMgL4ZOCpoC3qqoPx+hcOu0PuzEZAss3STCA@mail.gmail.com>
Message-ID: <X9WpLnPg5Wh+QIMZ@straasha.imrryr.org>

On Sun, Dec 13, 2020 at 12:19:18AM -0500, Carter Schonwald wrote:

> Having a decidable equality seems important for reasoning about groups.  Or
> computing on representations thereof.

This is of course not always possible.  If a group is presented as a
quotient of a free group on a set of generators via some set of
relators, then deciding whether two words are equal is IIRC known to be
generally intractable.  One can still perform the group operation, but
there is no known terminating algorithm for constructing a canonical
form for an element, performing equality tests, ...

Of course one might take the view that groups where equality is not
computable are not "useful", but that might rule out some applications.

-- 
    Viktor.

From zemyla at gmail.com  Sun Dec 13 06:49:49 2020
From: zemyla at gmail.com (Zemyla)
Date: Sun, 13 Dec 2020 00:49:49 -0600
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <X9WpLnPg5Wh+QIMZ@straasha.imrryr.org>
References: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
 <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
 <805909cb81151c4722e6f7997c3dec17@jackkelly.name>
 <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>
 <CAHYVw0zmxXhVDcsMgL4ZOCpoC3qqoPx+hcOu0PuzEZAss3STCA@mail.gmail.com>
 <X9WpLnPg5Wh+QIMZ@straasha.imrryr.org>
Message-ID: <CAK7nUjjC6MXr0yWji2r0Pf=GrFe78h=01DuHeqYf_BBoTTKgVw@mail.gmail.com>

A simpler example of groups with no computable equality: the Sum group on
computable reals. x + negate x === 0 for all x, but we can never fully
prove it, only demonstrate it for each number of digits. And yet this is a
perfectly well behaved abelian group.

On Sat, Dec 12, 2020, 23:41 Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:

> On Sun, Dec 13, 2020 at 12:19:18AM -0500, Carter Schonwald wrote:
>
> > Having a decidable equality seems important for reasoning about groups.
> Or
> > computing on representations thereof.
>
> This is of course not always possible.  If a group is presented as a
> quotient of a free group on a set of generators via some set of
> relators, then deciding whether two words are equal is IIRC known to be
> generally intractable.  One can still perform the group operation, but
> there is no known terminating algorithm for constructing a canonical
> form for an element, performing equality tests, ...
>
> Of course one might take the view that groups where equality is not
> computable are not "useful", but that might rule out some applications.
>
> --
>     Viktor.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201213/7fd48b69/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Sun Dec 13 14:26:13 2020
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Sun, 13 Dec 2020 15:26:13 +0100
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
	Haskell)
Message-ID: <5301d13b-211f-21b5-568c-328f0a443622@htwk-leipzig.de>

Hi.

Teaching is a topic that I do care about, and spend a lot of time on.
I want to underline two points that Chris Smith made
in his message about the ideas behind "Code World".
I am speaking from current experience in teaching
an "Intro to CS" course for non-CS students
("Informatik" on https://imweb.imn.htwk-leipzig.de/~waldmann/lehre.html)


>  easy graphics and UI library with a purely functional style.
> ... lets your students experience declarative programming
> and build cooI things easily, without needing to
> get bogged down in stuff like I/O [...] etc.

So much this! Have some basic pictures (rectangle, circle),
combinators "row" (besides) and "column" (above),
with some basic transformations. This will get students started
with the algebraic method (description in the term algebra,
evaluation in the domain algebra). I gave homework
"produce pictures that resemble letters, traffic signs, etc."

Does not need fancy graphics at all - I looked at the "diagrams"
package but then decided to go with rectangular black/white
pictures only. These restrictions make the "draw a sign"
exercise more interesting. And after all, CS is about abstraction.
It also allows me to connect to Boolean operations
(combine pictures of identical sizes with point-wise Nand, etc.)
that are treated in the lecture as well.


> get bogged down in stuff like [...] recursion, etc.

Again, yes! For my current course, I indeed think
that primitive recursion (that is, iteration) is quite enough.
E.g., students can draw a chess board from a single white square
by flipping the color, and iterated composition.
(Of course a CS major should know about the halting problem -
but only to avoid it when programming. A non-CS major shouldn't
write programs at all.)


Advertisment: So I made an experimental "sub-Haskell" language
(with online interpreter, integrated into an auto-grading system)
(source currently at
https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/tree/661-programmable-graphics/collection/src/Let
- I should break it out)

with drastically restricted features
* just one type (Pictures)
* "let" but it's not "letrec" - definitions cannot be recursive
* functions  but they must be named (no lambdas)
* strict evaluation (except for if-then-else which is hard-coded)
* just one hard-wired higher order functions:
  iterate :: (a -> a) -> Nat -> a -> a
* well, here I need Nat, and for if-then-else I need Bool,
  so that's the other two domain types besides Picture
* formal parameters of functions must have a type declaration
* extensive tracing of evaluation
* and   check(For)  for property-based testing
* code with with holes, where students  have to fill in the holes,
  but cannot change anything outside.

I can switch off some features (e.g., no functions, or, just unary)
and I can switch the underlying domain: instead of pictures,
can use sequences (it's not too much of a difference,
a sequence is just a one-dimensional picture).
I will use this for showing (one method of) compression:
find a short straight-line program that produces a given string.

Also I was thinking of introducing the "music" domain
(scores/performances as in Haskore/Euterpea) but I am
undecided about the best way of rendering MIDI in the browser
(without 3rd-party JS, see below). Perhaps it doesn't have
to be rendered (just print the events) as CS is about abstraction ...


So while I try to stay in a Haskell subset (syntactically and
semantically) the goal is not to teach some concrete
programming language but algebraic/structural thinking.
That is, mathematical thinking. Not "computational thinking" -
because there is no such thing. If it works, it *is* mathematical...


- J.W.


NB:  another necessary goal of an "intro to all things
computer/computing" course is to make students aware of the
surveillance economy. Fits nicely in the "computer networks" chapter.

> ... get your students started quickly and easily in class,
> without waiting for them to install GHC, Cabal/Stack, etc.

Yes. That's hard even for CS majors. Well and for me as well.

I normally provide software installed in the computer pool, but ..
cf. https://github.com/haskell/cabal/issues/7172

Of course "the browser is the OS" is what Evil Corp
wants students and teachers to think ..

From carter.schonwald at gmail.com  Sun Dec 13 15:56:33 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 13 Dec 2020 10:56:33 -0500
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <CAK7nUjjC6MXr0yWji2r0Pf=GrFe78h=01DuHeqYf_BBoTTKgVw@mail.gmail.com>
References: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
 <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
 <805909cb81151c4722e6f7997c3dec17@jackkelly.name>
 <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>
 <CAHYVw0zmxXhVDcsMgL4ZOCpoC3qqoPx+hcOu0PuzEZAss3STCA@mail.gmail.com>
 <X9WpLnPg5Wh+QIMZ@straasha.imrryr.org>
 <CAK7nUjjC6MXr0yWji2r0Pf=GrFe78h=01DuHeqYf_BBoTTKgVw@mail.gmail.com>
Message-ID: <CAHYVw0xKohWpSwh1Ef=foo5oBEMnw1z0UADUAWdaiyE5sgwdug@mail.gmail.com>

Absolutely.

I do think that the moment you start caring about representations or
presentations, as I believe emily has mentioned, some stronger assumptions
for certain families of interfaces is worth considering to allow for cool
stuff when those assumptions are admissible.

On Sun, Dec 13, 2020 at 1:51 AM Zemyla <zemyla at gmail.com> wrote:

> A simpler example of groups with no computable equality: the Sum group on
> computable reals. x + negate x === 0 for all x, but we can never fully
> prove it, only demonstrate it for each number of digits. And yet this is a
> perfectly well behaved abelian group.
>
> On Sat, Dec 12, 2020, 23:41 Viktor Dukhovni <ietf-dane at dukhovni.org>
> wrote:
>
>> On Sun, Dec 13, 2020 at 12:19:18AM -0500, Carter Schonwald wrote:
>>
>> > Having a decidable equality seems important for reasoning about
>> groups.  Or
>> > computing on representations thereof.
>>
>> This is of course not always possible.  If a group is presented as a
>> quotient of a free group on a set of generators via some set of
>> relators, then deciding whether two words are equal is IIRC known to be
>> generally intractable.  One can still perform the group operation, but
>> there is no known terminating algorithm for constructing a canonical
>> form for an element, performing equality tests, ...
>>
>> Of course one might take the view that groups where equality is not
>> computable are not "useful", but that might rule out some applications.
>>
>> --
>>     Viktor.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201213/cc66d227/attachment.html>

From carter.schonwald at gmail.com  Sun Dec 13 19:59:31 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 13 Dec 2020 14:59:31 -0500
Subject: [Haskell-cafe] heres a replacement CI template using gh actions:
 Psa : perhaps time for maintainers to start migrating off Travis ci
In-Reply-To: <CAHYVw0zCcXr2f6OyhH1acxuwqH0VcpSbqAtnX0iUNvp4F1bY5g@mail.gmail.com>
References: <CAHYVw0zCcXr2f6OyhH1acxuwqH0VcpSbqAtnX0iUNvp4F1bY5g@mail.gmail.com>
Message-ID: <CAHYVw0w0iONdtwc25e33e7vnz_qe_api5uQFHmtF2vFJqChvxA@mail.gmail.com>

https://github.com/cartazio/ralist/blob/495c3dcb3a8e16a693a97a415f731907549aa615/.github/workflows/hs-matrix.yml
is my current iteration

On Mon, Nov 16, 2020 at 1:02 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Hey everyone: it looks like, from my perspective and experiences, that
> Travis ci should perhaps now be viewed as not open source friendly. Or even
> converging on hostile?
>
> 1) crazy long queue times/ latency for oss ci actions to run
>
> 2) very low concurrency on oss builds.
>
> 3) very low build build  minute caps for oss that require high touch
> customer support contact to adjust.
>
> I’ve started moving my own projects slowly to gh actions for now, though
> there’s also gitlab ci , src hut and other options that may suit different
> folks.
>
> There’s definitely some ways to keep on having the clever cabal caching we
> know and love that folks like the Haskell-ci folks and others have hacked
> out for Travis be available on other platforms, though I don’t think
> there’s consolidated docs for those yet ?  Def seen it discussed though.
>
> https://github.com/haskell-CI/haskell-ci/issues/411
>
> Heres a url to my dupe ticket where I share an example naive use of the
> setup Haskell gh actions Config, definitely not perfect. But kinda amazing
> to have Mac and Linux and windows ci all in one ! :)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201213/ddd13a49/attachment.html>

From jo at durchholz.org  Sun Dec 13 22:52:20 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 13 Dec 2020 23:52:20 +0100
Subject: [Haskell-cafe] heres a replacement CI template using gh
 actions: Psa : perhaps time for maintainers to start migrating off Travis
 ci
In-Reply-To: <CAHYVw0w0iONdtwc25e33e7vnz_qe_api5uQFHmtF2vFJqChvxA@mail.gmail.com>
References: <CAHYVw0zCcXr2f6OyhH1acxuwqH0VcpSbqAtnX0iUNvp4F1bY5g@mail.gmail.com>
 <CAHYVw0w0iONdtwc25e33e7vnz_qe_api5uQFHmtF2vFJqChvxA@mail.gmail.com>
Message-ID: <5636d4c3-8b77-3b32-0fde-1443c20bdea0@durchholz.org>

Not wanting to dishearten you, but Github *was* acquired by Microsoft, 
and that company has changed policy more often than I have appendages to 
count.
Which means that replacing a Travis workflow with a Github workflow 
isn't improving anything, it's merely another station on the CI 
caravan's route.

Gitlab *is* publishing large parts of their server-side code. Set up a 
local test installation, make sure that CI automation runs there, then 
migrate to Gitlab - that's the strategy I'd choose, YMMV.

Gitlab may become FOSS-unfriendly over time just like any other 
commercial entity, but their barrier is significantly higher: The will 
loser more users and faster if they try anything funny with their 
policy, because then people will just run their own servers. Their 
current policy is a bit of a "we promise to remain FOSS-friendly, 
because, see? - we're locking ourselves in your corner" plot, and of 
course me advertising this is exactly what they want to achieve :-)

DISCLAIMER: I am NOT affiliated with Gitlab in any way.
Or with any other commercial entity offering services to the open-source 
community.

Regards,
Jo

Am 13.12.20 um 20:59 schrieb Carter Schonwald:
> https://github.com/cartazio/ralist/blob/495c3dcb3a8e16a693a97a415f731907549aa615/.github/workflows/hs-matrix.yml  
> is my current iteration
> 
> On Mon, Nov 16, 2020 at 1:02 PM Carter Schonwald 
> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
> 
>     Hey everyone: it looks like, from my perspective and experiences,
>     that Travis ci should perhaps now be viewed as not open source
>     friendly. Or even converging on hostile?
> 
>     1) crazy long queue times/ latency for oss ci actions to run
> 
>     2) very low concurrency on oss builds.
> 
>     3) very low build build  minute caps for oss that require high touch
>     customer support contact to adjust.
> 
>     I’ve started moving my own projects slowly to gh actions for now,
>     though there’s also gitlab ci , src hut and other options that may
>     suit different folks.
> 
>     There’s definitely some ways to keep on having the clever cabal
>     caching we know and love that folks like the Haskell-ci folks and
>     others have hacked out for Travis be available on other platforms,
>     though I don’t think there’s consolidated docs for those yet ?  Def
>     seen it discussed though.
> 
>     https://github.com/haskell-CI/haskell-ci/issues/411
> 
>     Heres a url to my dupe ticket where I share an example naive use of
>     the setup Haskell gh actions Config, definitely not perfect. But
>     kinda amazing to have Mac and Linux and windows ci all in one ! :)
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
> 


From carter.schonwald at gmail.com  Sun Dec 13 23:00:19 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 13 Dec 2020 18:00:19 -0500
Subject: [Haskell-cafe] heres a replacement CI template using gh
 actions: Psa : perhaps time for maintainers to start migrating off Travis
 ci
In-Reply-To: <5636d4c3-8b77-3b32-0fde-1443c20bdea0@durchholz.org>
References: <CAHYVw0zCcXr2f6OyhH1acxuwqH0VcpSbqAtnX0iUNvp4F1bY5g@mail.gmail.com>
 <CAHYVw0w0iONdtwc25e33e7vnz_qe_api5uQFHmtF2vFJqChvxA@mail.gmail.com>
 <5636d4c3-8b77-3b32-0fde-1443c20bdea0@durchholz.org>
Message-ID: <CAHYVw0xCUHJSoXUTNaa50ZdVHPdfJOLNqn5dgwKjutiivHusgQ@mail.gmail.com>

If you’re volunteering to do the legwork to have easy peasy ci setup for
me, I graciously accept!

Otherwise I don’t see how this critique is advancing a constructive
dialogue. Your suggestions aren’t concretely actionable for me given finite
time.

If you choose to do some community organizing to advance this approach
you’re advocating, I look forward to using it.  Else it’s just putting down
something I’m sharing in the open in hopes it has use for other folks.

Happy holidays!
-Carter

On Sun, Dec 13, 2020 at 5:53 PM Joachim Durchholz <jo at durchholz.org> wrote:

> Not wanting to dishearten you, but Github *was* acquired by Microsoft,
> and that company has changed policy more often than I have appendages to
> count.
> Which means that replacing a Travis workflow with a Github workflow
> isn't improving anything, it's merely another station on the CI
> caravan's route.
>
> Gitlab *is* publishing large parts of their server-side code. Set up a
> local test installation, make sure that CI automation runs there, then
> migrate to Gitlab - that's the strategy I'd choose, YMMV.
>
> Gitlab may become FOSS-unfriendly over time just like any other
> commercial entity, but their barrier is significantly higher: The will
> loser more users and faster if they try anything funny with their
> policy, because then people will just run their own servers. Their
> current policy is a bit of a "we promise to remain FOSS-friendly,
> because, see? - we're locking ourselves in your corner" plot, and of
> course me advertising this is exactly what they want to achieve :-)
>
> DISCLAIMER: I am NOT affiliated with Gitlab in any way.
> Or with any other commercial entity offering services to the open-source
> community.
>
> Regards,
> Jo
>
> Am 13.12.20 um 20:59 schrieb Carter Schonwald:
> >
> https://github.com/cartazio/ralist/blob/495c3dcb3a8e16a693a97a415f731907549aa615/.github/workflows/hs-matrix.yml
>
> > is my current iteration
> >
> > On Mon, Nov 16, 2020 at 1:02 PM Carter Schonwald
> > <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
> >
> >     Hey everyone: it looks like, from my perspective and experiences,
> >     that Travis ci should perhaps now be viewed as not open source
> >     friendly. Or even converging on hostile?
> >
> >     1) crazy long queue times/ latency for oss ci actions to run
> >
> >     2) very low concurrency on oss builds.
> >
> >     3) very low build build  minute caps for oss that require high touch
> >     customer support contact to adjust.
> >
> >     I’ve started moving my own projects slowly to gh actions for now,
> >     though there’s also gitlab ci , src hut and other options that may
> >     suit different folks.
> >
> >     There’s definitely some ways to keep on having the clever cabal
> >     caching we know and love that folks like the Haskell-ci folks and
> >     others have hacked out for Travis be available on other platforms,
> >     though I don’t think there’s consolidated docs for those yet ?  Def
> >     seen it discussed though.
> >
> >     https://github.com/haskell-CI/haskell-ci/issues/411
> >
> >     Heres a url to my dupe ticket where I share an example naive use of
> >     the setup Haskell gh actions Config, definitely not perfect. But
> >     kinda amazing to have Mac and Linux and windows ci all in one ! :)
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view 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/20201213/2fa65fdf/attachment.html>

From raoknz at gmail.com  Mon Dec 14 00:25:26 2020
From: raoknz at gmail.com (Richard O'Keefe)
Date: Mon, 14 Dec 2020 13:25:26 +1300
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
	Haskell)
In-Reply-To: <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <9e652229-7c6a-854b-97e2-d8358f06f237@vex.net>
Message-ID: <CABcYAdLcwsNe7A-Fvt1eC88ZWnJB0nUOXv2yOpvhk02b=6tzfw@mail.gmail.com>

You can find "ML for the Working Programmer" on-line at
https://b-ok.global/book/540620/dbb55f
Supposedly this is legal.

On Fri, 11 Dec 2020 at 13:00, Albert Y. C. Lai <trebla at vex.net> wrote:

> I think that the 99 Haskell Problems are an easy source of short exercises.
>
> https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems
>
> For longer, well-motivated problems, I think of the long-running
> examples in textbooks, for example the Countdown chapter in Hutton's
> Programming in Haskell.
>
> If you can find/borrow Lawrence Paulson's ML for The Working Programmer,
> it has a list of suggested projects near the end.  Don't worry about how
> that book is on ML rather than Haskell, most of its exercises and
> projects are good for Haskell too.  In fact, enjoy this sentence from
> the book: "This sort of thing is easier in Haskell". :)
>
> And now a dark turn---every silver lining has tarnish.
>
> FP does not change people from writing convoluted borrowed code to
> original simple code.  I saw this in my students, their only difference
> from your dis they are in university.  Everything you said about having
> gone through Python and Java, fishing for answers on Stackoverflow, and
> making a mess, is just as true of my students.  And to think that
> they're university students, yes.
>
> In fact, it may be even worse, now that recursion is compulsory.  People
> distrust recursion, they will think up all kinds of crazy schemes to
> micromanage code execution, rather than just letting recursion do its job.
>
> In fact, even worse when the language is Haskell instead of SML and
> OCaml, because of "how do I print debugging output?"
>
>
> On 2020-12-10 4:55 p.m., Zachi Baharav wrote:
> > Dear mighty Haskell list,
> >
> > I am a high-school teacher in the US (California, Palo Alto). We have an
> > advanced CS course that students can take after completing the AP-CS-A
> > (in Java). This is usually Juniors and Seniors, after at least 2 or 3
> > courses of coding (Python+Java). Traditionally, I've done a potpourri of
> > subjects, mostly search algorithms as applied to 'games'. Of course a
> > little bit of data-structure comes in, and each year we did some 'other'
> > interesting subject (like halftoning, barcodes, and so on) and
> > investigated and implemented algorithms there.
> >
> > THIS year, for the second half, I would like us to do
> > Functional-Programming. From what I have seen, my students over the
> > years tend to write more and more convoluted codes, electing first to
> > search on stackOverFlow for some similar pattern, rather than think and
> > find a concise and clean solution. I think FP would supply them with a
> > new way of thinking, which will help with whatever they will write later
> on.
> >
> > I've been coding with Haskell for about 7 years, so feel ok leading the
> > class.
> >
> > The question: I have many books on Haskell (i think 'all', but who
> > knows.  Haskell, Real world Haskell, Learn you a haskell for great good,
> > programming in haskell, and many more).
> > --->  I am looking for something more hands-on and 'fun' for HS
> > students. may i say the buzzword 'project based', or maybe better
> > 'problem based' for our case.
> > Something that I could teach a little, and then we can solve a bunch of
> > problems, and teach a little more, and so on.
> >
> > It doesn't have to be a Book!!  Just an outline of a course someone did
> > with associated bunch of problems would be awesome. We have 18 weeks in
> > a semester. My thought right now (if I don't find anything) is to relyon
> > Euler project early problems. These are often clean and simple in
> > Haskell.  Or otherwise some CSES problems (which we've done in Java).
> >
> > Ok, long enough email.
> >
> > If you have material and can share here, great!
> > If you have material and want to reach out privately, please do
> > (zbaharav at kehillah.org <mailto:zbaharav at kehillah.org>).
> > If you have a good pointer, that would be appreciated.
> >
> > Thanks in advance for any help!
> >     Zachi
> > (Dr. Zachi Baharav, HS teacher  (after 20 years in Industry and
> academia))
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view 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/20201214/22cc69db/attachment.html>

From vamchale at gmail.com  Mon Dec 14 20:01:31 2020
From: vamchale at gmail.com (Vanessa McHale)
Date: Mon, 14 Dec 2020 14:01:31 -0600
Subject: [Haskell-cafe] Compilers written in Haskell that generate assembly
Message-ID: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>

Hi all,

Have any of you written compilers or backends that generate assembly? 
Lots of projects seem to "end" at LLVM.

I have a project (https://hackage.haskell.org/package/kempe) where I 
used something like maximal munch and a linear register allocator, but I 
was wondering if there was anything more sophisticated out there!

So far I've found http://hackage.haskell.org/package/linearscan-hoopl also

Cheers,
Vanessa McHale


From lemming at henning-thielemann.de  Mon Dec 14 20:05:42 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 14 Dec 2020 21:05:42 +0100 (CET)
Subject: [Haskell-cafe] Compilers written in Haskell that generate
 assembly
In-Reply-To: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>
References: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>
Message-ID: <alpine.DEB.2.20.2012142104270.6163@sputnik>


On Mon, 14 Dec 2020, Vanessa McHale wrote:

> Have any of you written compilers or backends that generate assembly? 
> Lots of projects seem to "end" at LLVM.

I don't know of compiler backends, but I know of an x86 machine code 
generator:
    https://hackage.haskell.org/package/harpy

From vamchale at gmail.com  Mon Dec 14 20:07:52 2020
From: vamchale at gmail.com (Vanessa McHale)
Date: Mon, 14 Dec 2020 14:07:52 -0600
Subject: [Haskell-cafe] Compilers written in Haskell that generate
 assembly
In-Reply-To: <alpine.DEB.2.20.2012142104270.6163@sputnik>
References: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>
 <alpine.DEB.2.20.2012142104270.6163@sputnik>
Message-ID: <5e170612-181d-70ef-368e-2a882aa79ace@gmail.com>

That I stumbled across! I like it, though I've put off learning about 
assemblers...

On 12/14/20 2:05 PM, Henning Thielemann wrote:
>
> On Mon, 14 Dec 2020, Vanessa McHale wrote:
>
>> Have any of you written compilers or backends that generate assembly? 
>> Lots of projects seem to "end" at LLVM.
>
> I don't know of compiler backends, but I know of an x86 machine code 
> generator:
>    https://hackage.haskell.org/package/harpy

From sjcjoosten+haskell at gmail.com  Mon Dec 14 20:53:18 2020
From: sjcjoosten+haskell at gmail.com (Sebastiaan Joosten)
Date: Mon, 14 Dec 2020 15:53:18 -0500
Subject: [Haskell-cafe] Compilers written in Haskell that generate
	assembly
In-Reply-To: <5e170612-181d-70ef-368e-2a882aa79ace@gmail.com>
References: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>
 <alpine.DEB.2.20.2012142104270.6163@sputnik>
 <5e170612-181d-70ef-368e-2a882aa79ace@gmail.com>
Message-ID: <CABhTcUu+tADaxeFUO=mUtEnNaGk83WZowkf8aWsVjzBhaVQpdQ@mail.gmail.com>

Not something I've worked on (my answer to your original question is 'no I
haven't'), but GHC has a compiler from 'CMM' to various assemblies written
in Haskell
Code at:
https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/
https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/X86/CodeGen.hs

(I used to think that LLVM was the last step in GHC. I don't know when or
how I ever got that idea. Last year I learned that it only uses LLVM if you
tell it to and it bypasses it completely with the default `-fasm' option
<https://downloads.haskell.org/~ghc/8.10.2/docs/html/users_guide/codegens.html>.
In
any case, my own earlier misconception is why I felt the need to point out
what is perhaps obvious to most.)

Sebastiaan

On Mon, Dec 14, 2020 at 3:09 PM Vanessa McHale <vamchale at gmail.com> wrote:

> That I stumbled across! I like it, though I've put off learning about
> assemblers...
>
> On 12/14/20 2:05 PM, Henning Thielemann wrote:
> >
> > On Mon, 14 Dec 2020, Vanessa McHale wrote:
> >
> >> Have any of you written compilers or backends that generate assembly?
> >> Lots of projects seem to "end" at LLVM.
> >
> > I don't know of compiler backends, but I know of an x86 machine code
> > generator:
> >    https://hackage.haskell.org/package/harpy
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201214/fe90545a/attachment.html>

From dennis.raddle at gmail.com  Mon Dec 14 21:08:55 2020
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Mon, 14 Dec 2020 13:08:55 -0800
Subject: [Haskell-cafe] error: ghcide must be compiled with same GHC version
	as the project
Message-ID: <CAKxLvordDGaQhgXvkrtwmhAjx4_Y14r8Nm+4ULEY9pwbkg_VhA@mail.gmail.com>

I'm trying to use the Haskell extension with VS Code which, is my
understanding, uses ghcide.

When I built ghcide, I had the resolver in the stack.yaml set to
"nightly-2020-09-02".
Associated with this is GHC 8.10.2.

When I first created my project I had the resolver set to something like
lts-14.20. Associated with this is GHC something like 8.6.5.

Later I changed my project resolver to nightly-2020-09-02, same as ghcide.
But I'm still getting this error.

Perhaps I haven't properly rebuilt my project using the new resolver?

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

From carter.schonwald at gmail.com  Mon Dec 14 21:48:08 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 14 Dec 2020 16:48:08 -0500
Subject: [Haskell-cafe] Compilers written in Haskell that generate
	assembly
In-Reply-To: <CABhTcUu+tADaxeFUO=mUtEnNaGk83WZowkf8aWsVjzBhaVQpdQ@mail.gmail.com>
References: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>
 <alpine.DEB.2.20.2012142104270.6163@sputnik>
 <5e170612-181d-70ef-368e-2a882aa79ace@gmail.com>
 <CABhTcUu+tADaxeFUO=mUtEnNaGk83WZowkf8aWsVjzBhaVQpdQ@mail.gmail.com>
Message-ID: <CAHYVw0zpgJ5Kqk87DYSYa6NVNZ4dc-+=d1HtNujKqjieUn7ZKQ@mail.gmail.com>

I do genuinely think it’s actually a great piece of code to shamelessly
copy out and use for your own needs.  It doesn’t even really dictate any
RTS assumptions or anything. By and large ;)

On Mon, Dec 14, 2020 at 3:55 PM Sebastiaan Joosten <
sjcjoosten+haskell at gmail.com> wrote:

> Not something I've worked on (my answer to your original question is 'no I
> haven't'), but GHC has a compiler from 'CMM' to various assemblies written
> in Haskell
> Code at:
> https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/
>
> https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/X86/CodeGen.hs
>
> (I used to think that LLVM was the last step in GHC. I don't know when or
> how I ever got that idea. Last year I learned that it only uses LLVM if you
> tell it to and it bypasses it completely with the default `-fasm' option
> <https://downloads.haskell.org/~ghc/8.10.2/docs/html/users_guide/codegens.html>. In
> any case, my own earlier misconception is why I felt the need to point out
> what is perhaps obvious to most.)
>
>
> Sebastiaan
>
> On Mon, Dec 14, 2020 at 3:09 PM Vanessa McHale <vamchale at gmail.com> wrote:
>
>> That I stumbled across! I like it, though I've put off learning about
>> assemblers...
>>
>> On 12/14/20 2:05 PM, Henning Thielemann wrote:
>> >
>> > On Mon, 14 Dec 2020, Vanessa McHale wrote:
>> >
>> >> Have any of you written compilers or backends that generate assembly?
>> >> Lots of projects seem to "end" at LLVM.
>> >
>> > I don't know of compiler backends, but I know of an x86 machine code
>> > generator:
>> >    https://hackage.haskell.org/package/harpy
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20201214/8881c303/attachment.html>

From siddu.druid at gmail.com  Tue Dec 15 16:56:32 2020
From: siddu.druid at gmail.com (Siddharth Bhat)
Date: Tue, 15 Dec 2020 22:26:32 +0530
Subject: [Haskell-cafe] Compilers written in Haskell that generate
	assembly
In-Reply-To: <CAHYVw0zpgJ5Kqk87DYSYa6NVNZ4dc-+=d1HtNujKqjieUn7ZKQ@mail.gmail.com>
References: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>
 <alpine.DEB.2.20.2012142104270.6163@sputnik>
 <5e170612-181d-70ef-368e-2a882aa79ace@gmail.com>
 <CABhTcUu+tADaxeFUO=mUtEnNaGk83WZowkf8aWsVjzBhaVQpdQ@mail.gmail.com>
 <CAHYVw0zpgJ5Kqk87DYSYa6NVNZ4dc-+=d1HtNujKqjieUn7ZKQ@mail.gmail.com>
Message-ID: <CAPipc=0Kn9qrt1pCD7XGDs5WUDELRcxL38dqmOvnRqMGMmcndw@mail.gmail.com>

This might be of interest: It's a tiny optimizing compiler which generates
MIPS asm. It runs end-to-end, I think: simple programs can be tested using
`nasm`:

https://github.com/bollu/tiny-optimising-compiler

Best,
~Siddharth


On Tue, Dec 15, 2020 at 3:20 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> I do genuinely think it’s actually a great piece of code to shamelessly
> copy out and use for your own needs.  It doesn’t even really dictate any
> RTS assumptions or anything. By and large ;)
>
> On Mon, Dec 14, 2020 at 3:55 PM Sebastiaan Joosten <
> sjcjoosten+haskell at gmail.com> wrote:
>
>> Not something I've worked on (my answer to your original question is 'no
>> I haven't'), but GHC has a compiler from 'CMM' to various assemblies
>> written in Haskell
>> Code at:
>> https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/
>>
>> https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/X86/CodeGen.hs
>>
>> (I used to think that LLVM was the last step in GHC. I don't know when or
>> how I ever got that idea. Last year I learned that it only uses LLVM if you
>> tell it to and it bypasses it completely with the default `-fasm' option
>> <https://downloads.haskell.org/~ghc/8.10.2/docs/html/users_guide/codegens.html>. In
>> any case, my own earlier misconception is why I felt the need to point out
>> what is perhaps obvious to most.)
>>
>>
>> Sebastiaan
>>
>> On Mon, Dec 14, 2020 at 3:09 PM Vanessa McHale <vamchale at gmail.com>
>> wrote:
>>
>>> That I stumbled across! I like it, though I've put off learning about
>>> assemblers...
>>>
>>> On 12/14/20 2:05 PM, Henning Thielemann wrote:
>>> >
>>> > On Mon, 14 Dec 2020, Vanessa McHale wrote:
>>> >
>>> >> Have any of you written compilers or backends that generate assembly?
>>> >> Lots of projects seem to "end" at LLVM.
>>> >
>>> > I don't know of compiler backends, but I know of an x86 machine code
>>> > generator:
>>> >    https://hackage.haskell.org/package/harpy
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view 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.



-- 
https://bollu.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201215/ae661bf9/attachment.html>

From twilson at csufresno.edu  Tue Dec 15 22:05:13 2020
From: twilson at csufresno.edu (Todd Wilson)
Date: Tue, 15 Dec 2020 14:05:13 -0800
Subject: [Haskell-cafe] Question on optimization
Message-ID: <CA+-99o+FEBNe6LTS0YKyJw3_mmavV-AyhGGGtSuCfOeLPMSbWw@mail.gmail.com>

Dear Cafe,

In code of the form
    case as ++ bs of
      [] -> ...
      x:xs -> ...
under what circumstances is the overhead of cons-cell creation for the
elements of `as` that would happen in an eager language avoided?
Always? Is the answer the same if `f` is defined by simple list
recursion and we call `f (as ++ bs)`? What if `f` is defined in a
different module (or comes from the Prelude)?

I know that questions of this type can be answered in specific cases
by looking at the (intermediate) code generated by the compiler, but
more generally, are there some succinct principles that everyday
programmers can hang on their cubicle walls that summarize a lot of
what they can expect from the compiler in terms of optimizations?

Todd Wilson

From jo at durchholz.org  Tue Dec 15 22:29:34 2020
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 15 Dec 2020 23:29:34 +0100
Subject: [Haskell-cafe] heres a replacement CI template using gh
 actions: Psa : perhaps time for maintainers to start migrating off Travis
 ci
In-Reply-To: <CAHYVw0xCUHJSoXUTNaa50ZdVHPdfJOLNqn5dgwKjutiivHusgQ@mail.gmail.com>
References: <CAHYVw0zCcXr2f6OyhH1acxuwqH0VcpSbqAtnX0iUNvp4F1bY5g@mail.gmail.com>
 <CAHYVw0w0iONdtwc25e33e7vnz_qe_api5uQFHmtF2vFJqChvxA@mail.gmail.com>
 <5636d4c3-8b77-3b32-0fde-1443c20bdea0@durchholz.org>
 <CAHYVw0xCUHJSoXUTNaa50ZdVHPdfJOLNqn5dgwKjutiivHusgQ@mail.gmail.com>
Message-ID: <de9fb2c2-1b84-498c-f340-9bec8b8b278a@durchholz.org>

Am 14.12.20 um 00:00 schrieb Carter Schonwald:
> If you’re volunteering to do the legwork to have easy peasy ci setup for 
> me, I graciously accept!

I have to politely decline.

> Otherwise I don’t see how this critique is advancing a constructive 
> dialogue.

Somebody with enough time may decide to give Gitlab a spin that might 
have been unaware.
So yes it is constructive. Just not in a direction that helps you - but 
now you do have to accept hat people may pursue different strategies 
than yours, do you?

 > Your suggestions aren’t concretely actionable for me given
> finite time.

Neither is your suggestion that I do the legwork.

> If you choose to do some community organizing to advance this approach 
> you’re advocating, I look forward to using it.  Else it’s just putting 
> down something I’m sharing in the open in hopes it has use for other folks.

Temporary solution or not, your work is certainly going to be better 
than nothing at all!
So feel free to go ahead. (Well, you are free to do whatever you like 
anyway, I have no say at all in what you do or what you consider best ;-) )

Regards,
Jo

From cma at bitemyapp.com  Tue Dec 15 22:34:53 2020
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 15 Dec 2020 16:34:53 -0600
Subject: [Haskell-cafe] heres a replacement CI template using gh
 actions: Psa : perhaps time for maintainers to start migrating off Travis
 ci
In-Reply-To: <5636d4c3-8b77-3b32-0fde-1443c20bdea0@durchholz.org>
References: <CAHYVw0zCcXr2f6OyhH1acxuwqH0VcpSbqAtnX0iUNvp4F1bY5g@mail.gmail.com>
 <CAHYVw0w0iONdtwc25e33e7vnz_qe_api5uQFHmtF2vFJqChvxA@mail.gmail.com>
 <5636d4c3-8b77-3b32-0fde-1443c20bdea0@durchholz.org>
Message-ID: <CADnndOr6zi9LNGoEDUQ2gP=kM2yTJMHckbrfGH5ph9=Kam5dAQ@mail.gmail.com>

I use GitLab CI when I have the option. The Docker integration is pretty
helpful. If you're willing to deploy your own GitLab CI instance, you can
use Docker-in-Docker to build and deploy Docker images into production.

I wrote a blog post explaining why I use and prefer GitLab CI:
https://bitemyapp.com/blog/why-i-use-gitlab-ci/

I typically use the hosted CI (on Gitlab.com) and then when I need to speed
up builds, I run CI workers on my own machines. Very pleasant.

It has a few minor limitations to do with how much control you have things
in the YAML but it can be worked around if you need to. I've used GitLab CI
on several production projects, some of them belonging to an employer. I
also use it for my personal projects.

Hope this helps.

Cheers,
Chris Allen


On Sun, Dec 13, 2020 at 4:53 PM Joachim Durchholz <jo at durchholz.org> wrote:

> Not wanting to dishearten you, but Github *was* acquired by Microsoft,
> and that company has changed policy more often than I have appendages to
> count.
> Which means that replacing a Travis workflow with a Github workflow
> isn't improving anything, it's merely another station on the CI
> caravan's route.
>
> Gitlab *is* publishing large parts of their server-side code. Set up a
> local test installation, make sure that CI automation runs there, then
> migrate to Gitlab - that's the strategy I'd choose, YMMV.
>
> Gitlab may become FOSS-unfriendly over time just like any other
> commercial entity, but their barrier is significantly higher: The will
> loser more users and faster if they try anything funny with their
> policy, because then people will just run their own servers. Their
> current policy is a bit of a "we promise to remain FOSS-friendly,
> because, see? - we're locking ourselves in your corner" plot, and of
> course me advertising this is exactly what they want to achieve :-)
>
> DISCLAIMER: I am NOT affiliated with Gitlab in any way.
> Or with any other commercial entity offering services to the open-source
> community.
>
> Regards,
> Jo
>
> Am 13.12.20 um 20:59 schrieb Carter Schonwald:
> >
> https://github.com/cartazio/ralist/blob/495c3dcb3a8e16a693a97a415f731907549aa615/.github/workflows/hs-matrix.yml
>
> > is my current iteration
> >
> > On Mon, Nov 16, 2020 at 1:02 PM Carter Schonwald
> > <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
> >
> >     Hey everyone: it looks like, from my perspective and experiences,
> >     that Travis ci should perhaps now be viewed as not open source
> >     friendly. Or even converging on hostile?
> >
> >     1) crazy long queue times/ latency for oss ci actions to run
> >
> >     2) very low concurrency on oss builds.
> >
> >     3) very low build build  minute caps for oss that require high touch
> >     customer support contact to adjust.
> >
> >     I’ve started moving my own projects slowly to gh actions for now,
> >     though there’s also gitlab ci , src hut and other options that may
> >     suit different folks.
> >
> >     There’s definitely some ways to keep on having the clever cabal
> >     caching we know and love that folks like the Haskell-ci folks and
> >     others have hacked out for Travis be available on other platforms,
> >     though I don’t think there’s consolidated docs for those yet ?  Def
> >     seen it discussed though.
> >
> >     https://github.com/haskell-CI/haskell-ci/issues/411
> >
> >     Heres a url to my dupe ticket where I share an example naive use of
> >     the setup Haskell gh actions Config, definitely not perfect. But
> >     kinda amazing to have Mac and Linux and windows ci all in one ! :)
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view 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.



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201215/fd2bf868/attachment.html>

From ietf-dane at dukhovni.org  Tue Dec 15 23:13:43 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 15 Dec 2020 18:13:43 -0500
Subject: [Haskell-cafe] Question on optimization
In-Reply-To: <CA+-99o+FEBNe6LTS0YKyJw3_mmavV-AyhGGGtSuCfOeLPMSbWw@mail.gmail.com>
References: <CA+-99o+FEBNe6LTS0YKyJw3_mmavV-AyhGGGtSuCfOeLPMSbWw@mail.gmail.com>
Message-ID: <X9lDJ8KnYuQ68ZNV@straasha.imrryr.org>

On Tue, Dec 15, 2020 at 02:05:13PM -0800, Todd Wilson wrote:

> In code of the form
>     case as ++ bs of
>       [] -> ...
>       x:xs -> ...
>
> under what circumstances is the overhead of cons-cell creation for the
> elements of `as` that would happen in an eager language avoided?

In Haskell, even without optimisation, I'd expect the above to
run in constant space and time regardless of the length of `as`.

> Always? Is the answer the same if `f` is defined by simple list
> recursion and we call `f (as ++ bs)`? What if `f` is defined in a
> different module (or comes from the Prelude)?

For example, ghci with no optimisation:

    λ> let f n = [n..n*n]
    λ> case f 1000000 ++ f 10 of { [] -> "empty"; x:xs -> show x }
    "1000000"
    (0.01 secs, 69,680 bytes)
    λ> case f 10000000000000 ++ f 10 of { [] -> "empty"; x:xs -> show x }
    "10000000000000"
    (0.01 secs, 75,384 bytes)

    λ> let x = (1 : undefined) ++ [2]
    (0.01 secs, 63,200 bytes)
    λ> case x of { [] -> "empty"; x:xs -> show x }
    "1"
    (0.01 secs, 64,808 bytes)

So at least with "++" the result is expected to be lazy in the tail of
`as`.  If you interpose some list-generating function:

    f :: [a] -> [b]

called as `f (as ++ bs)`, the result rather depends on how strict `f` is
in the tail of its input.  If `f` can return an initial segment of its
output from just an initial segment of its input, then the same sort
of constant space/time behaviour would be expected from `f`.

> by looking at the (intermediate) code generated by the compiler, but
> more generally, are there some succinct principles that everyday
> programmers can hang on their cubicle walls that summarize a lot of
> what they can expect from the compiler in terms of optimizations?

This feels more like strict/lazy question to me, than optimised vs.
unoptimised.  Haskell promises lazy evaluation even when unoptimised.

    λ> head $ map (+1) $ (1 : undefined) ++ [2]
    2

Here, `map` is but one example of an `f` that is lazy in the tail of its
input:

    map _ [] = []
    map f (x:xs) = f x : map f xs

Generally, any list-to-list function that returns incrementally
consumable output given an infinite list, or a usable initial segment
from a list with a divergent term is one that necessarily only
evaluates some finite initial segment of its input, and is not
sensitive to what lies beyond.

A naive mental model for (++) is then:

    [] ++ bs = bs
    (a:as) ++ bs = a : (as ++ bs)

which is easily seen to be lazy in `as`.

-- 
    Viktor.

From jack at jackkelly.name  Wed Dec 16 12:18:11 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Wed, 16 Dec 2020 12:18:11 GMT
Subject: [Haskell-cafe] [HF-discuss] Do something about Cabal?
In-Reply-To: <9bedfabc-5e4e-f514-696e-8e76ec063827@vex.net>
References: <9bedfabc-5e4e-f514-696e-8e76ec063827@vex.net>
 <CAC60N7kjuBWnNAfg54Ox1421tgMP3+ivcH5_=ubQWjmDU6up5g@mail.gmail.com>
 <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
 <20201210131644.GC902@extensa>
 <CAB-2Q0_co_86Ago_yCCV6A-qf-1RN2N521rCRoMhZK5u1c-kVQ@mail.gmail.com>
 <7edeb28fe01dd8ab6589fbaaec043ce4@jackkelly.name>
 <887B1DEB-2611-4C3D-A0B1-AC93840B64DD@icloud.com>
 <CAM1nAcwpjgHpb6OJuwOJSKeGz-13WYi0GYKoDW+s7dY36nvcZA@mail.gmail.com>
Message-ID: <56ab1b1511f7d21657835f475f05501c@jackkelly.name>

December 12, 2020 4:37 AM, "Albert Y. C. Lai" <trebla at vex.net> wrote:

(Re: cabal-install commands)

> I would not recommend spending time on the v1 model, unless you're a 
> historian.

There is one edge case that I think still works better under cabal v1- commands: https://github.com/haskell/cabal/issues/6515
This is where you create a shared, read-only set of packages (e.g., in a computer lab image) so that students don't fill their $HOME with compiled packages.

Other than that, the v2-commands are a major step forward.

-- Jack

From mail at joachim-breitner.de  Wed Dec 16 15:28:20 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Dec 2020 16:28:20 +0100
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
 Haskell)
In-Reply-To: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
Message-ID: <4e22a74863b1d9e10872b1a787cefea90f94968f.camel@joachim-breitner.de>

Hi,

https://haskell-via-sokoban.nomeata.de/, which uses CodeWorld, starts
from zero, teaches programming not libraries, and in the end lets them
build a game might be good.

It’s a bit steep in some cases (e.g. recursion), but could well form
the basis of a course with more explanation.

It was part of https://www.cis.upenn.edu/~cis194/fall16/, the other
CIS194 iterations are also worth looking at.

Cheers,
Joachim


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



From zachi at baharav.org  Wed Dec 16 19:59:44 2020
From: zachi at baharav.org (Zachi Baharav)
Date: Wed, 16 Dec 2020 11:59:44 -0800
Subject: [Haskell-cafe] Teaching High-School one-semester FP (using
	Haskell)
In-Reply-To: <4e22a74863b1d9e10872b1a787cefea90f94968f.camel@joachim-breitner.de>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <4e22a74863b1d9e10872b1a787cefea90f94968f.camel@joachim-breitner.de>
Message-ID: <CA+ZB5aiHOF4pSa7wdvqkjQ7G78K7pV+Lap1GvTrC4=+ND7Mx-A@mail.gmail.com>

Thanks everyone for the insights and suggestions!!
I will now have the 2-weeks of XMas break to come up with something.

Two notes:
1. Problem set: We might use these https://cses.fi/problemset/  . We did
many in Java. I think doing the same ones in a different form will be
educating.

2. Remote-learning: I don't want to open a whole-new can of worms, and this
is not the list for this, BUT, remote learning certainly influenced my CS
classes as well (to my surprise!).   Keep in mind I am talking high school,
where in normal-years they will have about half of our time together to
work. I would then go around, help people, see where they are, they can ask
me questions. 'Lab' kind of thing. We do not do that now (less contact time
to start with), and moreover, working-remotely for high-schoolers is
remotely-working. So I will need to consider this as well for my planning.

Thanks again, and happy holidays!
  Zachi


On Wed, Dec 16, 2020 at 7:28 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> https://haskell-via-sokoban.nomeata.de/, which uses CodeWorld, starts
> from zero, teaches programming not libraries, and in the end lets them
> build a game might be good.
>
> It’s a bit steep in some cases (e.g. recursion), but could well form
> the basis of a course with more explanation.
>
> It was part of https://www.cis.upenn.edu/~cis194/fall16/, the other
> CIS194 iterations are also worth looking at.
>
> 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/20201216/56b4620d/attachment.html>

From chilledfrogs at disroot.org  Wed Dec 16 20:16:48 2020
From: chilledfrogs at disroot.org (Allen Sobot)
Date: Wed, 16 Dec 2020 21:16:48 +0100
Subject: [Haskell-cafe] Teaching High-School one-semester FP
	(using	Haskell)
In-Reply-To: <CA+ZB5aiHOF4pSa7wdvqkjQ7G78K7pV+Lap1GvTrC4=+ND7Mx-A@mail.gmail.com>
References: <CA+ZB5aiD5HgPbv7Rcj15-L4JsUW2MqGrdh-p_xm6FPySsUA6Ew@mail.gmail.com>
 <4e22a74863b1d9e10872b1a787cefea90f94968f.camel@joachim-breitner.de>
 <CA+ZB5aiHOF4pSa7wdvqkjQ7G78K7pV+Lap1GvTrC4=+ND7Mx-A@mail.gmail.com>
Message-ID: <CB7EE65D-8E89-4F39-8DEF-CBF34E50F606@disroot.org>

I hope this will remove duplicate recipients, not entirely sure how to properly reply on this mailing list (and mailing lists period really) yet, sorry if I screwed something up...

God how I would have loved to have a Haskell (or any programming) course in high school 😅

Further remarks inline, and best of luck to you and your students, have fun

On December 16, 2020 8:59:44 p.m. GMT+01:00, Zachi Baharav <zachi at baharav.org> wrote:
>Thanks everyone for the insights and suggestions!!
>I will now have the 2-weeks of XMas break to come up with something.
>
>Two notes:
>1. Problem set: We might use these https://cses.fi/problemset/  . We did
>many in Java. I think doing the same ones in a different form will be
>educating.
That's actually a great idea, I'll remember that when I start teaching one day 😅😅
>
>2. Remote-learning: I don't want to open a whole-new can of worms, and this
>is not the list for this, BUT, remote learning certainly influenced my CS
>classes as well (to my surprise!).   Keep in mind I am talking high school,
>where in normal-years they will have about half of our time together to
>work. I would then go around, help people, see where they are, they can ask
>me questions. 'Lab' kind of thing. We do not do that now (less contact time
>to start with), and moreover, working-remotely for high-schoolers is
>remotely-working. So I will need to consider this as well for my planning.
You might want to consider, maybe, Repl.it for its collaborative online coding facilities which might come in handy in this context. For community stuff, of course Discord or Zulip are in my opinion great choices for questions and answers, and Discord has great screen sharing and voice chat as well, idk about Zulip enough on that one though 😅 but both require time and experience to set up properly and securely; your students might be able to help you with that for Discord if you don't have experience with it yourself.
>
>Thanks again, and happy holidays!
>  Zachi
>
>
>On Wed, Dec 16, 2020 at 7:28 AM Joachim Breitner <mail at joachim-breitner.de>
>wrote:
>
>> Hi,
>>
>> https://haskell-via-sokoban.nomeata.de/, which uses CodeWorld, starts
>> from zero, teaches programming not libraries, and in the end lets them
>> build a game might be good.
>>
>> It’s a bit steep in some cases (e.g. recursion), but could well form
>> the basis of a course with more explanation.
>>
>> It was part of https://www.cis.upenn.edu/~cis194/fall16/, the other
>> CIS194 iterations are also worth looking at.
>>
>> 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.

From m.douglas.mcilroy at dartmouth.edu  Wed Dec 16 21:44:19 2020
From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy)
Date: Wed, 16 Dec 2020 16:44:19 -0500
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
Message-ID: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>

Some nominally rational functions, e.g n*(n+1)/2,
yield integer values for integer arguments. I seek
either a way to wrap such a function so it has type
Num a => a->a or a convincing argument that it can't
be done.

Doug

From lemming at henning-thielemann.de  Wed Dec 16 21:50:17 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 16 Dec 2020 22:50:17 +0100 (CET)
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2012162249250.6305@sputnik>


On Wed, 16 Dec 2020, M Douglas McIlroy wrote:

> Some nominally rational functions, e.g n*(n+1)/2,
> yield integer values for integer arguments. I seek
> either a way to wrap such a function so it has type
> Num a => a->a or a convincing argument that it can't
> be done.

Num will be difficult, but with Integral class you could use 'div'.

From david.feuer at gmail.com  Wed Dec 16 21:57:12 2020
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 16 Dec 2020 16:57:12 -0500
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
Message-ID: <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>

I very much doubt that Num a is sufficient. That's not even enough to check
whether a number is even. You can certainly perform the calculation with
`Integral a`, but you'll have to apply some external reasoning to see that
the result is correct.

On Wed, Dec 16, 2020, 4:45 PM M Douglas McIlroy <
m.douglas.mcilroy at dartmouth.edu> wrote:

> Some nominally rational functions, e.g n*(n+1)/2,
> yield integer values for integer arguments. I seek
> either a way to wrap such a function so it has type
> Num a => a->a or a convincing argument that it can't
> be done.
>
> Doug
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201216/5cb45c61/attachment.html>

From migmit at gmail.com  Wed Dec 16 22:07:15 2020
From: migmit at gmail.com (MigMit)
Date: Wed, 16 Dec 2020 23:07:15 +0100
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
Message-ID: <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>

Num + Enum would be enough though, since n*(n+1)/2 = sum [1..n], n*(n+1)*(n+2)/6 = sum (map (\m -> sum [1..m]) [1..n]) etc. Not quite effective, of course.

> On 16 Dec 2020, at 22:57, David Feuer <david.feuer at gmail.com> wrote:
> 
> I very much doubt that Num a is sufficient. That's not even enough to check whether a number is even. You can certainly perform the calculation with `Integral a`, but you'll have to apply some external reasoning to see that the result is correct.
> 
> On Wed, Dec 16, 2020, 4:45 PM M Douglas McIlroy <m.douglas.mcilroy at dartmouth.edu> wrote:
> Some nominally rational functions, e.g n*(n+1)/2,
> yield integer values for integer arguments. I seek
> either a way to wrap such a function so it has type
> Num a => a->a or a convincing argument that it can't
> be done.
> 
> Doug
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 lemming at henning-thielemann.de  Wed Dec 16 22:12:24 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 16 Dec 2020 23:12:24 +0100 (CET)
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
Message-ID: <alpine.DEB.2.20.2012162311290.6305@sputnik>


On Wed, 16 Dec 2020, MigMit wrote:

> Num + Enum would be enough though, since n*(n+1)/2 = sum [1..n], 
> n*(n+1)*(n+2)/6 = sum (map (\m -> sum [1..m]) [1..n]) etc. Not quite 
> effective, of course.

You could also use Num + Ord and do:

   sum $ takeWhile (<=n) $ iterate (1+) 1

From jaro.reinders at gmail.com  Wed Dec 16 22:13:38 2020
From: jaro.reinders at gmail.com (Jaro Reinders)
Date: Wed, 16 Dec 2020 23:13:38 +0100
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
Message-ID: <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>

Num alone is enough: sum [1..n] = sum (map fromInteger [1..n])

On 12/16/20 11:07 PM, MigMit wrote:
> Num + Enum would be enough though, since n*(n+1)/2 = sum [1..n], n*(n+1)*(n+2)/6 = sum (map (\m -> sum [1..m]) [1..n]) etc. Not quite effective, of course.
> 
>> On 16 Dec 2020, at 22:57, David Feuer <david.feuer at gmail.com> wrote:
>>
>> I very much doubt that Num a is sufficient. That's not even enough to check whether a number is even. You can certainly perform the calculation with `Integral a`, but you'll have to apply some external reasoning to see that the result is correct.
>>
>> On Wed, Dec 16, 2020, 4:45 PM M Douglas McIlroy <m.douglas.mcilroy at dartmouth.edu> wrote:
>> Some nominally rational functions, e.g n*(n+1)/2,
>> yield integer values for integer arguments. I seek
>> either a way to wrap such a function so it has type
>> Num a => a->a or a convincing argument that it can't
>> be done.
>>
>> Doug
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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 migmit at gmail.com  Wed Dec 16 22:17:30 2020
From: migmit at gmail.com (MigMit)
Date: Wed, 16 Dec 2020 23:17:30 +0100
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
Message-ID: <D2485F26-7242-46BF-A479-68FAB31DEA1C@gmail.com>

A small optimization, maybe: fromInteger ((n * (n+1)) `div` 2)?

> On 16 Dec 2020, at 23:13, Jaro Reinders <jaro.reinders at gmail.com> wrote:
> 
> Num alone is enough: sum [1..n] = sum (map fromInteger [1..n])
> 
> On 12/16/20 11:07 PM, MigMit wrote:
>> Num + Enum would be enough though, since n*(n+1)/2 = sum [1..n], n*(n+1)*(n+2)/6 = sum (map (\m -> sum [1..m]) [1..n]) etc. Not quite effective, of course.
>>> On 16 Dec 2020, at 22:57, David Feuer <david.feuer at gmail.com> wrote:
>>> 
>>> I very much doubt that Num a is sufficient. That's not even enough to check whether a number is even. You can certainly perform the calculation with `Integral a`, but you'll have to apply some external reasoning to see that the result is correct.
>>> 
>>> On Wed, Dec 16, 2020, 4:45 PM M Douglas McIlroy <m.douglas.mcilroy at dartmouth.edu> wrote:
>>> Some nominally rational functions, e.g n*(n+1)/2,
>>> yield integer values for integer arguments. I seek
>>> either a way to wrap such a function so it has type
>>> Num a => a->a or a convincing argument that it can't
>>> be done.
>>> 
>>> Doug
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view 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.


From x at tomsmeding.com  Wed Dec 16 22:18:36 2020
From: x at tomsmeding.com (Tom Smeding)
Date: Wed, 16 Dec 2020 22:18:36 +0000
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
Message-ID: <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>

That has n :: Integer, not n :: a, right?

@Douglas:

What about the ring of polynomials over the integers, i.e. Z[X]? We can certainly define a Num instance for that if we set 'signum _ = 1' and 'abs = id'. 'fromInteger' then injects constant polynomials.

However, if 'n' is X + 1, then n*(n+1) is X^2 + 3X + 2; what's that divided by 2? Not well-defined, since we were talking about polynomials over the integers.

If your function is to have type Num a => a -> a, it will need to handle this case, but I don't see a way in which it can.

- Tom

P.S. Unless, of course, you allow extra typeclasses; other posters have already suggested (inefficient) versions for Ord and Enum.

-------- Original Message --------

On 16 Dec 2020, 23:13, Jaro Reinders < jaro.reinders at gmail.com> wrote:

Num alone is enough: sum [1..n] = sum (map fromInteger [1..n])

On 12/16/20 11:07 PM, MigMit wrote:

> Num + Enum would be enough though, since n*(n+1)/2 = sum [1..n], n*(n+1)*(n+2)/6 = sum (map (\m -> sum [1..m]) [1..n]) etc. Not quite effective, of course.

>

>> On 16 Dec 2020, at 22:57, David Feuer <david.feuer at gmail.com> wrote:

>>

>> I very much doubt that Num a is sufficient. That's not even enough to check whether a number is even. You can certainly perform the calculation with `Integral a`, but you'll have to apply some external reasoning to see that the result is correct.

>>

>> On Wed, Dec 16, 2020, 4:45 PM M Douglas McIlroy <m.douglas.mcilroy at dartmouth.edu> wrote:

>> Some nominally rational functions, e.g n*(n+1)/2,

>> yield integer values for integer arguments. I seek

>> either a way to wrap such a function so it has type

>> Num a => a->a or a convincing argument that it can't

>> be done.

>>

>> Doug

>> _______________________________________________

>> Haskell-Cafe mailing list

>> To (un)subscribe, modify options or view 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/20201216/c9dd28e6/attachment.html>

From lemming at henning-thielemann.de  Wed Dec 16 22:26:57 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 16 Dec 2020 23:26:57 +0100 (CET)
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
 <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>
Message-ID: <alpine.DEB.2.20.2012162325140.6305@sputnik>


On Wed, 16 Dec 2020, Tom Smeding wrote:

> @Douglas:
> What about the ring of polynomials over the integers, i.e. Z[X]? We can certainly define a Num instance for that
> if we set 'signum _ = 1' and 'abs = id'. 'fromInteger' then injects constant polynomials.

I also thought about polynomials, but Num is a Ring plus 'signum' and 
'abs'. Are your definitions ob 'signum' and 'abs' sound? Are there other 
sound definitions that may allow the n*(n+1)/2 magic?

From x at tomsmeding.com  Wed Dec 16 22:41:53 2020
From: x at tomsmeding.com (Tom Smeding)
Date: Wed, 16 Dec 2020 22:41:53 +0000
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <alpine.DEB.2.20.2012162325140.6305@sputnik>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
 <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162325140.6305@sputnik>
Message-ID: <kmsJNCwdjik7-ukRpgVOeC__wDdD1V0t7EjgOPkaDyJrmDURbV8mwozEi8IgdQetYUKUnu2GdsmRXWynjkKp3dcdmy5PIxOdl86tuEJnzfw=@tomsmeding.com>

I'm not sure what "sound" means if the documentation[1] for Num states that the only reasonable expectation is that of a ring.

However, if we are to have laws for signum and abs, then I would expect that 'abs n = n * signum n'. My definitions satisfy that law.

Furthermore for polynomials, I don't think there is a useful definition of 'abs' where 'abs n' has a higher degree than 'n' itself. Assuming that 'abs' does not increase the degree, I don't think there are any other _useful_ definitions of abs and signum than the ones I gave: multiplication in Z[X] will never decrease the degree, so the degree of 'n * signum n' is at least that of 'n', and therefore the degree of 'abs n' is the same as that of 'n'; therefore 'signum n' is a constant polynomial (without X'es). With that restriction the only reasonable choice I see is 'signum = const 1'.

But even if you take 'abs' and 'signum' to be absolutely wild functions, to be able to write n*(n+1)/2 you need to define your division operator. There is certainly not one in base that will work for 'Int -> Int' as well as 'Float -> Float' as well as 'Poly Integer -> Poly Integer'. And in particular not abs nor signum. :)

- Tom

[1]: https://hackage.haskell.org/package/base-4.14.1.0/docs/Prelude.html#t:Num

-------- Original Message --------

On 16 Dec 2020, 23:26, Henning Thielemann < lemming at henning-thielemann.de> wrote:

On Wed, 16 Dec 2020, Tom Smeding wrote:

> @Douglas:

> What about the ring of polynomials over the integers, i.e. Z[X]? We can certainly define a Num instance for that

> if we set 'signum _ = 1' and 'abs = id'. 'fromInteger' then injects constant polynomials.

I also thought about polynomials, but Num is a Ring plus 'signum' and

'abs'. Are your definitions ob 'signum' and 'abs' sound? Are there other

sound definitions that may allow the n*(n+1)/2 magic?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201216/85ddfcc6/attachment.html>

From lemming at henning-thielemann.de  Wed Dec 16 22:48:08 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 16 Dec 2020 23:48:08 +0100 (CET)
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <kmsJNCwdjik7-ukRpgVOeC__wDdD1V0t7EjgOPkaDyJrmDURbV8mwozEi8IgdQetYUKUnu2GdsmRXWynjkKp3dcdmy5PIxOdl86tuEJnzfw=@tomsmeding.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
 <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162325140.6305@sputnik>
 <kmsJNCwdjik7-ukRpgVOeC__wDdD1V0t7EjgOPkaDyJrmDURbV8mwozEi8IgdQetYUKUnu2GdsmRXWynjkKp3dcdmy5PIxOdl86tuEJnzfw=@tomsmeding.com>
Message-ID: <alpine.DEB.2.20.2012162346400.6305@sputnik>


On Wed, 16 Dec 2020, Tom Smeding wrote:

> I'm not sure what "sound" means if the documentation[1] for Num states that the only reasonable expectation is
> that of a ring.
> 
> However, if we are to have laws for signum and abs, then I would expect that 'abs n = n * signum n'. My
> definitions satisfy that law.

What about abs x = x/2 and signum _ = 2?

Would satisfy your law and solve the problem of the original poster.

From jaro.reinders at gmail.com  Wed Dec 16 22:53:06 2020
From: jaro.reinders at gmail.com (Jaro Reinders)
Date: Wed, 16 Dec 2020 23:53:06 +0100
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <D2485F26-7242-46BF-A479-68FAB31DEA1C@gmail.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
 <D2485F26-7242-46BF-A479-68FAB31DEA1C@gmail.com>
Message-ID: <AAF31247-970F-4418-8982-7AC891862E80@gmail.com>

Ah, my mistake. n has to have the given type a and not Integer of course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201216/364a17c6/attachment.html>

From x at tomsmeding.com  Wed Dec 16 23:06:18 2020
From: x at tomsmeding.com (Tom Smeding)
Date: Wed, 16 Dec 2020 23:06:18 +0000
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <alpine.DEB.2.20.2012162346400.6305@sputnik>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
 <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162325140.6305@sputnik>
 <kmsJNCwdjik7-ukRpgVOeC__wDdD1V0t7EjgOPkaDyJrmDURbV8mwozEi8IgdQetYUKUnu2GdsmRXWynjkKp3dcdmy5PIxOdl86tuEJnzfw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162346400.6305@sputnik>
Message-ID: <oI2acyvxYBHC7_qISKu17O3aifNtyqzk9Ht_36t8H6BBYGv0bsx4p1-c37dJA0E6d1Kx8YvnIsLfHBbxqKTaXVSVmlbWXGk_-98hMm-IQoI=@tomsmeding.com>

You say 'abs x = x/2', but what's that (/)? For example, what is 'abs' supposed to give when called on (the representation of) the polynomial X^2 + 3X + 2?

Interesting also to think about what the meaning of 'n*(n+1)/2' on polynomials should even be. What is the sum of the numbers (polynomials?) from 1 to X + 1?

- Tom

-------- Original Message --------

On 16 Dec 2020, 23:48, Henning Thielemann < lemming at henning-thielemann.de> wrote:

On Wed, 16 Dec 2020, Tom Smeding wrote:

> I'm not sure what "sound" means if the documentation[1] for Num states that the only reasonable expectation is

> that of a ring.

>

> However, if we are to have laws for signum and abs, then I would expect that 'abs n = n * signum n'. My

> definitions satisfy that law.

What about abs x = x/2 and signum _ = 2?

Would satisfy your law and solve the problem of the original poster.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201216/215a3f50/attachment.html>

From lemming at henning-thielemann.de  Wed Dec 16 23:13:29 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 17 Dec 2020 00:13:29 +0100 (CET)
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <oI2acyvxYBHC7_qISKu17O3aifNtyqzk9Ht_36t8H6BBYGv0bsx4p1-c37dJA0E6d1Kx8YvnIsLfHBbxqKTaXVSVmlbWXGk_-98hMm-IQoI=@tomsmeding.com>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
 <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162325140.6305@sputnik>
 <kmsJNCwdjik7-ukRpgVOeC__wDdD1V0t7EjgOPkaDyJrmDURbV8mwozEi8IgdQetYUKUnu2GdsmRXWynjkKp3dcdmy5PIxOdl86tuEJnzfw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162346400.6305@sputnik>
 <oI2acyvxYBHC7_qISKu17O3aifNtyqzk9Ht_36t8H6BBYGv0bsx4p1-c37dJA0E6d1Kx8YvnIsLfHBbxqKTaXVSVmlbWXGk_-98hMm-IQoI=@tomsmeding.com>
Message-ID: <alpine.DEB.2.20.2012170011440.6305@sputnik>


On Wed, 16 Dec 2020, Tom Smeding wrote:

> You say 'abs x = x/2', but what's that (/)? For example, what is 'abs' 
> supposed to give when called on (the representation of) the polynomial 
> X^2 + 3X + 2?

I meant it this way:

instance (Fractional a) => Num (Polynomial a) where
    abs = fmap (/2)

From x at tomsmeding.com  Wed Dec 16 23:30:29 2020
From: x at tomsmeding.com (Tom Smeding)
Date: Wed, 16 Dec 2020 23:30:29 +0000
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <alpine.DEB.2.20.2012170011440.6305@sputnik>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
 <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162325140.6305@sputnik>
 <kmsJNCwdjik7-ukRpgVOeC__wDdD1V0t7EjgOPkaDyJrmDURbV8mwozEi8IgdQetYUKUnu2GdsmRXWynjkKp3dcdmy5PIxOdl86tuEJnzfw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162346400.6305@sputnik>
 <oI2acyvxYBHC7_qISKu17O3aifNtyqzk9Ht_36t8H6BBYGv0bsx4p1-c37dJA0E6d1Kx8YvnIsLfHBbxqKTaXVSVmlbWXGk_-98hMm-IQoI=@tomsmeding.com>
 <alpine.DEB.2.20.2012170011440.6305@sputnik>
Message-ID: <AyoPcTyFXaVOLswwdmVn45bLbn8gCbE8fNIs3Cj-ytwPWdNACWwElawkTVl7qRAPtjQKEEshB0M3C_vL8gfTTX5tpDVb9NRzr1XV2SlyOsA=@tomsmeding.com>

Good point, that would allow the original, desired function to be written 'f :: Num a => a -> a; f n = abs (n * (n + 1))'. However, that doesn't do the right thing when 'a' is Int or Float.

Any candidate 'f' would need to be written, all auxiliary functions inlined, in terms of the operations of Num. Since there is no way to do that when a ~ Int (since the Num Int instance doesn't have backdoors like this), it won't work. My polynomial example really only gives a conceptual idea why it _shouldn't_ work.

Assuming I'm not missing something; it's late here.

- Tom

-------- Original Message --------

On 17 Dec 2020, 00:13, Henning Thielemann < lemming at henning-thielemann.de> wrote:

On Wed, 16 Dec 2020, Tom Smeding wrote:

> You say 'abs x = x/2', but what's that (/)? For example, what is 'abs'

> supposed to give when called on (the representation of) the polynomial

> X^2 + 3X + 2?

I meant it this way:

instance (Fractional a) => Num (Polynomial a) where

abs = fmap (/2)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201216/387f268a/attachment-0001.html>

From sjcjoosten+haskell at gmail.com  Wed Dec 16 23:31:33 2020
From: sjcjoosten+haskell at gmail.com (Sebastiaan Joosten)
Date: Wed, 16 Dec 2020 18:31:33 -0500
Subject: [Haskell-cafe] "Natural" polymorphism for n*(n+1)/2
In-Reply-To: <alpine.DEB.2.20.2012170011440.6305@sputnik>
References: <CAKH6PiXxudt5sH+jWLk1cBPPfT+qNjj1Cb+QPLgRUhEpFfou9Q@mail.gmail.com>
 <CAMgWh9tg1rxv6_34WMH-jSWf=zWhY94iAKNXJ_P0-0B_+jXTVQ@mail.gmail.com>
 <E39B4ABA-0603-4020-AA15-77D5625337C3@gmail.com>
 <2e4e2150-4dda-d30f-afec-377cdfa1048f@gmail.com>
 <DulvJV0LrzG868fukiqpdIR_qUtBpyuI8DzOe5SEgmzQ_Lxq7iPCocafGT71eklvwLEwKj_5Wv-VMc31ze_CR2SPQuD-bqrxezeU4jaYxhw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162325140.6305@sputnik>
 <kmsJNCwdjik7-ukRpgVOeC__wDdD1V0t7EjgOPkaDyJrmDURbV8mwozEi8IgdQetYUKUnu2GdsmRXWynjkKp3dcdmy5PIxOdl86tuEJnzfw=@tomsmeding.com>
 <alpine.DEB.2.20.2012162346400.6305@sputnik>
 <oI2acyvxYBHC7_qISKu17O3aifNtyqzk9Ht_36t8H6BBYGv0bsx4p1-c37dJA0E6d1Kx8YvnIsLfHBbxqKTaXVSVmlbWXGk_-98hMm-IQoI=@tomsmeding.com>
 <alpine.DEB.2.20.2012170011440.6305@sputnik>
Message-ID: <CABhTcUus=uJW2pSO9DtBOy5cEPHZFeB64nra0O1MAhK9AHSMMw@mail.gmail.com>

here's why it cannot be done:

data TwoByTwoMatrix = TTM Integer Integer Integer Integer

instance Num TwoByTwoMatrix where
  fromInteger i = TTM i 0 0 i
  (TTM a b c d) + (TTM e f g h) = TTM (a+e) (b+f) (c+g) (d+h)
  negate m = (fromInteger (-1)) * m
  (TTM a b c d) * (TTM e f g h) = TTM (b*g+a*e) (a*f+b*h) (d*g+c*e)
(c*f+d*h)
It should follow that the above is a (non-abelian) ring, as required (all
definitions follow the standard matrix addition/multiplication/addition
convensions).

n = (TTM 0 1 0 0)
then: n * (n + 1) = n.
Since n has odd entries, it cannot be divided by 2 (more precisely: we
cannot find an m s.t. n * 2 = m).

Best,
Sebastiaan


On Wed, Dec 16, 2020 at 6:14 PM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Wed, 16 Dec 2020, Tom Smeding wrote:
>
> > You say 'abs x = x/2', but what's that (/)? For example, what is 'abs'
> > supposed to give when called on (the representation of) the polynomial
> > X^2 + 3X + 2?
>
> I meant it this way:
>
> instance (Fractional a) => Num (Polynomial a) where
>     abs = fmap (/2)
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201216/3951b214/attachment.html>

From twilson at csufresno.edu  Thu Dec 17 01:04:53 2020
From: twilson at csufresno.edu (Todd Wilson)
Date: Wed, 16 Dec 2020 17:04:53 -0800
Subject: [Haskell-cafe] Question on optimization
In-Reply-To: <X9lDJ8KnYuQ68ZNV@straasha.imrryr.org>
References: <CA+-99o+FEBNe6LTS0YKyJw3_mmavV-AyhGGGtSuCfOeLPMSbWw@mail.gmail.com>
 <X9lDJ8KnYuQ68ZNV@straasha.imrryr.org>
Message-ID: <CA+-99oKg07Sf6QTaZ3PgSbVPFE9zcuybYnAZAZL8Yobajt8eiw@mail.gmail.com>

Thanks, Viktor, for your response, but I think you misunderstood my question:

On Tue, Dec 15, 2020 at 3:14 PM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>
> On Tue, Dec 15, 2020 at 02:05:13PM -0800, Todd Wilson wrote:
>
> > In code of the form
> >     case as ++ bs of
> >       [] -> ...
> >       x:xs -> ...
> >
> > under what circumstances is the overhead of cons-cell creation for the
> > elements of `as` that would happen in an eager language avoided?
>
> In Haskell, even without optimisation, I'd expect the above to
> run in constant space and time regardless of the length of `as`.

Of course this is constant time and space, but that wasn't what I was
asking. Suppose HNF(as) = a : ys. Then the `case` will cause the
definition of (++) to unfold once and produce a : (ys ++ bs), taking
the second branch with x = a and xs = ys ++ bs, the latter a thunk. My
question was whether a cons-cell containing `a` is created in the heap
or not -- that's the "overhead" I was asking about. In this case, it
seems that the compiler could easily avoid this overhead by inlining
the definition of (++) and doing some basic simplification to arrive
at

> case as of
>   [] -> case bs of
>           [] -> -- 1st branch above
>           x:xs -> -- 2nd branch above
>   x:ys -> let xs = ys ++ bs in -- 2nd branch above

My follow-up questions were about whether this overhead would also be
avoided in `f (as ++ bs)` if f was defined in the same module by list
recursion, or in another module or the Prelude (say f = length).

Here is a similar, but more sophisticated example involving flattening
of nested lists, coded three ways:

> data Nest a = Nil | Cons a (Nest a) | Nest (Nest a) (Nest a)
>
> flatten :: Nest a -> [a]
> flatten Nil = []
> flatten (Cons x n) = x : flatten n
> flatten (Nest n1 n2) = flatten n1 ++ flatten n2
>
> flatten2 n = fl [n] where
>   fl :: [Nest a] -> [a]
>   fl [] = []
>   fl (Nil : ns) = fl ns
>   fl (Cons x n : ns) = x : fl (n:ns)
>   fl (Nest n1 n2 : ns) = fl (n1:n2:ns)
>
> flatten3 n = fl n [] where
>   fl :: Nest a -> [Nest a] -> [a]
>   fl Nil [] = []
>   fl Nil (n:ns) = fl n ns
>   fl (Cons x n) ns = x : fl n ns
>   fl (Nest n1 n2) ns = fl n1 (n2:ns)

On the surface, the difference between these three functions is how
many cons-cells they create, in decreasing order. In `flatten`,
elements are also copied during (++) operations a number of times
equal to their depth in the original nested list; the other two each
copy the original elements once. But does (or can) the compiler
simplify `flatten2` more or less to `flatten3`? It seems to hinge on
how nested patterns are handled.

Again, I wish I had some general principles about what kind of
compiler optimizations are applied, so that I could answer such
questions in the abstract and write code in an easier-to-understand
but seemingly more expensive way knowing that the extra expense was
going to be compiled away.

--Todd

From carette at mcmaster.ca  Thu Dec 17 03:20:08 2020
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 16 Dec 2020 22:20:08 -0500
Subject: [Haskell-cafe] Intermediate Modern Haskell
Message-ID: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>

I will be teaching a second Haskell course next semester.  Let's assume that

Introducing functional programming

Getting started with Haskell and GHCi

Basic types and definitions

Designing and writing programs

Data types, tuples and lists

Programming with lists

Defining functions over lists

Playing the game: I/O in Haskell

Reasoning about programs

Generalization: patterns of computation

Higher-order functions

Developing higher-order programs

Overloading, type classes and type checking

Algebraic types


(i.e. the first chapters of Thompson's Haskell: the Craft of Functional 
Programming book is "beginner, classic Haskell".  The next few chapters, 
namely

Abstract data types

Lazy programming

Programming with monads

Domain-Specific Languages

Time and space behaviour


would be (re)done at the start of such a second course. The question for 
cafe is: what else? I will likely cover:
- Typeclassopedia
- finally tagless
- Template Haskell
- Optics
- GADTs
- recursion schemes


I should probably cover parser combinators, pretty-printing, 
cabal&stack. I know that http://dev.stephendiehl.com/hask/ 
<http://dev.stephendiehl.com/hask/> gives me one heck of a smorgasbord 
of options, which is kind of a problem.


Things I know I will not cover:
- dependent types (if I was going to do that, I'd switch to Idris/Agda)
- concurrency (don't ask)


Jacques

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

From tikhon at jelv.is  Thu Dec 17 03:41:44 2020
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Wed, 16 Dec 2020 19:41:44 -0800
Subject: [Haskell-cafe] Intermediate Modern Haskell
In-Reply-To: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
References: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
Message-ID: <CAJN5CVLirirmxHf1vKd=qQeff=mZUsvcbzU5Fjw3LqGhhQ8oCQ@mail.gmail.com>

What kind of projects and applications are you focused on? In my
experience, the difficulty in learning—and teaching—"advanced" Haskell
topics is less in the topic itself and more in the level of abstraction
involved. I know that I struggled with GADTs and even existential types not
because of the features themselves but because I had real trouble putting
the features into context and understanding how I would use them. Just
*why* are those abstractions in particular interesting?

I can recommend some of my personal favorite topics like streaming
libraries, FRP, automatic differentiation and the probability monad, but
whether that recommendation makes sense depends on how you want to use
those topics. Alternatively, if you have some specific things you would
want to build with the class, we could suggest topics that fit those goals.

On Wed, Dec 16, 2020, 19:22 Jacques Carette <carette at mcmaster.ca> wrote:

> I will be teaching a second Haskell course next semester.  Let's assume
> that
>
> Introducing functional programming
>
> Getting started with Haskell and GHCi
>
> Basic types and definitions
>
> Designing and writing programs
>
> Data types, tuples and lists
>
> Programming with lists
>
> Defining functions over lists
>
> Playing the game: I/O in Haskell
>
> Reasoning about programs
>
> Generalization: patterns of computation
>
> Higher-order functions
>
> Developing higher-order programs
>
> Overloading, type classes and type checking
>
> Algebraic types
>
>
> (i.e. the first chapters of Thompson's Haskell: the Craft of Functional
> Programming book is "beginner, classic Haskell".  The next few chapters,
> namely
>
> Abstract data types
>
> Lazy programming
>
> Programming with monads
>
> Domain-Specific Languages
>
> Time and space behaviour
>
>
> would be (re)done at the start of such a second course. The question for
> cafe is: what else? I will likely cover:
> - Typeclassopedia
> - finally tagless
> - Template Haskell
> - Optics
> - GADTs
> - recursion schemes
>
>
> I should probably cover parser combinators, pretty-printing, cabal&stack.
> I know that http://dev.stephendiehl.com/hask/ gives me one heck of a
> smorgasbord of options, which is kind of a problem.
>
>
> Things I know I will not cover:
> - dependent types (if I was going to do that, I'd switch to Idris/Agda)
> - concurrency (don't ask)
>
>
> Jacques
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201216/3dd21bee/attachment.html>

From ietf-dane at dukhovni.org  Thu Dec 17 05:15:19 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 17 Dec 2020 00:15:19 -0500
Subject: [Haskell-cafe] Question on optimization
In-Reply-To: <CA+-99oKg07Sf6QTaZ3PgSbVPFE9zcuybYnAZAZL8Yobajt8eiw@mail.gmail.com>
References: <CA+-99o+FEBNe6LTS0YKyJw3_mmavV-AyhGGGtSuCfOeLPMSbWw@mail.gmail.com>
 <X9lDJ8KnYuQ68ZNV@straasha.imrryr.org>
 <CA+-99oKg07Sf6QTaZ3PgSbVPFE9zcuybYnAZAZL8Yobajt8eiw@mail.gmail.com>
Message-ID: <X9rpZ8e/xWYZt/Rv@straasha.imrryr.org>

On Wed, Dec 16, 2020 at 05:04:53PM -0800, Todd Wilson wrote:

> Thanks, Viktor, for your response, but I think you misunderstood my question:

Indeed I read much too little into it.  Sorry about that.

> Here is a similar, but more sophisticated example involving flattening
> of nested lists, coded three ways:
> 
> > data Nest a = Nil | Cons a (Nest a) | Nest (Nest a) (Nest a)
> >
> > flatten :: Nest a -> [a]
> > flatten Nil = []
> > flatten (Cons x n) = x : flatten n
> > flatten (Nest n1 n2) = flatten n1 ++ flatten n2

I would have gone with a right fold:

    flatten = foldr k []
      where
        k Nil a = a
        k (Cons x n) a = x : foldr k a n
        k (Nest x y) a = foldr k (foldr k a y) x

In fact, I'd be rather inclined to do this indirectly by instead
defining an instance of Foldable for this structure, and then just
using that to do the flattening:

    instance Foldable Nest where
        foldr _ z Nil = z
        foldr f z (Cons x n) = f x (foldr f z n)
        foldr f z (Nest x y) = foldr f (foldr f z y) x

    flatten = foldr (:) []

> Again, I wish I had some general principles about what kind of
> compiler optimizations are applied, so that I could answer such
> questions in the abstract and write code in an easier-to-understand
> but seemingly more expensive way knowing that the extra expense was
> going to be compiled away.

I don't have an answer for your original question, but I think
you'll find that flattening foldable/traversable data structures
is often optimally done with some sort of right fold, which avoids
the costs of (++), by producing the first element directly, and
then lazily the rest of the structure.

The Traversable instance in this case would be:

    {-# LANGUAGE DerivingFunctor, StandaloneDeriving #-}
    data Nest a = Nil
                | Cons a (Nest a)
                | Nest (Nest a) (Nest a)
        deriving (Show, Functor)

    instance Traversable Nest where
        traverse f Nil = pure Nil
        traverse f (Cons x n) = Cons <$> f x <*> traverse f n
        traverse f (Nest x y) = Nest <$> traverse f x <*> traverse f y

A complete demo program is below my signature, which produces the
expected output:

    [1,2,3,10,4,20]
    Just (Cons 2 (Cons 3 (Nest (Cons 4 (Cons 11 Nil)) (Cons 5 (Cons 21 Nil)))))

I don't know whether indirection via "foldr = go" with `go`
recursive and `foldr` "INLINABLE" and ditto for `traverse` would
create further opportunities for optimisation when the instances
are in a separate module.  Someone else might clear that up, or
you could benchmark and see.  IIRC, recursive functions don't
directly inline without such tweaks, but the tweaks might not
help much.

-- 
    Viktor.

{-# LANGUAGE DeriveFunctor #-}

module Main (main) where

data Nest a = Nil
            | Cons a (Nest a)
            | Nest (Nest a) (Nest a)
    deriving (Show, Functor)

instance Foldable Nest where
    foldr _ z Nil = z
    foldr f z (Cons x n) = f x (foldr f z n)
    foldr f z (Nest x y) = foldr f (foldr f z y) x

instance Traversable Nest where
    traverse f Nil = pure Nil
    traverse f (Cons x n) = Cons <$> f x <*> traverse f n
    traverse f (Nest x y) = Nest <$> traverse f x <*> traverse f y

flatten :: Nest a -> [a]
flatten = foldr (:) []

nested :: Nest Int
nested =
    Cons 1
    $ Cons 2
    $ Nest (Cons 3 $ Cons 10 Nil)
           (Cons 4 $ Cons 20 Nil)

main :: IO ()
main = do
    print $ flatten nested
    print $ traverse (\i -> Just (i + 1)) nested

From ietf-dane at dukhovni.org  Thu Dec 17 06:48:34 2020
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 17 Dec 2020 01:48:34 -0500
Subject: [Haskell-cafe] Question on optimization
In-Reply-To: <X9rpZ8e/xWYZt/Rv@straasha.imrryr.org>
References: <CA+-99o+FEBNe6LTS0YKyJw3_mmavV-AyhGGGtSuCfOeLPMSbWw@mail.gmail.com>
 <X9lDJ8KnYuQ68ZNV@straasha.imrryr.org>
 <CA+-99oKg07Sf6QTaZ3PgSbVPFE9zcuybYnAZAZL8Yobajt8eiw@mail.gmail.com>
 <X9rpZ8e/xWYZt/Rv@straasha.imrryr.org>
Message-ID: <X9r/Qk52glNxMzK+@straasha.imrryr.org>

On Thu, Dec 17, 2020 at 12:15:19AM -0500, Viktor Dukhovni wrote:

> I don't know whether indirection via "foldr = go" with `go`
> recursive and `foldr` "INLINABLE" and ditto for `traverse` would
> create further opportunities for optimisation when the instances
> are in a separate module.  Someone else might clear that up, or
> you could benchmark and see.  IIRC, recursive functions don't
> directly inline without such tweaks, but the tweaks might not
> help much.

Naive experiments seem to suggest that inlining via a `go` indirection
that captures `f` is somewhat helpful, but the real win is using a right
fold, vs.  your original flatten implementation.  Here's a comparison
with a somewhat branchy deep structure.

Flatten via Foldable:
---------------------

       2,281,024 bytes allocated in the heap
           3,312 bytes copied during GC
          44,408 bytes maximum residency (1 sample(s))
          25,224 bytes maximum slop
              17 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0         0 colls,     0 par    0.000s   0.000s     0.0000s    0.0000s
  Gen  1         1 colls,     0 par    0.000s   0.000s     0.0005s    0.0005s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.002s  (  0.002s elapsed)
  GC      time    0.000s  (  0.000s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    0.003s  (  0.003s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    1,234,320,346 bytes per MUT second

  Productivity  68.0% of total user, 68.0% of total elapsed

The posted flatten (1000x more allocations! 200x runtime):
--------------------

   2,651,027,056 bytes allocated in the heap
      11,386,968 bytes copied during GC
         164,424 bytes maximum residency (2 sample(s))
          29,320 bytes maximum slop
              27 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0       104 colls,     0 par    0.015s   0.015s     0.0001s    0.0004s
  Gen  1         2 colls,     0 par    0.001s   0.001s     0.0007s    0.0010s

  INIT    time    0.001s  (  0.001s elapsed)
  MUT     time    0.715s  (  0.715s elapsed)
  GC      time    0.016s  (  0.016s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    0.732s  (  0.732s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    3,705,952,327 bytes per MUT second

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

-- 
    Viktor.

{-# LANGUAGE DeriveFunctor #-}

module Nest
    ( Nest(..)
    ) where

data Nest a = Nil
            | Cons a (Nest a)
            | Nest (Nest a) (Nest a)
    deriving (Show, Functor)

instance Foldable Nest where
    {-# INLINE foldr #-}
    foldr f = go
      where
        go z Nil = z
        go z (Cons x n) = f x (go z n)
        go z (Nest x y) = go (go z y) x

instance Traversable Nest where
    {-# INLINE traverse #-}
    traverse f = go
      where
        go Nil = pure Nil
        go (Cons x n) = Cons <$> f x <*> go n
        go (Nest x y) = Nest <$> go x <*> go y

From strake888 at gmail.com  Thu Dec 17 08:02:31 2020
From: strake888 at gmail.com (Matthew Farkas-Dyck)
Date: Thu, 17 Dec 2020 00:02:31 -0800
Subject: [Haskell-cafe] Compilers written in Haskell that generate
	assembly
In-Reply-To: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>
References: <bcfe9e90-ad64-fca7-730a-54b8056a8346@gmail.com>
Message-ID: <CAL3m8eDDGh5E3t59fB_TutD6qbQG-n4uB2yBWRAwFAcs=Od6mQ@mail.gmail.com>

On 12/14/20, Vanessa McHale <vamchale at gmail.com> wrote:
> Have any of you written compilers or backends that generate assembly?
> Lots of projects seem to "end" at LLVM.

It's very rough work yet, but a low-level backend IR has been a
ongoing project of mine for a while now:
https://github.com/strake/esil.hs

I am designing a programming language, but LLVM was unfit for my
purposes as i need both dynamically-sized stack-allocated values and
arbitrary control flow.

> I have a project (https://hackage.haskell.org/package/kempe) where I
> used something like maximal munch and a linear register allocator, but I
> was wondering if there was anything more sophisticated out there!

I also have a graph-coloring register allocator:
https://hub.darcs.net/strake/reg-alloc-graph-color.hs

Unfortunately the docs just now are poor, at best. If this seems
potentially useful to you, let me know, so i can prioritize that!

(Esil uses the register allocator, but thru another interface which is
a compiler framework of mine.)

From johannes.waldmann at htwk-leipzig.de  Thu Dec 17 11:49:46 2020
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Thu, 17 Dec 2020 12:49:46 +0100
Subject: [Haskell-cafe] Intermediate Modern Haskell
Message-ID: <1fe460fc-5bf6-ccd6-cac6-74e314ec633e@htwk-leipzig.de>

Hi,

when I was in a similar situation two years ago
(an advanced course, after something basic) I had this list of topics
https://imweb.imn.htwk-leipzig.de/~waldmann/edu/modul/seminar/fkps/

This was not a lecture but "Seminar", meaning that students give talks.
Not all topics were actually presented -
depending on number, and preferences, of participants.

Meanwhile, I would probably add something on Foldable
(cf. Section 7 of https://arxiv.org/abs/1808.08329)

and I do plan to use https://thinkingwithtypes.com/ next time.

Best regards, Johannes.


PS: overview of my basic course:
https://imweb.imn.htwk-leipzig.de/~waldmann/talk/17/wflp/

with that regard - on your list of topics:

"Basic: ... algebraic data types" - comes last - good heavens!
For me, it's first. See also Joachim's CIS 194.

"likely cover: ... recursion schemes" - by all means do!
Second lecture of basic course! Full marks for Brent's version
of CIS194 https://www.cis.upenn.edu/~cis194/spring13/lectures.html

From david.feuer at gmail.com  Thu Dec 17 13:59:12 2020
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 17 Dec 2020 08:59:12 -0500
Subject: [Haskell-cafe] Intermediate Modern Haskell
In-Reply-To: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
References: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
Message-ID: <CAMgWh9vqgvDGJ5MDHOkB+e0sz3hL-Yw0M1Zg6Yb3jh8G6A0njw@mail.gmail.com>

Okasaki's debit analysis!

On Wed, Dec 16, 2020, 10:20 PM Jacques Carette <carette at mcmaster.ca> wrote:

> I will be teaching a second Haskell course next semester.  Let's assume
> that
>
> Introducing functional programming
>
> Getting started with Haskell and GHCi
>
> Basic types and definitions
>
> Designing and writing programs
>
> Data types, tuples and lists
>
> Programming with lists
>
> Defining functions over lists
>
> Playing the game: I/O in Haskell
>
> Reasoning about programs
>
> Generalization: patterns of computation
>
> Higher-order functions
>
> Developing higher-order programs
>
> Overloading, type classes and type checking
>
> Algebraic types
>
>
> (i.e. the first chapters of Thompson's Haskell: the Craft of Functional
> Programming book is "beginner, classic Haskell".  The next few chapters,
> namely
>
> Abstract data types
>
> Lazy programming
>
> Programming with monads
>
> Domain-Specific Languages
>
> Time and space behaviour
>
>
> would be (re)done at the start of such a second course. The question for
> cafe is: what else? I will likely cover:
> - Typeclassopedia
> - finally tagless
> - Template Haskell
> - Optics
> - GADTs
> - recursion schemes
>
>
> I should probably cover parser combinators, pretty-printing, cabal&stack.
> I know that http://dev.stephendiehl.com/hask/ gives me one heck of a
> smorgasbord of options, which is kind of a problem.
>
>
> Things I know I will not cover:
> - dependent types (if I was going to do that, I'd switch to Idris/Agda)
> - concurrency (don't ask)
>
>
> Jacques
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201217/9f65eeeb/attachment.html>

From komendantskaya at gmail.com  Thu Dec 17 15:02:55 2020
From: komendantskaya at gmail.com (Ekaterina Komendantskaya)
Date: Thu, 17 Dec 2020 15:02:55 +0000
Subject: [Haskell-cafe] PhD studentships in Robotics (Edinburgh Center for
	Robotics)
Message-ID: <CAEQEJxLj_ePtwAbC4_N5DUk2FnAgmh7Z6wXK1HsA35W0+iV__w@mail.gmail.com>

Dear colleagues,

Edinburgh Center for Robotics has published a fresh call for PhD
scholarship applications. There will be space for verification and
programming language research: see item 3: *" explainable AI,
certification, verification, safety, security, multi-agent interactions;"*

It is an ideal opportunity for PhD students who wish to apply their
knowledge in Programming Languages and Verification to the growing field of
Robotics and Autonomous systems research.

See below the official advert and contact me directly if you need
more information.

***************************************

The Edinburgh Centre of Robotics is offering exciting PhD Studentships
<https://www.edinburgh-robotics.org/projects-list> for September 2021
through the EPSRC Centre for Doctoral Training in Robotics and Autonomous
Systems (CDT-RAS). A limited number of industry PhD placements may also be
available and information about these opportunities is posted here
<https://www.edinburgh-robotics.org/industry-studentships>.



*Closing date 29**th** January 2021*



Heriot-Watt University and the University of Edinburgh are jointly offering
an exciting opportunity to study a PhD through an innovative 4-year PhD
training programme, drawing on our extensive experience with postgraduate
teaching and research supervision in the area of Robotics and Autonomous
Systems.   The Centre's goal is to train
innovation-ready robotics researchers to be part of a multi-disciplinary
team, focusing on *Safe Interaction for Robotics.*  PhD candidates
specialise in one of the following four areas, whilst gaining a deep
understanding of technical aspects and theoretical foundations:

1. *Physical Interactions**: *control, actuation, compliance, sensing,
mapping, planning, embodiments, swarms;

2. *People Interactions*: human-robot interaction, affective robotics,
smart spaces, human-robot teaming, collaborative decision-making, cobots,
multimodal interfaces;

3. *Self-Interactions*: condition monitoring, prognosis, explainable AI,
certification, verification, safety, security, multi-agent interactions;

4. *Interaction Enablers*: vision, embedded and parallel computing, novel
and soft fabrication methods, optimisation, (transparent) machine learning,
deep reinforcement learning and other AI techniques inc. natural language
processing (NLP).



Achieving impact with robotics also requires non-technical skills, for
example an understanding of technology translation, creativity and
entrepreneurial processes. These are an essential component of
the CDT programme, captured in the #Cauldron
<https://www.edinburgh-robotics.org/content/cauldron> training programme.



Why join us?

·  Flexible programme structure allows students to tailor courses to match
research area of interest in year one, ensuring students have a strong
general grounding in responsible research, current theory, methods and
applications as a solid foundation for their PhD research.

·  Cohort approach with activities including group projects and away days
encourages peer support and cross fertilisation of ideas.

·  Opportunity for international placement in prestigious research
laboratory in year three.

·  Bespoke #Cauldron training programme to provide non-technical skills
such as understanding of technology translation, creativity, and
entrepreneurial processes.

·  Gateway seminars with prestigious speakers.

·  Fund to seed innovation.

·  Fully funded posts available paying stipend and Home fees, limited posts
for overseas students



More information on PhD placements and how to apply:

www.edinburgh-robotics.org/apply

***************


Prof. Ekaterina Komendantskaya
Department of Computer Science
School of Mathematical and Computer Sciences
Earl Mountbatten Building  [ building 21, office G26 ]
Heriot-Watt University
Edinburgh, UK, EH14 4AS
+44 (0)131 451 8283
http://www.macs.hw.ac.uk/~ek19/
http://www.laiv.ac.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201217/2891f35e/attachment.html>

From carette at mcmaster.ca  Thu Dec 17 22:47:54 2020
From: carette at mcmaster.ca (Carette, Jacques)
Date: Thu, 17 Dec 2020 22:47:54 +0000
Subject: [Haskell-cafe] Intermediate Modern Haskell
In-Reply-To: <CAJN5CVLirirmxHf1vKd=qQeff=mZUsvcbzU5Fjw3LqGhhQ8oCQ@mail.gmail.com>
References: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
 <CAJN5CVLirirmxHf1vKd=qQeff=mZUsvcbzU5Fjw3LqGhhQ8oCQ@mail.gmail.com>
Message-ID: <YT1PR01MB3657402AC17B49033CF06B26B4C40@YT1PR01MB3657.CANPRD01.PROD.OUTLOOK.COM>

Excellent question. I am not focused on any project/applications in particular. I do have a personal bias towards “languages” and processing of them. Haskell really excels at that.  I’m getting the students in my *grad* class (on generative programming) to do partial evaluators using finally tagless the way “it should have been done” in the paper, if we’d been all-knowing 10 years ago 😉 .  I don’t think we’ll get to that in the undergrad class. Maybe as bonus questions.

Thanks for the timely reminder to try extra-hard to put all the features in context. My background being Pure Math (long ago), that sometimes leads me to forget that abstraction for abstraction’s sake isn’t everyone’s cup of tea!

Certainly things like you mention are excellent topics that fits well with the kinds of programs that I like to write, and that Haskell is fairly well suited for (I’m become an Agda fanboy, so it feels like I’m really slumming it by coding in Haskell, even worse when I’m working in my metaocaml code base).

From: Tikhon Jelvis <tikhon at jelv.is>
Sent: December 16, 2020 10:42 PM
To: Carette, Jacques <carette at mcmaster.ca>
Cc: haskell-cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Intermediate Modern Haskell

What kind of projects and applications are you focused on? In my experience, the difficulty in learning—and teaching—"advanced" Haskell topics is less in the topic itself and more in the level of abstraction involved. I know that I struggled with GADTs and even existential types not because of the features themselves but because I had real trouble putting the features into context and understanding how I would use them. Just *why* are those abstractions in particular interesting?

I can recommend some of my personal favorite topics like streaming libraries, FRP, automatic differentiation and the probability monad, but whether that recommendation makes sense depends on how you want to use those topics. Alternatively, if you have some specific things you would want to build with the class, we could suggest topics that fit those goals.

On Wed, Dec 16, 2020, 19:22 Jacques Carette <carette at mcmaster.ca<mailto:carette at mcmaster.ca>> wrote:

I will be teaching a second Haskell course next semester.  Let's assume that

Introducing functional programming

Getting started with Haskell and GHCi

Basic types and definitions

Designing and writing programs

Data types, tuples and lists

Programming with lists

Defining functions over lists

Playing the game: I/O in Haskell

Reasoning about programs

Generalization: patterns of computation

Higher-order functions

Developing higher-order programs

Overloading, type classes and type checking

Algebraic types



(i.e. the first chapters of Thompson's Haskell: the Craft of Functional Programming book is "beginner, classic Haskell".  The next few chapters, namely

Abstract data types

Lazy programming

Programming with monads

Domain-Specific Languages

Time and space behaviour



would be (re)done at the start of such a second course. The question for cafe is: what else? I will likely cover:
- Typeclassopedia
- finally tagless
- Template Haskell
- Optics
- GADTs
- recursion schemes



I should probably cover parser combinators, pretty-printing, cabal&stack. I know that http://dev.stephendiehl.com/hask/ gives me one heck of a smorgasbord of options, which is kind of a problem.



Things I know I will not cover:
- dependent types (if I was going to do that, I'd switch to Idris/Agda)
- concurrency (don't ask)



Jacques
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view 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/20201217/848cb7d3/attachment.html>

From carette at mcmaster.ca  Thu Dec 17 22:51:20 2020
From: carette at mcmaster.ca (Carette, Jacques)
Date: Thu, 17 Dec 2020 22:51:20 +0000
Subject: [Haskell-cafe] Intermediate Modern Haskell
In-Reply-To: <CAMgWh9vqgvDGJ5MDHOkB+e0sz3hL-Yw0M1Zg6Yb3jh8G6A0njw@mail.gmail.com>
References: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
 <CAMgWh9vqgvDGJ5MDHOkB+e0sz3hL-Yw0M1Zg6Yb3jh8G6A0njw@mail.gmail.com>
Message-ID: <YT1PR01MB3657A94EF6C8D19102EF321DB4C40@YT1PR01MB3657.CANPRD01.PROD.OUTLOOK.COM>

Which also reminds me of the Hinze-Paterson paper on Finger Trees. Excellent.

From: David Feuer <david.feuer at gmail.com>
Sent: December 17, 2020 8:59 AM
To: Carette, Jacques <carette at mcmaster.ca>
Cc: haskell-cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Intermediate Modern Haskell

Okasaki's debit analysis!

On Wed, Dec 16, 2020, 10:20 PM Jacques Carette <carette at mcmaster.ca<mailto:carette at mcmaster.ca>> wrote:

I will be teaching a second Haskell course next semester.  Let's assume that

Introducing functional programming

Getting started with Haskell and GHCi

Basic types and definitions

Designing and writing programs

Data types, tuples and lists

Programming with lists

Defining functions over lists

Playing the game: I/O in Haskell

Reasoning about programs

Generalization: patterns of computation

Higher-order functions

Developing higher-order programs

Overloading, type classes and type checking

Algebraic types



(i.e. the first chapters of Thompson's Haskell: the Craft of Functional Programming book is "beginner, classic Haskell".  The next few chapters, namely

Abstract data types

Lazy programming

Programming with monads

Domain-Specific Languages

Time and space behaviour



would be (re)done at the start of such a second course. The question for cafe is: what else? I will likely cover:
- Typeclassopedia
- finally tagless
- Template Haskell
- Optics
- GADTs
- recursion schemes



I should probably cover parser combinators, pretty-printing, cabal&stack. I know that http://dev.stephendiehl.com/hask/ gives me one heck of a smorgasbord of options, which is kind of a problem.



Things I know I will not cover:
- dependent types (if I was going to do that, I'd switch to Idris/Agda)
- concurrency (don't ask)



Jacques
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view 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/20201217/b9032e9f/attachment.html>

From carette at mcmaster.ca  Thu Dec 17 23:01:30 2020
From: carette at mcmaster.ca (Carette, Jacques)
Date: Thu, 17 Dec 2020 23:01:30 +0000
Subject: [Haskell-cafe] Intermediate Modern Haskell
In-Reply-To: <1fe460fc-5bf6-ccd6-cac6-74e314ec633e@htwk-leipzig.de>
References: <1fe460fc-5bf6-ccd6-cac6-74e314ec633e@htwk-leipzig.de>
Message-ID: <YT1PR01MB36574375701CA861323BFF48B4C40@YT1PR01MB3657.CANPRD01.PROD.OUTLOOK.COM>

Hurray for google translate... I could have dealt with French easily, deciphered quite a few other Romance languages, but German isn't in my bag of tricks. Oh, it wasn't hard to mostly guess, but since I didn't have to...



Nice list of topics. I should get a copy of Thinking with Types and officially review it for this purpose. To late for this year, maybe next time.



On the topic list: this is the TOC of Thompson's book. Naturally algebraic data types show up already in chapter 1, but are not named as such until later, and then keep getting revisited.  So it's not as bad as that! 😉



Yes, Brent's version of CIS194 is brilliant. I could probably use material from the latter half of that course too. [Brent and I go way back - look at the 2nd paragraph of the Acknowledgements in his PhD thesis for details.]



> -----Original Message-----

> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Johannes

> Waldmann

> Sent: December 17, 2020 6:50 AM

> To: Haskell Cafe <haskell-cafe at haskell.org>

> Subject: Re: [Haskell-cafe] Intermediate Modern Haskell

>

> Hi,

>

> when I was in a similar situation two years ago (an advanced course, after

> something basic) I had this list of topics https://imweb.imn.htwk-<https://imweb.imn.htwk-leipzig.de/~waldmann/edu/modul/seminar/fkps/>

> leipzig.de/~waldmann/edu/modul/seminar/fkps/<https://imweb.imn.htwk-leipzig.de/~waldmann/edu/modul/seminar/fkps/>

>

> This was not a lecture but "Seminar", meaning that students give talks.

> Not all topics were actually presented - depending on number, and preferences,

> of participants.

>

> Meanwhile, I would probably add something on Foldable (cf. Section 7 of

> https://arxiv.org/abs/1808.08329)

>

> and I do plan to use https://thinkingwithtypes.com/ next time.

>

> Best regards, Johannes.

>

>

> PS: overview of my basic course:

> https://imweb.imn.htwk-leipzig.de/~waldmann/talk/17/wflp/

>

> with that regard - on your list of topics:

>

> "Basic: ... algebraic data types" - comes last - good heavens!

> For me, it's first. See also Joachim's CIS 194.

>

> "likely cover: ... recursion schemes" - by all means do!

> Second lecture of basic course! Full marks for Brent's version of CIS194

> https://www.cis.upenn.edu/~cis194/spring13/lectures.html

> _______________________________________________

> Haskell-Cafe mailing list

> To (un)subscribe, modify options or view 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/20201217/9467795b/attachment-0001.html>

From jack at jackkelly.name  Thu Dec 17 23:24:25 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Thu, 17 Dec 2020 23:24:25 GMT
Subject: [Haskell-cafe] Intermediate Modern Haskell
In-Reply-To: <YT1PR01MB3657A94EF6C8D19102EF321DB4C40@YT1PR01MB3657.CANPRD01.PROD.OUTLOOK.COM>
References: <YT1PR01MB3657A94EF6C8D19102EF321DB4C40@YT1PR01MB3657.CANPRD01.PROD.OUTLOOK.COM>
 <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
 <CAMgWh9vqgvDGJ5MDHOkB+e0sz3hL-Yw0M1Zg6Yb3jh8G6A0njw@mail.gmail.com>
Message-ID: <66fa984fa18dfdb1f448c466730520de@jackkelly.name>

Speaking of finger trees, this video does an excellent job of explaining them, if you're looking for another angle on the idea (either use the accompanying paper, or mine the video for lecture ideas):

https://www.youtube.com/watch?v=ip92VMpf_-A

HTH,

-- Jack

December 18, 2020 8:51 AM, "Carette, Jacques" <carette at mcmaster.ca> wrote:

> Which also reminds me of the Hinze-Paterson paper on Finger Trees. Excellent.
> 
> On Wed, Dec 16, 2020, 10:20 PM Jacques Carette <carette at mcmaster.ca> wrote:
> 
>> I will be teaching a second Haskell course next semester.

From fumiexcel at gmail.com  Fri Dec 18 05:09:48 2020
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Fri, 18 Dec 2020 14:09:48 +0900
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <4515611f-907c-a0e2-8c92-fc395db9ca65@durchholz.org>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
 <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
 <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
 <b47992b8-33ef-fa55-794a-997adab4f07f@durchholz.org>
 <d6381b4d-104a-6585-6a47-b377d3758f6e@vex.net>
 <4515611f-907c-a0e2-8c92-fc395db9ca65@durchholz.org>
Message-ID: <CAATCwU=bqHBV2=uYrX_hdKf7UbXji-=Uv-NRDWhi4c4yUu2fBw@mail.gmail.com>

Thanks for the feedback. Apparently it's controversial so I decided not to
submit the proposal.

2020年12月11日(金) 14:15 Joachim Durchholz <jo at durchholz.org>:

> Am 11.12.20 um 00:06 schrieb Albert Y. C. Lai:
> > On 2020-12-10 4:49 p.m., Joachim Durchholz wrote:
> >> Will -Wall prevent :load?
> >> If not, this particular argument is beside the point.
> >
> > -Wall will hide the few warnings I need in the haystack of a lot of
> > warnings I don't need.
>
> You said
>
>  > Because ghci is so much more informative when :load succeeds.
>
> which struck a cognitive dissonance in me, so my question still is: Will
> a warning from -Wall prevent :load from succeeding?
>
> 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/20201218/a9c0e23d/attachment.html>

From godzbanebane at gmail.com  Fri Dec 18 10:23:16 2020
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Fri, 18 Dec 2020 12:23:16 +0200
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <CAATCwU=bqHBV2=uYrX_hdKf7UbXji-=Uv-NRDWhi4c4yUu2fBw@mail.gmail.com>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
 <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
 <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
 <b47992b8-33ef-fa55-794a-997adab4f07f@durchholz.org>
 <d6381b4d-104a-6585-6a47-b377d3758f6e@vex.net>
 <4515611f-907c-a0e2-8c92-fc395db9ca65@durchholz.org>
 <CAATCwU=bqHBV2=uYrX_hdKf7UbXji-=Uv-NRDWhi4c4yUu2fBw@mail.gmail.com>
Message-ID: <CABT0e9o9HVp6JWOCS_94U1NhknaUdqkjfCxwtAUNYHev6SxEjA@mail.gmail.com>

How about at least encouraging newcomers to try out -Wall in some visible
place? Especially for newcomers to programming in general who are not used
to turning on warnings. In my teaching experience it easily exposes "code
smells" in students' code, but someone learning on their own/learning from
a teacher who doesn't turn on -Wall would entirely miss this.

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

From P.Achten at cs.ru.nl  Fri Dec 18 15:59:41 2020
From: P.Achten at cs.ru.nl (Peter Achten)
Date: Fri, 18 Dec 2020 16:59:41 +0100
Subject: [Haskell-cafe] [TFPIE'21] Second Call For Papers: Trends in
 Functional Programming *in Education* 2021,
 16 February 2021 (with Lambda Days 2021 & TFP 2021)
Message-ID: <0855d066-6763-6b13-5b70-e51a8f93968a@cs.ru.nl>

-----------------------------------
    TFPIE 2021 2nd Call for papers
-----------------------------------
https://wiki.tfpie.science.ru.nl/TFPIE2021#TFPIE_2021
(February 16 2021, co-organized with TFP 2021 and Lambda Days 2021)

Because of the covid pandemic, the events are online this year.

The goal of the International Workshops on Trends in Functional 
Programming in
Education is to gather researchers, professors, teachers, and all 
professionals
that use or are interested in the use of functional programming in 
education.
TFPIE aims to be a venue where novel ideas, classroom-tested ideas, and 
work in
progress on the use of functional programming in education are 
discussed. The
one-day workshop will foster a spirit of open discussion by having a review
process for publication after the workshop.

TFPIE 2021 welcomes submissions in the above mentioned areas. This year 
many
teaching programmes have had to make a rapid transition to online 
teaching, and
we explicitly solicit papers that explore this area of teaching functional
programming.

Topics of interest include, but are not limited to:
-  FP and beginning CS students
-  FP and Computational Thinking
-  FP and Artificial Intelligence
-  FP in Robotics
-  FP and Music
-  Advanced FP for undergraduates
-  FP in graduate education
-  Engaging students in research using FP
-  FP in Programming Languages
-  FP in the high school curriculum
-  FP as a stepping stone to other CS topics
-  FP and Philosophy
-  The pedagogy of teaching FP
-  FP and e-learning: MOOCs, automated assessment etc.
-  Best Lectures - more details below

In addition to papers, we are requesting best lecture presentations. 
What's your
best lecture topic in an FP related course? Do you have a fun way to 
present FP
concepts to novices or perhaps an especially interesting presentation of a
difficult topic? In either case, please consider sharing it. Best 
lecture topics
will be selected for presentation based on a short abstract describing the
lecture and its interest to TFPIE attendees. The length of the presentation
should be comparable to that of a paper. On top of the lecture itself,
the presentation can also provide commentary on the lecture.

Submissions
Potential presenters are invited to submit an extended abstract (4-6 
pages) or a
draft paper (up to 20 pages) in EPTCS style. The authors of accepted
presentations will have their preprints and their slides made available 
on the
workshop's website. Papers and abstracts can be submitted via easychair 
at the
following link:

https://easychair.org/conferences/?conf=tfpie2021

After the workshop, presenters are invited to submit (a revised version of)
their article for review. The PC will select the best articles for 
publication
in the Electronic Proceedings in Theoretical Computer Science (EPTCS).
Articles rejected for presentation and extended abstracts will not be 
formally
reviewed by the PC.

Dates
-  Submission deadline: January 11 2021, Anywhere on Earth.
-  Notification: January 15 2021
-  Workshop: February 16 2021
-  Submission for formal review: April 20 2021, Anywhere on Earth.
-  Notification of full article: June 7 2021
-  Camera ready: July 1st 2021

Program Committee
- Peter Achten,    Radboud University, Netherlands (chair)
- Edwin Brady,     University of St Andrews, UK
- Laura Castro,    Universidade da Coruña, Spain
- Stephen Chang,   University of Massachusetts Boston, USA
- Youyou Cong,     Tokyo Institute of Technology, Japan
- Matthew Flatt,   University of Utah, USA
- Seth Fogarty,    Trinity University, USA
- Alex Gerdes,     University of Gothenburg, Sweden
- Gabriele Keller, Utrecht University, Netherlands
- Prabhakar Ragde, University of Waterloo, Canada
- Melinda Tóth,    Eötvös Loránd University, Budapest, Hungary

Registration
TFPIE is part of Lambda Days. Please visit the Lambda Days 2021 pages 
when registration
information becomes available.

Only papers that have been presented at TFPIE may be submitted to the 
post-reviewing
process.

Information on Lambda Days is available at 
https://www.lambdadays.org/lambdadays2021
Information on TFP         is available at http://tfp2021.org


From mgajda at mimuw.edu.pl  Sun Dec 20 01:47:01 2020
From: mgajda at mimuw.edu.pl (mgajda at mimuw.edu.pl)
Date: Sun, 20 Dec 2020 01:47:01 UTC
Subject: [Haskell-cafe] [CFP]Agile and Functional Data Pipelines workshop
Message-ID: <20201220014701.5c749982ff53d23d@migamake.com>

Dear Friends,

The emerging interest in the rigorous and agile data science and
functional ETL pipelines has driven the developments of many new
libraries, frameworks and methodologies. We invite industry
practitioners and academics to present their latest work on agile
functional data pipelines as a workshop at the EDI'2021 conference.

Call for papers
===============

The following would be accepted:

-   Exposures of methodologies for building agile functional data
    pipelines
-   Presentations of frameworks used for data pipelines in industry and
    academia
-   Experience reports from building of data pipelines in industry and
    academia
-   Benchmarks and optimization of agile data pipeline frameworks
-   Solutions to data integration and exchange problems within ETL
    pipelines.

In particular, we encourage:

-   Agile functional data methodologists
-   Authors of ETL frameworks, streaming libraries and databases,
    reactive streaming, streaming benchmarks, high-performance workflow
    engines
-   Position papers on the use of agile and functional data
    methodologies
-   Descriptions of environments for interactive and live programming
    with data
-   Benchmarks of state-of-the-art solutions for agile functional data
    pipelines.

Details at https://afdp.github.io

Important dates
===============

Abstract registration deadline
  : December 27th, 2020 (extended)

Submission deadline
  : January 3rd, 2020 (extended)

Acceptance notification
  : January 12th 2021

Final manuscripts
:   January 23rd, 2021

Presentation at the conference
:   March 23rd-26th 2021

Submission instructions
=======================

Original, unpublished papers are solicited for presentation at the AFDP
workshop. Prospective authors are invited to submit papers
(electronically, PDF only) that are no longer than 6 pages for full
papers, including all figures and references. For work-in-progress, we
also solicit extended abstracts for presentations.

The submitted paper must be formatted according to the guidelines of
Procedia Computer Science. All accepted papers will be published in
Procedia Computer Science.

Location
========

This workshop will be held as a part of [The 4th International
Conference on Emerging Data and Industry 4.0
(EDI40)](http://cs-conferences.acadiau.ca/EDI40-21/) held on March 23 -
26, 2021 in Warsaw, Poland.

--
  Best regards
    Michał


From mgajda at mimuw.edu.pl  Sun Dec 20 02:08:15 2020
From: mgajda at mimuw.edu.pl (mgajda at mimuw.edu.pl)
Date: Sun, 20 Dec 2020 02:08:15 UTC
Subject: [Haskell-cafe] [CFP]Automatic Debugging,
	Error and Impact Reporting Approaches workshop
Message-ID: <20201220020815.96914cea13cdaaea@migamake.com>

Dear Friends,

The emerging interest in the rigorous and agile data science and
functional ETL pipelines has driven the developments of many new
libraries, frameworks and methodologies. We invite industry
practitioners and academics to present their latest work on agile
functional data pipelines as a workshop at the EDI'2021 conference.

Call for papers
===============

The following would be accepted:

-   Exposures of methodologies for building agile functional data
    pipelines
-   Presentations of frameworks used for data pipelines in industry and
    academia
-   Experience reports from building of data pipelines in industry and
    academia
-   Benchmarks and optimization of agile data pipeline frameworks
-   Solutions to data integration and exchange problems within ETL
    pipelines.

In particular, we encourage:

-   Agile functional data methodologists
-   Authors of ETL frameworks, streaming libraries and databases,
    reactive streaming, streaming benchmarks, high-performance workflow
    engines
-   Position papers on the use of agile and functional data
    methodologies
-   Descriptions of environments for interactive and live programming
    with data
-   Benchmarks of state-of-the-art solutions for agile functional data
    pipelines.

Details at https://afdp.github.io

Important dates
===============

Abstract registration deadline
  : December 27th, 2020 (extended)

Submission deadline
  : January 3rd, 2020 (extended)

Acceptance notification
  : January 12th 2021

Final manuscripts
:   January 23rd, 2021

Presentation at the conference
:   March 23rd-26th 2021

Submission instructions
=======================

Original, unpublished papers are solicited for presentation at the AFDP
workshop. Prospective authors are invited to submit papers
(electronically, PDF only) that are no longer than 6 pages for full
papers, including all figures and references. For work-in-progress, we
also solicit extended abstracts for presentations.

The submitted paper must be formatted according to the guidelines of
Procedia Computer Science. All accepted papers will be published in
Procedia Computer Science.

Location
========

This workshop will be held as a part of [The 4th International
Conference on Emerging Data and Industry 4.0
(EDI40)](http://cs-conferences.acadiau.ca/EDI40-21/) held on March 23 -
26, 2021 in Warsaw, Poland.

--
  Best regards
    Michał


From mgajda at mimuw.edu.pl  Sun Dec 20 02:11:48 2020
From: mgajda at mimuw.edu.pl (mgajda at mimuw.edu.pl)
Date: Sun, 20 Dec 2020 02:11:48 UTC
Subject: [Haskell-cafe] [CFP]Automatic Debugging,
	Error and Impact Reporting Approaches workshop
Message-ID: <20201220021148.b549612b700e5be5@migamake.com>

International workshop on Automatic Debugging, Error and Impact Reporting Approaches
====================================================================================

Automatic debugging, error fixing, and reporting is getting more and
more popularity across different research communities. We aim to provide
a forum for exchange of latest work and document best practices across
different disciplines.

-   Automatic reproducers like those generated by LLDB
-   Automatic unit test extraction and using decorators and code
    inspection
-   Automatic reproducer/error case minimization
-   Interactive error recovery systems and their applications
-   Error algebras and error-tracing algebras
-   Formalizations of debugging
-   Fault impact reporting and accuracy estimation
-   Provenance tracking in term rewriting
-   Error analytics pipelines and databases
-   Error monitoring in intrusion detection systems
-   Delta debugging
-   Automatic generation of error dashboards
-   Global fault analysis of systems with both computational and human
    component, and cyber-physical systems.

Note that workshop particularly encourage treatment of all kinds of
errors, be they compile-time, run-time, discrepancies between intent and
specification, hardware failures, or human errors to the degree to which
they are amenable to automatic analysis and reporting.

Intended audience
-----------------

-   Experts in automated debugging, error fixing wishing to exchange
    knowledge with their peers.
-   Industry practitioners interested to learn more about approaches to
    automated analysis of errors.
-   Academics in quest for formalization of automated error analysis and
    fixing
-   Financial industry practitioners interested in computer science
    approaches to satisfy risk reporting guidelines with respect to
    error impact tracing and reporting of accuracy
-   Management scientist looking for automatic global fault reporting
    and impact reporting methodologies.

Because of this, we encourage you to reference used theories and
methodologies, and provide a introductions with use cases.

The workshop is held as a part of [Programming Conference
2021](https://2021.programming-conference.org/).

Goals
-----

-   Our main goal is to encourage social exchange of ideas related to
    automatic error analysis and impact reporting.
-   We call for position papers, research expositions, early stage work,
    and industry experience papers to encourage exchange of on-going
    research and implementation efforts.

Important dates
===============

Abstract registration deadline
:   January 15th, 2021

Submission deadline
:   January 20th, 2021

Author response period
:   February 14th-21st, 2021

Acceptance notification
:   March 1st, 2021
Programme committee
-------------------

-   Kenichi Asai, [Ochanomizu
    University](http://pllab.is.ocha.ac.jp/~asai/)
-   Michał J. Gajda, [Migamake Pte Ltd](https://migamake.com) *(chair)*
-   Michał "phoe" Herda [\#lisp @ Freenode
    IRC](https://netsplit.de/channels/details.php?room=%23lisp&net=freenode)
-   Henrik Nilsson [University of
    Nottingham](http://www.cs.nott.ac.uk/~psznhn/)
-   Vladimir Panteleev
    [DustMite](https://github.com/CyberShadow/DustMite)
-   Francesco Spegni [Università Politecnica delle
    Marche](https://www.dii.univpm.it/francesco.spegni)
-   Dmitry Vostokov [DumpAnalysis.org](https://DumpAnalysis.org)
-   Vadim Zaytsev [Universiteit Twente](http://grammarware.net)

Submissions
===========

We welcome original, unpublished papers of the following forms: full
articles, extended abstracts, case studies.

Please submit your paper or extended abstract [by
EasyChair](https://easychair.org/conferences/?conf=adeira2021). You may
[contact the committee chair](https://www.linkedin.com/in/mjgajda/) with
any questions you have about submission.

The paper evaluation will use the following criteria: \* Novelty \*
Clarity of exposition \* Transferrability of innovation(s) to other
domains \* Scientific rigour and form of the article \*
Cross-pollination potential with other papers \* Preliminary papers will
be offered feedback on how to improve the quality in all these factors
before and during the workshop

All submissions should use [ACM DL
template](https://www.acm.org/publications/proceedings-template).

From raoknz at gmail.com  Sun Dec 20 05:27:57 2020
From: raoknz at gmail.com (Richard O'Keefe)
Date: Sun, 20 Dec 2020 18:27:57 +1300
Subject: [Haskell-cafe] Intermediate Modern Haskell
In-Reply-To: <YT1PR01MB3657402AC17B49033CF06B26B4C40@YT1PR01MB3657.CANPRD01.PROD.OUTLOOK.COM>
References: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
 <CAJN5CVLirirmxHf1vKd=qQeff=mZUsvcbzU5Fjw3LqGhhQ8oCQ@mail.gmail.com>
 <YT1PR01MB3657402AC17B49033CF06B26B4C40@YT1PR01MB3657.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <CABcYAdJMo3c7rPR68E4pWaZSf0RX7uA2K7aX_LGOVLLtvx9Jog@mail.gmail.com>

Have you looked at Richard Bird's "Thinking Functionally"?

On Fri, 18 Dec 2020 at 11:53, Carette, Jacques <carette at mcmaster.ca> wrote:

> Excellent question. I am not focused on any project/applications in
> particular. I do have a personal bias towards “languages” and processing of
> them. Haskell really excels at that.  I’m getting the students in my *
> *grad** class (on generative programming) to do partial evaluators using
> finally tagless the way “it should have been done” in the paper, if we’d
> been all-knowing 10 years ago 😉 .  I don’t think we’ll get to that in
> the undergrad class. Maybe as bonus questions.
>
>
>
> Thanks for the timely reminder to try extra-hard to put all the features
> in context. My background being Pure Math (long ago), that sometimes leads
> me to forget that abstraction for abstraction’s sake isn’t everyone’s cup
> of tea!
>
>
>
> Certainly things like you mention are excellent topics that fits well with
> the kinds of programs that I like to write, and that Haskell is fairly well
> suited for (I’m become an Agda fanboy, so it feels like I’m really slumming
> it by coding in Haskell, even worse when I’m working in my metaocaml code
> base).
>
>
>
> *From:* Tikhon Jelvis <tikhon at jelv.is>
> *Sent:* December 16, 2020 10:42 PM
> *To:* Carette, Jacques <carette at mcmaster.ca>
> *Cc:* haskell-cafe <haskell-cafe at haskell.org>
> *Subject:* Re: [Haskell-cafe] Intermediate Modern Haskell
>
>
>
> What kind of projects and applications are you focused on? In my
> experience, the difficulty in learning—and teaching—"advanced" Haskell
> topics is less in the topic itself and more in the level of abstraction
> involved. I know that I struggled with GADTs and even existential types not
> because of the features themselves but because I had real trouble putting
> the features into context and understanding how I would use them. Just
> *why* are those abstractions in particular interesting?
>
>
>
> I can recommend some of my personal favorite topics like streaming
> libraries, FRP, automatic differentiation and the probability monad, but
> whether that recommendation makes sense depends on how you want to use
> those topics. Alternatively, if you have some specific things you would
> want to build with the class, we could suggest topics that fit those goals.
>
>
>
> On Wed, Dec 16, 2020, 19:22 Jacques Carette <carette at mcmaster.ca> wrote:
>
> I will be teaching a second Haskell course next semester.  Let's assume
> that
>
> Introducing functional programming
>
> Getting started with Haskell and GHCi
>
> Basic types and definitions
>
> Designing and writing programs
>
> Data types, tuples and lists
>
> Programming with lists
>
> Defining functions over lists
>
> Playing the game: I/O in Haskell
>
> Reasoning about programs
>
> Generalization: patterns of computation
>
> Higher-order functions
>
> Developing higher-order programs
>
> Overloading, type classes and type checking
>
> Algebraic types
>
>
>
> (i.e. the first chapters of Thompson's Haskell: the Craft of Functional
> Programming book is "beginner, classic Haskell".  The next few chapters,
> namely
>
> Abstract data types
>
> Lazy programming
>
> Programming with monads
>
> Domain-Specific Languages
>
> Time and space behaviour
>
>
>
> would be (re)done at the start of such a second course. The question for
> cafe is: what else? I will likely cover:
> - Typeclassopedia
> - finally tagless
> - Template Haskell
> - Optics
> - GADTs
> - recursion schemes
>
>
>
> I should probably cover parser combinators, pretty-printing, cabal&stack.
> I know that http://dev.stephendiehl.com/hask/ gives me one heck of a
> smorgasbord of options, which is kind of a problem.
>
>
>
> Things I know I will not cover:
> - dependent types (if I was going to do that, I'd switch to Idris/Agda)
> - concurrency (don't ask)
>
>
>
> Jacques
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201220/1a1a60ba/attachment.html>

From kindaro at gmail.com  Sun Dec 20 11:23:36 2020
From: kindaro at gmail.com (Ignat Insarov)
Date: Sun, 20 Dec 2020 16:23:36 +0500
Subject: [Haskell-cafe] Where do trivial functions on the usual containers
	live?
Message-ID: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>

Hello.

I am looking for a place where I can find or put some simple functions that I
expect but do not find in the `containers` or elsewhere in the standard
libraries. Some examples I have in mind:

* Group a collection by an equivalence relation:

      classify ∷ Ord π ⇒ (a → π) → [a] → [[a]]

* From a finite map, get a map from its range to its fibers:

      fibers ∷ (Ord k, Ord v) ⇒ Map k v → Map v (NonEmpty k)

* Put a type into the diagonal of its square:

      diagonal = λx → (x, x)

These are all very common and trivial mathematical constructions and I really
want such things to be common place in Haskell, so that they may have a
canonical, polished definition. It is unfeasible to put them into the standard
libraries. _(Attempts were made.)_ So I wonder if there is a package around that
would accept them!

From lemming at henning-thielemann.de  Sun Dec 20 12:44:01 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 20 Dec 2020 13:44:01 +0100 (CET)
Subject: [Haskell-cafe] Where do trivial functions on the usual
 containers live?
In-Reply-To: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>
References: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2012201339420.6856@sputnik>


On Sun, 20 Dec 2020, Ignat Insarov wrote:

> I am looking for a place where I can find or put some simple functions that I
> expect but do not find in the `containers` or elsewhere in the standard
> libraries.

I have my own utility library for such functions. However, it does not and 
shall not depend on 'containers'.

> Some examples I have in mind:
>
> * Group a collection by an equivalence relation:
>
>      classify ∷ Ord π ⇒ (a → π) → [a] →a]]

If the grouped elements must be consecutive then I have 
Data.List.Key.group. But I guess, that Ord means that you want to group 
all elements with the same key in one group. Then I would use Map anyway 
for representing the result.

> * From a finite map, get a map from its range to its fibers:
>
>      fibers ∷ (Ord k, Ord v) ⇒ Map k v → Map v (NonEmpty k)
>
> * Put a type into the diagonal of its square:
>
>      diagonal = λx → (x, x)

I have Data.Tuple.HT.double. But recently the name 'dup' was discussed 
here.

From monkleyon at gmail.com  Sun Dec 20 13:39:25 2020
From: monkleyon at gmail.com (MarLinn)
Date: Sun, 20 Dec 2020 14:39:25 +0100
Subject: [Haskell-cafe] Where do trivial functions on the usual
 containers live?
In-Reply-To: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>
References: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>
Message-ID: <dcc865b4-61de-0d4d-3f8f-f257ac2cad82@gmail.com>

> I am looking for a place where I can find or put some simple functions that I
> expect but do not find in the `containers` or elsewhere in the standard
> libraries.

For now, I can't see a good place for any of your suggestions. But maybe 
even discussing potential why-not's may further the discussion.


> * Group a collection by an equivalence relation:
>
>        classify ∷ Ord π ⇒ (a → π) → [a] → [[a]]

If the provided function is indeed an "equivalence relation", shouldn't 
the type be Eq π ⇒ (a → π) → [a] → [[a]], which is basically 
Data.List.groupBy? On the other hand if the resulting list is supposed 
to be ordered, most practical applications will probably use a set or a 
map anyway.

So the difference between this function and existing functionality is so 
small, that the cost of maintenance and remembering the name might not 
be worth it.


> * From a finite map, get a map from its range to its fibers:
>
>        fibers ∷ (Ord k, Ord v) ⇒ Map k v → Map v (NonEmpty k)

Why NonEmpty, and not Set? Or any Monoid? And more importantly, who are 
we to decide? Again, the cost difference between maintaining and 
re-discovering one "standard" vs. re-implementing something more 
precisely suited to the task at hand via (e.g.) Data.Map.foldMapWithKey 
doesn't seem worth it.

Additionally if I'm writing a program that would benefit from this 
function, performance considerations will almost always lead me to not 
use it. Instead, I will maintain both the map and its inverse from the 
start.


> * Put a type into the diagonal of its square:
>
>        diagonal = λx → (x, x)

Now this might fit into Data.Tuple. Then again, it's faster and more 
self-documenting to re-implement it at hoc than to remember a name.

Also, this (again) is less useful than it seems. It will almost always 
require an application of uncurry as well, which makes the program 
harder to understand. Sometimes it's better to replace both with a 
single application of the Monad instance of (->) – or with the "real" 
function.

For example:

uncurry (+) . diagonal ≡ join (+) ≡ \x -> x + x ≡ (2*)

Using diagonal is probably one of the worst ways to implement this and 
many of its brethren.


> It is unfeasible to put them into the standard libraries. _(Attempts were made.)_

This sounds like the maintainers of the standard libraries had their own 
objections. I suspect some of them might be similar to the ones above. 
Which leads me to suspect you might not have taken their feedback to 
heart. Which might in fact be the biggest hurdle on getting your code 
accepted into a library.


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

From kindaro at gmail.com  Sun Dec 20 16:56:15 2020
From: kindaro at gmail.com (Ignat Insarov)
Date: Sun, 20 Dec 2020 21:56:15 +0500
Subject: [Haskell-cafe] Where do trivial functions on the usual
	containers live?
In-Reply-To: <dcc865b4-61de-0d4d-3f8f-f257ac2cad82@gmail.com>
References: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>
 <dcc865b4-61de-0d4d-3f8f-f257ac2cad82@gmail.com>
Message-ID: <CAB-2Q0-gU+6iSpfnNN9E53yCCcDOYpXZeXkTPvimXEL4KBMRXQ@mail.gmail.com>

I immediately surrender any claims to having given perfect types to the
functions I would like to have. All I want is to have things that work somewhere
at hand, and not at all to have perfect things nowhere.

Nevertheless, I am going to reply to your objections.

> > * Group a collection by an equivalence relation:
> >
> > classify ∷ Ord π ⇒ (a → π) → [a] → [[a]]
>
> If the provided function is indeed an "equivalence relation", shouldn't the
> type be Eq π ⇒ (a → π) → [a] → [[a]], which is basically Data.List.groupBy? On
> the other hand if the resulting list is supposed to be ordered, most practical
> applications will probably use a set or a map anyway.

`Data.List.groupBy` detects only adjacent equivalent elements. The intention
here is to detect distant equivalent elements as well. You may see a more
detailed explanation and examples here:
<https://stackoverflow.com/questions/8262179>. See also previous discussion
here: <https://mail.haskell.org/pipermail/libraries/2020-August/030736.html>.

You may also see from these sources that it is not trivial to define this
function without the `Ord` constraint. In more detail: there are two versions,
one of which requires only `Eq` and runs in _n × m_ time, and the other requires
`Ord` and runs in _n × log n_ time. Neither is clearly better.

The most precise and informative type for the result seems to be `[NonEmpty
α]`. I do not see how `Set` or `Map` would be more suitable.

> > * From a finite map, get a map from its range to its fibers:
> >
> > fibers ∷ (Ord k, Ord v) ⇒ Map k v → Map v (NonEmpty k)
>
> Why NonEmpty, and not Set? Or any Monoid? And more importantly, who are we to
> decide? Again, the cost difference between maintaining and re-discovering one
> "standard" vs. re-implementing something more precisely suited to the task at
> hand via (e.g.) Data.Map.foldMapWithKey doesn't seem worth it.

Because a fiber is non-empty. Ideally, sure, I would like `(k, Set k)`.

The remainder of the quote would be very hard to substantiate. I evaluate the
cost and the benefit differently, that is all.

> > * Put a type into the diagonal of its square:
> >
> > diagonal = λx → (x, x)
>
> Now this might fit into Data.Tuple. Then again, it's faster and more
> self-documenting to re-implement it at hoc than to remember a name.
>
> Also, this (again) is less useful than it seems. It will almost always require
> an application of uncurry as well, which makes the program harder to
> understand. Sometimes it's better to replace both with a single application of
> the Monad instance of (->) – or with the "real" function.
>
> For example:
>
> uncurry (+) . diagonal ≡ join (+) ≡ \x -> x + x ≡ (2*)

I added this for a joke. It has been discussed previously at hilarious
length. See:

<https://mail.haskell.org/pipermail/libraries/2018-October/029051.html>
<https://mail.haskell.org/pipermail/libraries/2019-July/029744.html>
<https://mail.haskell.org/pipermail/libraries/2020-September/030789.html>

Surprizingly, many high profile Haskell programmers agree that it is useful.

> > It is unfeasible to put them into the standard libraries. _(Attempts were
> > made.)_
>
> This sounds like the maintainers of the standard libraries had their own
> objections. I suspect some of them might be similar to the ones above. Which
> leads me to suspect you might not have taken their feedback to heart. Which
> might in fact be the biggest hurdle on getting your code accepted into a
> library.

Turns out your objections mostly come down to evaluation of usefulness, which
would be very hard to substantiate by evidence, especially since usefulness is
potential as much as it is actual.

From ben.franksen at online.de  Sun Dec 20 16:59:47 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Sun, 20 Dec 2020 17:59:47 +0100
Subject: [Haskell-cafe] Do something about Cabal?
In-Reply-To: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
References: <CAB-2Q0-C1UEmHdJ6MSoORCy3=sdUC3MTJ9xkxB65GxCLFeuz2g@mail.gmail.com>
Message-ID: <rrnvu3$16g8$1@ciao.gmane.io>

Am 10.12.20 um 12:23 schrieb Ignat Insarov:
> Cabal is the second most used tool in Haskell after GHC. It has many
> problems. It may be noticed that there is one and a half developers working on
> it. This is clearly not enough to address these problems. I propose that this is
> a good place to invest in.

Cabal has *dramatically* improved over the years and since version 3.2
is working very smoothly for me. I generally favour cabal over stack
because I like the extra flexibility in chosing package versions that
cabal offers. Stack is also a very fine tool and has a slightly more
polished UI.

>   It is ordinary to receive output like this:
> 
>   ```
>   % cabal run example-executable
>   Warning: The package list for 'hackage.haskell.org' is 84 days old.
>   Run 'cabal update' to get the latest list of available packages.
>   Resolving dependencies...
>   cabal: Could not resolve dependencies:
>   [__0] trying: example-0.1.0.6 (user goal)
>   [__1] next goal: opaleye (dependency of example)
>   [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
>   config TODO requires ==0.6.7006.1)
>   [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
>   [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
>   opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
>   opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
>   opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
>   opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
>   opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
>   opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
>   opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
>   previous version to fail: excluded by constraint '^>=0.7' from example)
>   [__1] fail (backjumping, conflict set: example, opaleye)
>   After searching the rest of the dependency tree exhaustively, these were the
>   goals I've had most trouble fulfilling: opaleye, example
>   ```
> 
>   There are so many things that are wrong here.

The output is a bit verbose but the punch line at the end is pretty plain:

>   goals I've had most trouble fulfilling: opaleye, example

It doesn't take a PHD to conclude that you'll have to experiment with
(usually: relax) the version bounds for these two packages to find a
valid build plan. And the detailed output, however intimidating at
first, is acually helpful to find out what goes wrong.

I don't know how much effort goes into stackage (curating packages into
coherent sets) but my guess is: quite a bit. Without that extra effort
stack wouldn't be as useful as it is.

Cheers
Ben


From kindaro at gmail.com  Sun Dec 20 17:44:06 2020
From: kindaro at gmail.com (Ignat Insarov)
Date: Sun, 20 Dec 2020 22:44:06 +0500
Subject: [Haskell-cafe] Where do trivial functions on the usual
	containers live?
In-Reply-To: <alpine.DEB.2.20.2012201339420.6856@sputnik>
References: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>
 <alpine.DEB.2.20.2012201339420.6856@sputnik>
Message-ID: <CAB-2Q08-8KAkh3+6V1ZDAA5h49AktgNDwiAzfadv-bDuWYEesg@mail.gmail.com>

> I have my own utility library for such functions. However, it does not and
> shall not depend on 'containers'.

Why not, if I may ask?

From lemming at henning-thielemann.de  Sun Dec 20 17:53:48 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 20 Dec 2020 18:53:48 +0100 (CET)
Subject: [Haskell-cafe] Where do trivial functions on the usual
 containers live?
In-Reply-To: <CAB-2Q0-gU+6iSpfnNN9E53yCCcDOYpXZeXkTPvimXEL4KBMRXQ@mail.gmail.com>
References: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>
 <dcc865b4-61de-0d4d-3f8f-f257ac2cad82@gmail.com>
 <CAB-2Q0-gU+6iSpfnNN9E53yCCcDOYpXZeXkTPvimXEL4KBMRXQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2012201852170.6856@sputnik>


On Sun, 20 Dec 2020, Ignat Insarov wrote:

>> > * From a finite map, get a map from its range to its fibers:
>> >
>> > fibers ∷ (Ord k, Ord v) ⇒ Map k v → Map v (NonEmpty k)
>>
>> Why NonEmpty, and not Set? Or any Monoid? And more importantly, who are we to
>> decide? Again, the cost difference between maintaining and re-discovering one
>> "standard" vs. re-implementing something more precisely suited to the task at
>> hand via (e.g.) Data.Map.foldMapWithKey doesn't seem worth it.
>
> Because a fiber is non-empty. Ideally, sure, I would like `(k, Set k)`.

NonEmptyMap (and NonEmptySet?) were already discussed here.

I also have:
    https://hackage.haskell.org/package/non-empty-0.3.2/docs/Data-NonEmpty-Set.html

From lemming at henning-thielemann.de  Sun Dec 20 17:54:55 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 20 Dec 2020 18:54:55 +0100 (CET)
Subject: [Haskell-cafe] Where do trivial functions on the usual
 containers live?
In-Reply-To: <CAB-2Q08-8KAkh3+6V1ZDAA5h49AktgNDwiAzfadv-bDuWYEesg@mail.gmail.com>
References: <CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com>
 <alpine.DEB.2.20.2012201339420.6856@sputnik>
 <CAB-2Q08-8KAkh3+6V1ZDAA5h49AktgNDwiAzfadv-bDuWYEesg@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2012201854060.6856@sputnik>


On Sun, 20 Dec 2020, Ignat Insarov wrote:

>> I have my own utility library for such functions. However, it does not and
>> shall not depend on 'containers'.
>
> Why not, if I may ask?

Because I wanted to depend only on 'base' and be very stable. However, 
there is certainly room for a containers-utility library.

From a.pelenitsyn at gmail.com  Sun Dec 20 19:05:02 2020
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Sun, 20 Dec 2020 14:05:02 -0500
Subject: [Haskell-cafe] Intermediate Modern Haskell
In-Reply-To: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
References: <8a9cc7f9-26b1-d26e-d7c7-a64985d08cfb@mcmaster.ca>
Message-ID: <CAPKAvQVHdUQF99fbbtgwjGsD6qUSyNYmCnqx9cr7k_ZstKdpmg@mail.gmail.com>

Dear Jacques,

You may be interested in browsing through the table of contents (and maybe
the actual contents) of the Haskell in Depth book by Vitaly Bragilevsky
https://www.manning.com/books/haskell-in-depth
It will soon be out from Manning (currently finishing the preview phase
called MEAP). It has a good selection of "advanced" topics (including ones
you mentioned) supported by a set of interesting projects.

--
Kind regards,
Artem

On Wed, Dec 16, 2020, 10:22 PM Jacques Carette <carette at mcmaster.ca> wrote:

> I will be teaching a second Haskell course next semester.  Let's assume
> that
>
> Introducing functional programming
>
> Getting started with Haskell and GHCi
>
> Basic types and definitions
>
> Designing and writing programs
>
> Data types, tuples and lists
>
> Programming with lists
>
> Defining functions over lists
>
> Playing the game: I/O in Haskell
>
> Reasoning about programs
>
> Generalization: patterns of computation
>
> Higher-order functions
>
> Developing higher-order programs
>
> Overloading, type classes and type checking
>
> Algebraic types
>
>
> (i.e. the first chapters of Thompson's Haskell: the Craft of Functional
> Programming book is "beginner, classic Haskell".  The next few chapters,
> namely
>
> Abstract data types
>
> Lazy programming
>
> Programming with monads
>
> Domain-Specific Languages
>
> Time and space behaviour
>
>
> would be (re)done at the start of such a second course. The question for
> cafe is: what else? I will likely cover:
> - Typeclassopedia
> - finally tagless
> - Template Haskell
> - Optics
> - GADTs
> - recursion schemes
>
>
> I should probably cover parser combinators, pretty-printing, cabal&stack.
> I know that http://dev.stephendiehl.com/hask/ gives me one heck of a
> smorgasbord of options, which is kind of a problem.
>
>
> Things I know I will not cover:
> - dependent types (if I was going to do that, I'd switch to Idris/Agda)
> - concurrency (don't ask)
>
>
> Jacques
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201220/4dcb20a8/attachment.html>

From olf at aatal-apotheke.de  Mon Dec 21 10:19:44 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Mon, 21 Dec 2020 11:19:44 +0100
Subject: [Haskell-cafe] Where do trivial functions on the usual containers
 live?
Message-ID: <10f8ed72d5dfd132e491265d5500b243397d2bfb.camel@aatal-apotheke.de>

> I am looking for a place where I can find or put some simple
> functions that I
> expect but do not find in the `containers` or elsewhere in the
> standard
> libraries. 
Many hackage contributors seem to maintain their own 
<maintainer>-utils
package containing bits and bobs they personally deem useful but can
not find elsewhere. I might add my own one soon. Not saying this is a
good thing, though. 

> Some examples I have in mind:
> 
> * Group a collection by an equivalence relation:
> 
>       classify ∷ Ord π ⇒ (a → π) → [a] → [[a]]

GHC.Exts.groupWith or Data.List.groupBy might do want you want,
depending on whether you want to aggregate globally or only consecutive
runs of equivalent elements. 

> 
> * From a finite map, get a map from its range to its fibers:
> 
>       fibers ∷ (Ord k, Ord v) ⇒ Map k v → Map v (NonEmpty k)

The usual Semigroup instance of Map k v destroys data upon key
collision. For problems like this I have a newtype wrapper 

newtype SemiMap f v = SemiMap {getSemiMap :: f v}
instance (Semigroup v, Ord k) => Semigroup (SemiMap (Map k) v)

so that one can implement 'fibers' using foldMapWithKey. Is this worth
its own package? 

> 
> * Put a type into the diagonal of its square:
> 
>       diagonal = λx → (x, x)

This may be too trivial to be a library function, and its proper type
should rather be 
x -> Pair x
since we know both components have the same type. Pair is a Monad and
this function is its return. In package ghc Pair has an Applicativeinstance at least. 

Regards,
Olaf


From jack at jackkelly.name  Mon Dec 21 10:50:12 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Mon, 21 Dec 2020 10:50:12 GMT
Subject: [Haskell-cafe] Where do trivial functions on the usual
 containers live?
In-Reply-To: <10f8ed72d5dfd132e491265d5500b243397d2bfb.camel@aatal-apotheke.de>
References: <10f8ed72d5dfd132e491265d5500b243397d2bfb.camel@aatal-apotheke.de>
Message-ID: <d8aa5a5f85d1b05b7221f4a7cda93094@jackkelly.name>

December 21, 2020 8:19 PM, "Olaf Klinke" <olf at aatal-apotheke.de> wrote:

> The usual Semigroup instance of Map k v destroys data upon key
> collision. For problems like this I have a newtype wrapper
> 
> newtype SemiMap f v = SemiMap {getSemiMap :: f v}
> instance (Semigroup v, Ord k) => Semigroup (SemiMap (Map k) v)

You might like the monoidal-containers package, which newtypes the unordered-containers and containers types to have instances like `instance (Semigroup v, Ord k) => Semigroup (MonoidalMap k v)`.

-- Jack

From alexander.vershilov at gmail.com  Mon Dec 21 13:42:58 2020
From: alexander.vershilov at gmail.com (Alexander V Vershilov)
Date: Mon, 21 Dec 2020 16:42:58 +0300
Subject: [Haskell-cafe] (Co-)Maintainer-needed: imagemagick, binary-conduit
Message-ID: <CAO-1Pb42JpmLO2GUs8OmWaARG5C1EO=M4_Ev6Dh+i-Hhu-4UFQ@mail.gmail.com>

Hello,

I'm searching for the (co-)maintainers for packages that I don't use
at my daily work. If anyone use those, please volunteer:

  https://hackage.haskell.org/package/imagemagick
  https://hackage.haskell.org/package/binary-conduit
  https://hackage.haskell.org/package/network-transport-zeromq

--
Alexander Vershilov

From ben.franksen at online.de  Mon Dec 21 18:25:49 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 21 Dec 2020 19:25:49 +0100
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <CAMgWh9uSJ5mD8RiWSPVYVVGbNPNs+-PCaWyQpbbD-qCduGvy1w@mail.gmail.com>
 <X9GvOeKhR9PdZZrC@straasha.imrryr.org>
 <CABT0e9q-BXXhZd_-woVfgMz02gYKRr4dKkyq0Di8i1K23+_rCw@mail.gmail.com>
 <2562d911-ca23-54ae-7b86-34271df37062@vex.net>
Message-ID: <rrqpbd$g1o$2@ciao.gmane.io>

-1 for almost the same reasons as given below.

Am 10.12.20 um 20:46 schrieb Albert Y. C. Lai:
> -1 from me.  I vote for the status quo.
> 
> 0. I believe that it really comes down to a vote (as opposed to settling
> by technical merit).  My work habit (which stems from my personality) is
> going to be the opposite of many people's, and vice versa.  Every
> "technical merit" cited on this issue is conditional on accepting a
> certain personality.  So yes it has to come down to a vote.  I'm OK if I
> happen to be in the minority.
> 
> 1. -Wall warnings have almost zero correletion with my mistakes.  (See?
> my personality dictates what mistakes I make. YMMV.)
> 
> An example is unused binds.  My unused binds are intentional, thank you
> very much.  I make unused binds because it's future-proof---perhaps I
> will actually use it in the next version?  Editing from
> 
> (p, _q) = f x
> 
> to
> 
> (p, q) = f x
> 
> produces noise in diffs and commits, no?  Some of you are against noisy
> diffs and commits, no?  Then embrace unused binds!
> 
> 2. In fact, I go so far as adding -fdefer-type-errors during the first
> 99% of a development cycle.  Why?  Because ghci is so much more
> informative when :load succeeds.  Tab completion works.  :type works.
> Asking for where a local variable is defined works.  Asking for the type
> of an arbitrary subexpression works.  (I use those features via emacs
> haskell-mode or dante, of course.)  Would be a pity to throw that all
> away just for unfinished code.  Hell, to finish the unfinished code, I
> need those ghci features.  90% of the people who think they need a
> Haskell IDE, they just need this, -fdefer-type-errors and a low-tech
> editor plugin that actually knows what ghci offers.
> 
> -fdefer-type-errors still gives me compile-time warnings for what should
> be static errors.  I am not losing any information.  Clearly, I don't
> consider my job done until all-clear.  Just let me do my job.
> 
> 
> On 2020-12-10 2:50 a.m., Georgi Lyubenov wrote:
>> For me, the default is -Wall and the "production" version is also
>> turning on -Werror.
>>
>> I'm +1 on this.
>>
>> =======
>> Georgi
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



From lemming at henning-thielemann.de  Mon Dec 21 23:03:58 2020
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 22 Dec 2020 00:03:58 +0100 (CET)
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2012212351380.6618@sputnik>


On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:

> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3

He's pretty right about pattern matching and -Wall and 
-Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the 
two latter ones are not part of -Wall. But this is not your proposal.

I have always -Wall on, especially during early development. I can ignore 
warnings. But I will always remove the cause for warnings before making a 
commit. Warnings remind me on the unfinished bits. Thus also warnings 
about unused imports, unused parameters, unused functions are very 
important for me.

I would even like to see some warnings before or along type errors. 
Currently warnings are shown only after the type errors are resolved. 
However, sometimes I get very complicated type errors but actually the 
warning "variable x unused" (and thus type inference could not take place) 
would be much more helpful.

I have also taught programming to students. They often like to first run 
and test their programs and then resolve warnings somewhen in the future 
(or not at all). They are surprised why their programs don't work, whereas 
the warnings would directly point them to the problems. But -Wall is 
disabled by default. And thus making code warning free looks like an 
optional extra.

On the other hand I do not know how GHC with -Wall as default affects the 
tons of packages that are already released.

From david.feuer at gmail.com  Mon Dec 21 23:28:12 2020
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 21 Dec 2020 18:28:12 -0500
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <alpine.DEB.2.20.2012212351380.6618@sputnik>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <alpine.DEB.2.20.2012212351380.6618@sputnik>
Message-ID: <CAMgWh9s4NXVGNMh1w2Tcpu9VUdRLWhun5ZpYP32vG+O8BQKJRw@mail.gmail.com>

I think the git pull request cycle provides a great deadline for warnings.
Well-run projects typically expect code to be -Wall clean before being
merged. That sort of discipline is good for personal projects
too—everything should be clean before merging a feature branch to the main
one.

On Mon, Dec 21, 2020, 6:04 PM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:
>
> > [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
>
> He's pretty right about pattern matching and -Wall and
> -Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
> two latter ones are not part of -Wall. But this is not your proposal.
>
> I have always -Wall on, especially during early development. I can ignore
> warnings. But I will always remove the cause for warnings before making a
> commit. Warnings remind me on the unfinished bits. Thus also warnings
> about unused imports, unused parameters, unused functions are very
> important for me.
>
> I would even like to see some warnings before or along type errors.
> Currently warnings are shown only after the type errors are resolved.
> However, sometimes I get very complicated type errors but actually the
> warning "variable x unused" (and thus type inference could not take place)
> would be much more helpful.
>
> I have also taught programming to students. They often like to first run
> and test their programs and then resolve warnings somewhen in the future
> (or not at all). They are surprised why their programs don't work, whereas
> the warnings would directly point them to the problems. But -Wall is
> disabled by default. And thus making code warning free looks like an
> optional extra.
>
> On the other hand I do not know how GHC with -Wall as default affects the
> tons of packages that are already released.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201221/500e6a5b/attachment.html>

From ben.franksen at online.de  Mon Dec 21 23:36:39 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Tue, 22 Dec 2020 00:36:39 +0100
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <alpine.DEB.2.20.2012212351380.6618@sputnik>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <alpine.DEB.2.20.2012212351380.6618@sputnik>
Message-ID: <rrrbi7$13nc$1@ciao.gmane.io>

Am 22.12.20 um 00:03 schrieb Henning Thielemann:
> On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:
> 
>> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
> 
> He's pretty right about pattern matching and -Wall and
> -Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
> two latter ones are not part of -Wall. But this is not your proposal.

Yes, this should definitely be fixed.

> I have always -Wall on, especially during early development. I can
> ignore warnings. But I will always remove the cause for warnings before
> making a commit. Warnings remind me on the unfinished bits. Thus also
> warnings about unused imports, unused parameters, unused functions are
> very important for me.

A very good point, I have run into that problem a lot lately.

Still, this is also not the OP's proposal.

Cheers
Ben


From oleg.grenrus at iki.fi  Tue Dec 22 11:18:02 2020
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Tue, 22 Dec 2020 13:18:02 +0200
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <rrrbi7$13nc$1@ciao.gmane.io>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <alpine.DEB.2.20.2012212351380.6618@sputnik> <rrrbi7$13nc$1@ciao.gmane.io>
Message-ID: <756b998a-6ce1-e6cd-5a76-d20b3da31caf@iki.fi>

> Yes, this should definitely be fixed.

It is

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4614

Though not -Wpartial-fields (definition site), but
-Wincomplete-record-updates (use site).

- Oleg

On 22.12.2020 1.36, Ben Franksen wrote:
> Am 22.12.20 um 00:03 schrieb Henning Thielemann:
>> On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:
>>
>>> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
>> He's pretty right about pattern matching and -Wall and
>> -Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
>> two latter ones are not part of -Wall. But this is not your proposal.
> Yes, this should definitely be fixed.
>
>> I have always -Wall on, especially during early development. I can
>> ignore warnings. But I will always remove the cause for warnings before
>> making a commit. Warnings remind me on the unfinished bits. Thus also
>> warnings about unused imports, unused parameters, unused functions are
>> very important for me.
> A very good point, I have run into that problem a lot lately.
>
> Still, this is also not the OP's proposal.
>
> Cheers
> Ben
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From johannes.waldmann at htwk-leipzig.de  Tue Dec 22 15:52:11 2020
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 22 Dec 2020 16:52:11 +0100
Subject: [Haskell-cafe] type class Boolean
Message-ID: <8ef218f8-620d-3447-0db7-2783589675b1@htwk-leipzig.de>

> most useful kind of instance would be symbolic booleans

Yes. Ersatz has this:

https://hackage.haskell.org/package/ersatz-0.4.8/docs/Ersatz-Bit.html#t:Boolean

I also use this class (re-exported) in
https://hackage.haskell.org/package/obdd

Then modules typically start with

import Prelude hiding ( not, and, or, (&&), (||) ) -- possibly more
import Ersatz

slightly annoying but you get used to it ...

- J.

From ben.franksen at online.de  Tue Dec 22 19:19:57 2020
From: ben.franksen at online.de (Ben Franksen)
Date: Tue, 22 Dec 2020 20:19:57 +0100
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <756b998a-6ce1-e6cd-5a76-d20b3da31caf@iki.fi>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <alpine.DEB.2.20.2012212351380.6618@sputnik> <rrrbi7$13nc$1@ciao.gmane.io>
 <756b998a-6ce1-e6cd-5a76-d20b3da31caf@iki.fi>
Message-ID: <rrtgst$s4m$1@ciao.gmane.io>

Am 22.12.20 um 12:18 schrieb Oleg Grenrus:
> On 22.12.2020 1.36, Ben Franksen wrote:
>> Am 22.12.20 um 00:03 schrieb Henning Thielemann:
>>> On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:
>>>
>>>> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
>>> He's pretty right about pattern matching and -Wall and
>>> -Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
>>> two latter ones are not part of -Wall. But this is not your proposal.
>> Yes, this should definitely be fixed.
> 
> It is
> 
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4614

Nice!

> Though not -Wpartial-fields (definition site), but
> -Wincomplete-record-updates (use site).

Is there a specific reason or is it just that it wasn't included in the
proposal?

Cheers
Ben


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Tue Dec 22 19:31:36 2020
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 22 Dec 2020 19:31:36 +0000
Subject: [Haskell-cafe] Enable -Wall by default?
In-Reply-To: <rrtgst$s4m$1@ciao.gmane.io>
References: <CAATCwUm_ztoxS4e0AWj3MTLX7RZiH6u9JSmoxiHtXCMviVb97Q@mail.gmail.com>
 <alpine.DEB.2.20.2012212351380.6618@sputnik>
 <rrrbi7$13nc$1@ciao.gmane.io>
 <756b998a-6ce1-e6cd-5a76-d20b3da31caf@iki.fi>
 <rrtgst$s4m$1@ciao.gmane.io>
Message-ID: <20201222193136.GG28742@cloudinit-builder>

On Tue, Dec 22, 2020 at 08:19:57PM +0100, Ben Franksen wrote:
> Am 22.12.20 um 12:18 schrieb Oleg Grenrus:
> > On 22.12.2020 1.36, Ben Franksen wrote:
> >> Am 22.12.20 um 00:03 schrieb Henning Thielemann:
> >>> On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:
> >>>
> >>>> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
> >>> He's pretty right about pattern matching and -Wall and
> >>> -Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
> >>> two latter ones are not part of -Wall. But this is not your proposal.
> >> Yes, this should definitely be fixed.
> > 
> > It is
> > 
> > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4614
> 
> Nice!
> 
> > Though not -Wpartial-fields (definition site), but
> > -Wincomplete-record-updates (use site).
> 
> Is there a specific reason or is it just that it wasn't included in the
> proposal?

I don't think it even existed when I made the proposal!  It seems
to have appeared in 8.4 in March 2018.

https://hackage.haskell.org/package/base/changelog

https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history

https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/using-warnings.html

https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/using-warnings.html

Tom

From guthrie at miu.edu  Tue Dec 22 20:28:21 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Tue, 22 Dec 2020 20:28:21 +0000
Subject: [Haskell-cafe] cabal build fails: sidebyside
Message-ID: <DM6PR03MB4331791FFD32202057FB1FE7A1DF0@DM6PR03MB4331.namprd03.prod.outlook.com>

I have a fairly simple Haskell program which I build with cabal, which ends up seemingly successful with an executable (apl.exe).
(but what a path(!):
  . \dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe

Running that gives an error:
Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration
is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more
detailAt line:1 char:1
+ ./apl
+ ~~~~~.
At line:1 char:1
+ ./apl
+ ~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

Looking in the Windows event viewer, it reports:
     Activation context generation failed for "...\apl.exe". Error in manifest or policy file "...apl.exe" on line 2. Invalid Xml syntax.

Sxstrace did not seem to give any additional information:
Begin Activation Context Generation.
Input Parameter:
                Flags = 0
                ProcessorArchitecture = AMD64
                CultureFallBacks = en-US;en
                ManifestPath = D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\apl.exe
                AssemblyDirectory = D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\
                Application Config File =
-----------------
INFO: Parsing Manifest File D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\apl.exe.
                INFO: Manifest Definition Identity is (null).
                ERROR: Line 2: XML Syntax error.
ERROR: Activation Context generation failed.
End Activation Context Generation.

Online some posts suggest installing a current VC_redist - I did that, no relief.

Any suggestions on what is causing this, and a fix?

Running GCH: 8.10.1
Cabal: 3.2.0.0
Windows 10

Dr. Gregory Guthrie

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

From alan.zimm at gmail.com  Wed Dec 23 11:31:26 2020
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 23 Dec 2020 11:31:26 +0000
Subject: [Haskell-cafe] Haskell-language-server is looking for a logo
Message-ID: <CANma=H8Z7c4T5vivyyZE8QwFP4mjtiQAvgfVJjEBSDiTixu1Ow@mail.gmail.com>

Hi all,

The haskell language server is coming up for its first birthday in
January.  To celebrate we would like to collectively choose a logo.

So if you have a creative streak and would like to donate a lasting
contribution to the project, please submit for consideration at [1].

We will aim to close the judging on 25 Jan 2021, being the anniversary of
the Bristol Hackathon[2] where HLS was born.

Alan

[1] https://github.com/haskell/haskell-language-server/issues/694
[2] https://mpickering.github.io/bristol2020.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201223/eeb069eb/attachment.html>

From rebecca at rebeccaskinner.net  Wed Dec 23 16:00:28 2020
From: rebecca at rebeccaskinner.net (Rebecca Skinner)
Date: Wed, 23 Dec 2020 10:00:28 -0600
Subject: [Haskell-cafe] Supporting The Haskell Foundation
Message-ID: <CAGb4h=25ufpqr-Pex1FXDD0q7rJ-McGQfgWQGSQMWc7H8qqZmA@mail.gmail.com>

This has been an eventful year for many of us, and haskell.org is no

different. This year we've continued to support a significant part of

the Haskell community infrastructure- including haskell.org, Hackage,

Hoogle, and GHC build infrastructure. We're able to do this thanks to

the support of the Haskell community.

In addition to our ongoing work maintaining Haskell community

infrastructure, we once again participated in the Google Summer of

Code this year, supporting 12 projects. You can read more about the

projects here:

https://summer.haskell.org/news/2020-10-12-final-results.html

As many of you are likely aware, this year also saw some of our

community successfully launch a new initiative, the Haskell

Foundation. We are thrilled for the Haskell Foundation and

congratulate them on their successful launch.

Haskell.org is an independent organization, and while we welcome any

opportunities to collaborate with the Haskell Foundation, we will

continue to pursue our mission of managing and supporting Haskell

community infrastructure. If you would like to support Haskell.org in

our mission, you can donate via several method, including PayPay and

check:

https://www.haskell.org/donations/

Haskell.org can also accept donations through employers via Benevity

using the unique ID 475236502.

Haskell.org is a 501(c)(3) non-profit, so donations may be

tax-deductible in your jurisdiction.

Another way to help haskell.org is to serve on the committee. We have

three positions opening in 2021, and our call for nominations is open

through Jan 7th 2021. Please email the committee at

committee at haskell.org if you would like to nominate yourself or

someone else for a position.

We look forward to continuing this work with your support in 2021 as

well as exploring new projects to improve the Haskell community

infrastructure.

Best wishes, Rebecca Skinner on behalf of the haskell.org committee.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201223/5a0b9f80/attachment.html>

From rebecca at rebeccaskinner.net  Wed Dec 23 16:05:03 2020
From: rebecca at rebeccaskinner.net (Rebecca Skinner)
Date: Wed, 23 Dec 2020 10:05:03 -0600
Subject: [Haskell-cafe] Supporting The Haskell Foundation
In-Reply-To: <CAGb4h=25ufpqr-Pex1FXDD0q7rJ-McGQfgWQGSQMWc7H8qqZmA@mail.gmail.com>
References: <CAGb4h=25ufpqr-Pex1FXDD0q7rJ-McGQfgWQGSQMWc7H8qqZmA@mail.gmail.com>
Message-ID: <CAGb4h=1sOic4kXijh6vbSvgh9sU3nEebF67jcoLJ-mHgJeaLbg@mail.gmail.com>

Hey everyone, apologies for the subject of the email here. I inadvertently
said "Haskell Foundation" instead of Haskell.org.

The Haskell Foundation and Haskell.org are separate entities, and while
several of us on the haskell.org committee have been working closely with
the foundation, we do remain an independent entity serving the haskell
community. I merely got some wires crossed when drafting the title for the
email.

Thanks,
~Rebecca Skinner on behalf of the haskell.org committee

On Wed, Dec 23, 2020 at 10:00 AM Rebecca Skinner <rebecca at rebeccaskinner.net>
wrote:

> This has been an eventful year for many of us, and haskell.org is no
>
> different. This year we've continued to support a significant part of
>
> the Haskell community infrastructure- including haskell.org, Hackage,
>
> Hoogle, and GHC build infrastructure. We're able to do this thanks to
>
> the support of the Haskell community.
>
> In addition to our ongoing work maintaining Haskell community
>
> infrastructure, we once again participated in the Google Summer of
>
> Code this year, supporting 12 projects. You can read more about the
>
> projects here:
>
> https://summer.haskell.org/news/2020-10-12-final-results.html
>
> As many of you are likely aware, this year also saw some of our
>
> community successfully launch a new initiative, the Haskell
>
> Foundation. We are thrilled for the Haskell Foundation and
>
> congratulate them on their successful launch.
>
> Haskell.org is an independent organization, and while we welcome any
>
> opportunities to collaborate with the Haskell Foundation, we will
>
> continue to pursue our mission of managing and supporting Haskell
>
> community infrastructure. If you would like to support Haskell.org in
>
> our mission, you can donate via several method, including PayPay and
>
> check:
>
> https://www.haskell.org/donations/
>
> Haskell.org can also accept donations through employers via Benevity
>
> using the unique ID 475236502.
>
> Haskell.org is a 501(c)(3) non-profit, so donations may be
>
> tax-deductible in your jurisdiction.
>
> Another way to help haskell.org is to serve on the committee. We have
>
> three positions opening in 2021, and our call for nominations is open
>
> through Jan 7th 2021. Please email the committee at
>
> committee at haskell.org if you would like to nominate yourself or
>
> someone else for a position.
>
> We look forward to continuing this work with your support in 2021 as
>
> well as exploring new projects to improve the Haskell community
>
> infrastructure.
>
> Best wishes, Rebecca Skinner on behalf of the haskell.org committee.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201223/5e990021/attachment.html>

From rebecca at rebeccaskinner.net  Wed Dec 23 16:22:08 2020
From: rebecca at rebeccaskinner.net (Rebecca Skinner)
Date: Wed, 23 Dec 2020 10:22:08 -0600
Subject: [Haskell-cafe] Supporting Haskell.org
Message-ID: <CAGb4h=0NQtf4F1rWY7DYtjW6OadSfex17gG6k=22W5i1QiAx7w@mail.gmail.com>

Hi everyone. Apologies for the second email here. I originally sent this
message with an incorrect subject, and I wanted to re-post here with a
correct subject for visibility.

This has been an eventful year for many of us, and haskell.org is no

different. This year we've continued to support a significant part of

the Haskell community infrastructure- including haskell.org, Hackage,

Hoogle, and GHC build infrastructure. We're able to do this thanks to

the support of the Haskell community.

In addition to our ongoing work maintaining Haskell community

infrastructure, we once again participated in the Google Summer of

Code this year, supporting 12 projects. You can read more about the

projects here:

https://summer.haskell.org/news/2020-10-12-final-results.html

As many of you are likely aware, this year also saw some of our

community successfully launch a new initiative, the Haskell

Foundation. We are thrilled for the Haskell Foundation and

congratulate them on their successful launch.

Haskell.org is an independent organization, and while we welcome any

opportunities to collaborate with the Haskell Foundation, we will

continue to pursue our mission of managing and supporting Haskell

community infrastructure. If you would like to support Haskell.org in

our mission, you can donate via several method, including PayPay and

check:

https://www.haskell.org/donations/

Haskell.org can also accept donations through employers via Benevity

using the unique ID 475236502.

Haskell.org is a 501(c)(3) non-profit, so donations may be

tax-deductible in your jurisdiction.

Another way to help haskell.org is to serve on the committee. We have

three positions opening in 2021, and our call for nominations is open

through Jan 7th 2021. Please email the committee at

committee at haskell.org if you would like to nominate yourself or

someone else for a position.

We look forward to continuing this work with your support in 2021 as

well as exploring new projects to improve the Haskell community

infrastructure.

Best wishes, Rebecca Skinner on behalf of the haskell.org committee.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201223/927237c9/attachment.html>

From albert+haskell at zeitkraut.de  Wed Dec 23 18:24:05 2020
From: albert+haskell at zeitkraut.de (Albert Krewinkel)
Date: Wed, 23 Dec 2020 19:24:05 +0100
Subject: [Haskell-cafe] Haskell-language-server is looking for a logo
In-Reply-To: <CANma=H8Z7c4T5vivyyZE8QwFP4mjtiQAvgfVJjEBSDiTixu1Ow@mail.gmail.com>
References: <CANma=H8Z7c4T5vivyyZE8QwFP4mjtiQAvgfVJjEBSDiTixu1Ow@mail.gmail.com>
Message-ID: <87v9cspeii.fsf@zeitkraut.de>

Alan & Kim Zimmerman writes:

> The haskell language server is coming up for its first birthday in
> January.  To celebrate we would like to collectively choose a logo.
>
> So if you have a creative streak and would like to donate a lasting
> contribution to the project, please submit for consideration at [1].

You could also post this as a "job" on the Open Source Design board, a
community dedicated to help open source projects with their designs.
https://opensourcedesign.net/

Cheers,
Albert

--
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124

From carter.schonwald at gmail.com  Wed Dec 23 18:57:30 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 23 Dec 2020 13:57:30 -0500
Subject: [Haskell-cafe] Haskell-language-server is looking for a logo
In-Reply-To: <87v9cspeii.fsf@zeitkraut.de>
References: <CANma=H8Z7c4T5vivyyZE8QwFP4mjtiQAvgfVJjEBSDiTixu1Ow@mail.gmail.com>
 <87v9cspeii.fsf@zeitkraut.de>
Message-ID: <CAHYVw0xyc+eCyNxcsYp1y0ON=wp7BdbmkGCBaRkxePArMVwpuw@mail.gmail.com>

“Cause Haskell language server gives you wings! “ — joke brief for logo
design? :)

On Wed, Dec 23, 2020 at 1:25 PM Albert Krewinkel <
albert+haskell at zeitkraut.de> wrote:

> Alan & Kim Zimmerman writes:
>
> > The haskell language server is coming up for its first birthday in
> > January.  To celebrate we would like to collectively choose a logo.
> >
> > So if you have a creative streak and would like to donate a lasting
> > contribution to the project, please submit for consideration at [1].
>
> You could also post this as a "job" on the Open Source Design board, a
> community dedicated to help open source projects with their designs.
> https://opensourcedesign.net/
>
> Cheers,
> Albert
>
> --
> Albert Krewinkel
> GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201223/4f6fdd78/attachment.html>

From monkleyon at gmail.com  Wed Dec 23 20:57:01 2020
From: monkleyon at gmail.com (MarLinn)
Date: Wed, 23 Dec 2020 21:57:01 +0100
Subject: [Haskell-cafe] Haskell-language-server is looking for a logo
In-Reply-To: <CAHYVw0xyc+eCyNxcsYp1y0ON=wp7BdbmkGCBaRkxePArMVwpuw@mail.gmail.com>
References: <CANma=H8Z7c4T5vivyyZE8QwFP4mjtiQAvgfVJjEBSDiTixu1Ow@mail.gmail.com>
 <87v9cspeii.fsf@zeitkraut.de>
 <CAHYVw0xyc+eCyNxcsYp1y0ON=wp7BdbmkGCBaRkxePArMVwpuw@mail.gmail.com>
Message-ID: <83c3b452-2c7a-1fd6-cd24-0eeccf30c7b6@gmail.com>

Something with "wings", you say.

Something that represents the "magic" of HLS, you say.

Something that shows an obvious relation to the Haskell roots, you say.

Say no more.

Definitely not based on exactly 7 minutes of research and obviously made 
with all the skills and seriousness I could muster, I give you:

abominable cross of a lambda symbol and a witch on a broom stick

Sorry, had to get that out of my system. Maybe it gets some creative 
juices flowing or something, who knows…

Cheers and happy holidays!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201223/9ef3a854/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hsl logo.png
Type: image/png
Size: 10491 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201223/9ef3a854/attachment.png>

From carter.schonwald at gmail.com  Thu Dec 24 00:15:47 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 23 Dec 2020 19:15:47 -0500
Subject: [Haskell-cafe] Haskell-language-server is looking for a logo
In-Reply-To: <83c3b452-2c7a-1fd6-cd24-0eeccf30c7b6@gmail.com>
References: <CANma=H8Z7c4T5vivyyZE8QwFP4mjtiQAvgfVJjEBSDiTixu1Ow@mail.gmail.com>
 <87v9cspeii.fsf@zeitkraut.de>
 <CAHYVw0xyc+eCyNxcsYp1y0ON=wp7BdbmkGCBaRkxePArMVwpuw@mail.gmail.com>
 <83c3b452-2c7a-1fd6-cd24-0eeccf30c7b6@gmail.com>
Message-ID: <CAHYVw0zmJzVSj4QQ31FciFEhBtnpPnUuE_P=3pNkcpoBDdi6kg@mail.gmail.com>

awesome :) love it

On Wed, Dec 23, 2020 at 3:58 PM MarLinn <monkleyon at gmail.com> wrote:

> Something with "wings", you say.
>
> Something that represents the "magic" of HLS, you say.
>
> Something that shows an obvious relation to the Haskell roots, you say.
>
> Say no more.
>
> Definitely not based on exactly 7 minutes of research and obviously made
> with all the skills and seriousness I could muster, I give you:
>
> [image: abominable cross of a lambda symbol and a witch on a broom stick]
>
> Sorry, had to get that out of my system. Maybe it gets some creative
> juices flowing or something, who knows…
>
> Cheers and happy holidays!
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201223/a894fffe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hsl logo.png
Type: image/png
Size: 10491 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201223/a894fffe/attachment-0001.png>

From ida.bzowska at gmail.com  Thu Dec 24 12:16:19 2020
From: ida.bzowska at gmail.com (Ida Bzowska)
Date: Thu, 24 Dec 2020 13:16:19 +0100
Subject: [Haskell-cafe] Haskell-language-server is looking for a logo
In-Reply-To: <CAHYVw0zmJzVSj4QQ31FciFEhBtnpPnUuE_P=3pNkcpoBDdi6kg@mail.gmail.com>
References: <CANma=H8Z7c4T5vivyyZE8QwFP4mjtiQAvgfVJjEBSDiTixu1Ow@mail.gmail.com>
 <87v9cspeii.fsf@zeitkraut.de>
 <CAHYVw0xyc+eCyNxcsYp1y0ON=wp7BdbmkGCBaRkxePArMVwpuw@mail.gmail.com>
 <83c3b452-2c7a-1fd6-cd24-0eeccf30c7b6@gmail.com>
 <CAHYVw0zmJzVSj4QQ31FciFEhBtnpPnUuE_P=3pNkcpoBDdi6kg@mail.gmail.com>
Message-ID: <CAOOeZjBFgWL+m6o7J=ip=pj8eEx68tM2Q0bhqUbwQ8qFc_yWmA@mail.gmail.com>

Hey,
Maybe something about Bristol (to commemorate the Hackathon)? - I know that
Bristol is famous for hot air balloons; so why not make the logo simple:
*branded* hot air balloon? (note: I'm not a designer :D ).
[image: logo.png]
λCheers
Ida Bzowska


czw., 24 gru 2020 o 01:15 Carter Schonwald <carter.schonwald at gmail.com>
napisał(a):

> awesome :) love it
>
> On Wed, Dec 23, 2020 at 3:58 PM MarLinn <monkleyon at gmail.com> wrote:
>
>> Something with "wings", you say.
>>
>> Something that represents the "magic" of HLS, you say.
>>
>> Something that shows an obvious relation to the Haskell roots, you say.
>>
>> Say no more.
>>
>> Definitely not based on exactly 7 minutes of research and obviously made
>> with all the skills and seriousness I could muster, I give you:
>>
>> [image: abominable cross of a lambda symbol and a witch on a broom stick]
>>
>> Sorry, had to get that out of my system. Maybe it gets some creative
>> juices flowing or something, who knows…
>>
>> Cheers and happy holidays!
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20201224/9d916709/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hsl logo.png
Type: image/png
Size: 10491 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201224/9d916709/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 17228 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201224/9d916709/attachment-0001.png>

From jack at jackkelly.name  Fri Dec 25 13:05:48 2020
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Fri, 25 Dec 2020 13:05:48 GMT
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>
References: <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>
 <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
 <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
 <805909cb81151c4722e6f7997c3dec17@jackkelly.name>
Message-ID: <c7c6e063dcfc3bd206b671dd5dc07e0e@jackkelly.name>

December 13, 2020 1:49 PM, "Emily Pillmore" <emilypi at cohomolo.gy> wrote:

>> My problem with maps is that if I want to stay with Group and the obvious elementwise inversion, I
>> don't have a good answer for distinguishing `mempty` values at a particular key, vs the key not
>> being present at all.
> 
> This brings up a good point about sparsity. It's probably a good idea from a resource perspective
> to consider inserting mempty as he identity on the structure, and it raises an interesting point
> about how often you should simplify by delete mempty elements if you don't conflate it. Either way,
> I think you'll be forced to pick up an additional `Eq` constraint on the values, which may not be
> ideal.

You can use `MonoidNull`. from monoid-subclasses to avoid an `Eq` constraint.

However, auto-pruning `mempty` values from a map seems wonky. You'd have to newtype everything a la monoidal-containers, and consider equivalence classes under `mempty`-pruning:

```
-- Don't export constructor, force callers to use 'fromPruning' so there's no observable differences
newtype Pruning t a = Pruning (t a) deriving (Semigroup, TheUsualSuspects)

pruneMempty :: (Filterable t, MonoidNull a) => t a -> t a
pruneMempty = catMaybes $ \a -> if null a then Nothing else Just a

fromPruning :: (Filterable t, MonoidNull a) => Pruning t a -> t a
fromPruning (Pruning ta) = pruneMempty ta

instance (Filterable t, MonoidNull a) => Eq (Pruning t a) where
  x == y = pruneMempty x == pruneMempty y
```

I suspect (but haven't confirmed) that you'd then have `instance (Group g, MonoidNull g, Ord k) => Group (Pruning (MonoidalMap k) g)`.

>> The reason I believe this is that you can't make up "additional" inverses by adding mappings from
>> some `k => mempty`. The type system stops you from choosing any particular `k`, and even if you
>> could, you fail the requirement that `x <> inverse x <> x = x`
> 
> Do you mind expanding on this? i don't quite get what you're saying here.

Sure. AIUI, for a regular semigroup, you requite each `x` to have at least one pseudoinverse `inv x` s.t.:

1. `x <> inv x <> x = x`
2. `inv x <> x <> inv x = inv x`

For an inverse semigroup, you require each pseudoinverse to be unique.
I'm then thinking about whether you can have instance `(Ord k, InverseSemigroup g) => InverseSemigroup (Map k g)` or whether `(Ord k, InverseSemigroup g) => RegularSemigroup (Map k g)` is as far as you can go.

I'm mostly thinking about whether it's possible to cook up additional pseudoinverses when trying to lift to maps. Suppose you have a map `fromList [(k, v)]`. The obvious inverse is `fromList [(k, inv v)]`. My concern was whether you could cook up arbitrary additional inverses by saying `fromList [(k, inv v), (k', mempty)]` for some `k'` not present in the map. You cannot: while it passes condition (2), it fails condition (1). Also, if your `k` type variable is unconstrained, you can't even choose other key values because you know nothing about the key type.

Next question: We can get to inverse semigroups for maps, is it worth having a class for regular semigroups at all? I haven't seen any compelling regular semigroups, but maybe there are some? Also, the typeclass method you have to provide is pretty bad, because even if an element has many pseudoinverses, they're possibly not even enumerable. So you're probably still asking for a method `inv :: g -> g` 

Other question - which I still haven't had time to think about properly - is whether there should be an InverseSemigroup class between Semigroup and Group, or whether I can do the sort of stuff I want to tidy the `patch` library and its use in `reflex` using the cancellative operations in monoid-subclasses. If I can't, I think there's maybe a case for `InverseSemigroup` in `group-theory` (might be worth adding, regardless). My instinct is to proliferate data types rather than classes, and maybe that means having a `Pruning` type in monoidal-subclasses is better than adding a new class?

Hope that's clearer.

-- Jack


> On Fri, Dec 11, 2020 at 8:25 AM, <jack at jackkelly.name> wrote:
> 
>> December 10, 2020 5:05 AM, "Emily Pillmore" <emilypi at cohomolo.gy> wrote:
>> 
>>> Correct me if I'm wrong here, because I've never seen anyone describe maps like this, but it seems
>>> to me that for an algebraic constraint `c`, `c g ⇒ Map k g` would be a `k`-graded c-structure, and
>>> we can think of algebraic operations applied to those `g` meaningfully in that sense. For example,
>>> an indexed-list where `Group a ⇒ [(Int, a)]` can be seen as a ℤ-graded group.
>>> 
>>> In your example, Jack, inversion is defined on a map by `fmap inverse ≣ inverse_k0 + inverse_k1 + …
>>> + inverse k_n`, componentwise for each key. So perhaps your problem here for maps, is equivalent to
>>> finding a nice indexed-group for structure for the types:
>>> 
>>> ```
>>> — | A functor indexed by a discrete category. Not to be confused with
>>> -- indexed as in higher functor on functor ala Atkey's Outrageous Fortune.
>>> — This is not the most general encoding.
>>> —
>>> 
>>> class GradedFunctor f where
>>> imap :: (i → a → b) → f i a → f i b
>>> — Being a graded group requires that the "overall" structure be both an indexed functor,
>>> — as well as a group, so that `t i g = g_i0 + … + giN` forms a group as well.
>> I don't have the algebra knowledge to follow what you just wrote, but this class smells like
>> FunctorWithIndex from `lens`, but I don't know how principled that class is.
>> 
>> My problem with maps is that if I want to stay with Group and the obvious elementwise inversion, I
>> don't have a good answer for distinguishing `mempty` values at a particular key, vs the key not
>> being present at all.
>> 
>> However, I'm quite confident that elementwise inversion gives you an Inverse Semigroup because
>> inverses are unique. (I had previously mentioned that I thought you only had a Regular Semigroup,
>> but I think that was an error.) The reason I believe this is that you can't make up "additional"
>> inverses by adding mappings from some `k => mempty`. The type system stops you from choosing any
>> particular `k`, and even if you could, you fail the requirement that `x <> inverse x <> x = x`
>> 
>> -- Jack

From viercc at gmail.com  Sat Dec 26 08:15:28 2020
From: viercc at gmail.com (=?UTF-8?B?5a6u6YeM5rS45Y+4?=)
Date: Sat, 26 Dec 2020 17:15:28 +0900
Subject: [Haskell-cafe] [Ann] group-theory
In-Reply-To: <c7c6e063dcfc3bd206b671dd5dc07e0e@jackkelly.name>
References: <kihqw4al.f250e4a0-9b32-4fe6-930f-92702c00806f@we.are.superhuman.com>
 <6207544a-9840-03f8-624a-54b19f2939f0@rogers.com>
 <kic1wq8x.bb9c49cc-0fe4-4da6-b58f-b47c6c4ed949@we.are.superhuman.com>
 <387165f3b38988de076a34462a1b9e61@jackkelly.name>
 <28c31eb62a34479f226e64adebcac70d@jackkelly.name>
 <805909cb81151c4722e6f7997c3dec17@jackkelly.name>
 <kimd7gys.6ca0c6a3-a48e-4f2c-abd7-72b7fac41707@we.are.superhuman.com>
 <c7c6e063dcfc3bd206b671dd5dc07e0e@jackkelly.name>
Message-ID: <CAPLpts+w+Tm1r8q054U5NPukVkgjcHJa5v7piFzdwbJq7R5UdQ@mail.gmail.com>

> You can use `MonoidNull`. from monoid-subclasses to avoid an `Eq` constraint.

For groups, there is no difference between `MonoidNull` and `Eq`, as
you can define `x == y` be
`null (x <> inv y)`. There are monoids which `==` is not even
decidable but `null` is (e.g. context-free grammars
with equality defined by the language it defines), but such monoid
necessarily has no `Group` instance.



2020年12月25日(金) 22:08 Jack Kelly via Haskell-Cafe <haskell-cafe at haskell.org>:
>
> December 13, 2020 1:49 PM, "Emily Pillmore" <emilypi at cohomolo.gy> wrote:
>
> >> My problem with maps is that if I want to stay with Group and the obvious elementwise inversion, I
> >> don't have a good answer for distinguishing `mempty` values at a particular key, vs the key not
> >> being present at all.
> >
> > This brings up a good point about sparsity. It's probably a good idea from a resource perspective
> > to consider inserting mempty as he identity on the structure, and it raises an interesting point
> > about how often you should simplify by delete mempty elements if you don't conflate it. Either way,
> > I think you'll be forced to pick up an additional `Eq` constraint on the values, which may not be
> > ideal.
>
> You can use `MonoidNull`. from monoid-subclasses to avoid an `Eq` constraint.
>
> However, auto-pruning `mempty` values from a map seems wonky. You'd have to newtype everything a la monoidal-containers, and consider equivalence classes under `mempty`-pruning:
>
> ```
> -- Don't export constructor, force callers to use 'fromPruning' so there's no observable differences
> newtype Pruning t a = Pruning (t a) deriving (Semigroup, TheUsualSuspects)
>
> pruneMempty :: (Filterable t, MonoidNull a) => t a -> t a
> pruneMempty = catMaybes $ \a -> if null a then Nothing else Just a
>
> fromPruning :: (Filterable t, MonoidNull a) => Pruning t a -> t a
> fromPruning (Pruning ta) = pruneMempty ta
>
> instance (Filterable t, MonoidNull a) => Eq (Pruning t a) where
>   x == y = pruneMempty x == pruneMempty y
> ```
>
> I suspect (but haven't confirmed) that you'd then have `instance (Group g, MonoidNull g, Ord k) => Group (Pruning (MonoidalMap k) g)`.
>
> >> The reason I believe this is that you can't make up "additional" inverses by adding mappings from
> >> some `k => mempty`. The type system stops you from choosing any particular `k`, and even if you
> >> could, you fail the requirement that `x <> inverse x <> x = x`
> >
> > Do you mind expanding on this? i don't quite get what you're saying here.
>
> Sure. AIUI, for a regular semigroup, you requite each `x` to have at least one pseudoinverse `inv x` s.t.:
>
> 1. `x <> inv x <> x = x`
> 2. `inv x <> x <> inv x = inv x`
>
> For an inverse semigroup, you require each pseudoinverse to be unique.
> I'm then thinking about whether you can have instance `(Ord k, InverseSemigroup g) => InverseSemigroup (Map k g)` or whether `(Ord k, InverseSemigroup g) => RegularSemigroup (Map k g)` is as far as you can go.
>
> I'm mostly thinking about whether it's possible to cook up additional pseudoinverses when trying to lift to maps. Suppose you have a map `fromList [(k, v)]`. The obvious inverse is `fromList [(k, inv v)]`. My concern was whether you could cook up arbitrary additional inverses by saying `fromList [(k, inv v), (k', mempty)]` for some `k'` not present in the map. You cannot: while it passes condition (2), it fails condition (1). Also, if your `k` type variable is unconstrained, you can't even choose other key values because you know nothing about the key type.
>
> Next question: We can get to inverse semigroups for maps, is it worth having a class for regular semigroups at all? I haven't seen any compelling regular semigroups, but maybe there are some? Also, the typeclass method you have to provide is pretty bad, because even if an element has many pseudoinverses, they're possibly not even enumerable. So you're probably still asking for a method `inv :: g -> g`
>
> Other question - which I still haven't had time to think about properly - is whether there should be an InverseSemigroup class between Semigroup and Group, or whether I can do the sort of stuff I want to tidy the `patch` library and its use in `reflex` using the cancellative operations in monoid-subclasses. If I can't, I think there's maybe a case for `InverseSemigroup` in `group-theory` (might be worth adding, regardless). My instinct is to proliferate data types rather than classes, and maybe that means having a `Pruning` type in monoidal-subclasses is better than adding a new class?
>
> Hope that's clearer.
>
> -- Jack
>
>
> > On Fri, Dec 11, 2020 at 8:25 AM, <jack at jackkelly.name> wrote:
> >
> >> December 10, 2020 5:05 AM, "Emily Pillmore" <emilypi at cohomolo.gy> wrote:
> >>
> >>> Correct me if I'm wrong here, because I've never seen anyone describe maps like this, but it seems
> >>> to me that for an algebraic constraint `c`, `c g ⇒ Map k g` would be a `k`-graded c-structure, and
> >>> we can think of algebraic operations applied to those `g` meaningfully in that sense. For example,
> >>> an indexed-list where `Group a ⇒ [(Int, a)]` can be seen as a ℤ-graded group.
> >>>
> >>> In your example, Jack, inversion is defined on a map by `fmap inverse ≣ inverse_k0 + inverse_k1 + …
> >>> + inverse k_n`, componentwise for each key. So perhaps your problem here for maps, is equivalent to
> >>> finding a nice indexed-group for structure for the types:
> >>>
> >>> ```
> >>> — | A functor indexed by a discrete category. Not to be confused with
> >>> -- indexed as in higher functor on functor ala Atkey's Outrageous Fortune.
> >>> — This is not the most general encoding.
> >>> —
> >>>
> >>> class GradedFunctor f where
> >>> imap :: (i → a → b) → f i a → f i b
> >>> — Being a graded group requires that the "overall" structure be both an indexed functor,
> >>> — as well as a group, so that `t i g = g_i0 + … + giN` forms a group as well.
> >> I don't have the algebra knowledge to follow what you just wrote, but this class smells like
> >> FunctorWithIndex from `lens`, but I don't know how principled that class is.
> >>
> >> My problem with maps is that if I want to stay with Group and the obvious elementwise inversion, I
> >> don't have a good answer for distinguishing `mempty` values at a particular key, vs the key not
> >> being present at all.
> >>
> >> However, I'm quite confident that elementwise inversion gives you an Inverse Semigroup because
> >> inverses are unique. (I had previously mentioned that I thought you only had a Regular Semigroup,
> >> but I think that was an error.) The reason I believe this is that you can't make up "additional"
> >> inverses by adding mappings from some `k => mempty`. The type system stops you from choosing any
> >> particular `k`, and even if you could, you fail the requirement that `x <> inverse x <> x = x`
> >>
> >> -- Jack
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
/* Koji Miyazato <viercc at gmail.com> */

From olf at aatal-apotheke.de  Sat Dec 26 19:54:13 2020
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 26 Dec 2020 20:54:13 +0100
Subject: [Haskell-cafe] [Ann] group-theory
Message-ID: <a99d65d9e7926267120c5fc2b33dad8a54440957.camel@aatal-apotheke.de>

Koji Miyazato wrote:
> > You can use `MonoidNull`. from monoid-subclasses to avoid an `Eq`
> constraint.
> 
> For groups, there is no difference between `MonoidNull` and `Eq`, as
> you can define `x == y` be
> `null (x <> inv y)`. There are monoids which `==` is not even
> decidable but `null` is (e.g. context-free grammars
> with equality defined by the language it defines), but such monoid
> necessarily has no `Group` instance.

A beautiful example of topological groups: Their topology is completely
determined by the neighbourhoods of the identity element. If the
identity element is isolated, the entire group is discrete. 

Olaf


From minorinoki at gmail.com  Mon Dec 28 12:05:49 2020
From: minorinoki at gmail.com (ARATA Mizuki)
Date: Mon, 28 Dec 2020 21:05:49 +0900
Subject: [Haskell-cafe] [ANN] fp-ieee v0.1
Message-ID: <44F911D8-A142-412A-8A84-E78BB06A4812@gmail.com>

Hi all,

I'd like to announce the first release of fp-ieee.

https://hackage.haskell.org/package/fp-ieee

This library aims to provide IEEE 754-2019 compliant operations, including

* fusedMultiplyAdd

* correctly-rounding versions of fromInteger (GHC's fromInteger for Float and Double do not round correctly; see https://gitlab.haskell.org/ghc/ghc/-/issues/17231)

* realFloatToFrac: an alternative of realToFrac with well-defined semantics.

Other notes:

* Most of the functions are generic, and any RealFloat instance can be used. However, manipulation of NaN's sign and payload requires an additional constraint (RealFloatNaN, provided by this library).

* Access to floating-point environment is not provided. If you want to control rounding direction, look at my another library: https://hackage.haskell.org/package/rounded-hw

* Decimal-specific operations (like quantize, quantum) are not provided, and the preferred exponent is not honored.

* Use of FFI can be disabled via a package flag (maybe useful when using non-native targets).


Mizuki


From carter.schonwald at gmail.com  Mon Dec 28 15:14:20 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 28 Dec 2020 10:14:20 -0500
Subject: [Haskell-cafe] [ANN] fp-ieee v0.1
In-Reply-To: <44F911D8-A142-412A-8A84-E78BB06A4812@gmail.com>
References: <44F911D8-A142-412A-8A84-E78BB06A4812@gmail.com>
Message-ID: <CAHYVw0wNirKuKYn0c9LMDBJ8PJLee4P_TfnOaK-Qj=K+euwG5w@mail.gmail.com>

This is really cool!

Is the fall back strategy to do Kahn style compensated arithmetic.  Similar
to in Edward Kmett’s compensated library on hackage?

I like how you have both styles of NaN semantics for min and max, with the
default being NaN poisoning but also providing the NaN avoiding one some
software needs to do.

On Mon, Dec 28, 2020 at 7:06 AM ARATA Mizuki <minorinoki at gmail.com> wrote:

> Hi all,
>
> I'd like to announce the first release of fp-ieee.
>
> https://hackage.haskell.org/package/fp-ieee
>
> This library aims to provide IEEE 754-2019 compliant operations, including
>
> * fusedMultiplyAdd
>
> * correctly-rounding versions of fromInteger (GHC's fromInteger for Float
> and Double do not round correctly; see
> https://gitlab.haskell.org/ghc/ghc/-/issues/17231)
>
> * realFloatToFrac: an alternative of realToFrac with well-defined
> semantics.
>
> Other notes:
>
> * Most of the functions are generic, and any RealFloat instance can be
> used. However, manipulation of NaN's sign and payload requires an
> additional constraint (RealFloatNaN, provided by this library).
>
> * Access to floating-point environment is not provided. If you want to
> control rounding direction, look at my another library:
> https://hackage.haskell.org/package/rounded-hw
>
> * Decimal-specific operations (like quantize, quantum) are not provided,
> and the preferred exponent is not honored.
>
> * Use of FFI can be disabled via a package flag (maybe useful when using
> non-native targets).
>
>
> Mizuki
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20201228/95c26e86/attachment.html>

From guthrie at miu.edu  Mon Dec 28 18:44:35 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Mon, 28 Dec 2020 18:44:35 +0000
Subject: [Haskell-cafe] cabal errors
Message-ID: <DM6PR03MB4331CC07BFA9FFF0CB3A5534A1D90@DM6PR03MB4331.namprd03.prod.outlook.com>

I'm having some issues with Cabal ,  wonder if they are known issues.

1) I had a previously working installation of files, hadn't used them for some time, did Haskell upgrades (chocolatey), and tried to recompile.
I got a weird error on running the build - 
     Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration
     is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detailAt line:1 char:1
     + ./apl
     + ~~~~~.
     At line:1 char:1
     + ./apl
     + ~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed
Chasing this all around - no solutions so I started over, in a new location, adding one file at a time.
Worked fine.
2) So I then has a current working build in some top level xTest temporary directory.
      (Just a direct copy of all the files, and "cabal v2-build")
3) So I then just copied all the source files back to a desired installation place, with a longer path name.
4) But there it fails to build:
     PS D:\CS\Courses\long path\Solns\All Solutions> cabal v2-install
     Wrote tarball sdist to D:\CS\Courses\long path\Solns\All Solutions\dist-newstyle\sdist\apl-0.0.1.tar.gz
     Resolving dependencies...
     Build profile: -w ghc-8.10.1 -O1
     In order, the following will be built (use -v for more details):
      - apl-0.0.1 (exe:apl) (requires build)
     cabal.exe: Failed to unpack apl-0.0.1. The exception was:
     dieVerbatim: user error (cabal.exe: Package .cabal file not found in the tarball:
     C:\Users\guthrie\AppData\Local\Temp\cabal-install.-2584\dist-newstyle\tmp\src-2584\apl-0.0.1\apl.cabal)
5) Just copying (again) the same folder of files which is failing to a top level new folder (yTest), deleting the dist-newstyle folder,
     And running "cabal v2-buld" again, all works fine, no errors, executable built.

Three directories, all with the same files - one fails.
?? The only difference I can see is the long path name with blanks in it - is that an issue?

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


From guthrie at miu.edu  Mon Dec 28 20:41:42 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Mon, 28 Dec 2020 20:41:42 +0000
Subject: [Haskell-cafe] cabal errors
In-Reply-To: <DM6PR03MB4331CC07BFA9FFF0CB3A5534A1D90@DM6PR03MB4331.namprd03.prod.outlook.com>
References: <DM6PR03MB4331CC07BFA9FFF0CB3A5534A1D90@DM6PR03MB4331.namprd03.prod.outlook.com>
Message-ID: <DM6PR03MB4331BA39437CFD4B5A6CF419A1D90@DM6PR03MB4331.namprd03.prod.outlook.com>

Hmm, I just did a 4th test, copied the same directory of sources to a top level directory, but also with a blank in the name of the directory, works fine.

So I made a 5th variation, copied he whole thing (working) back to a sibling directory of the original failing one.

It did a build, then fails on execution - 
      Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration
     is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more
    detailAt line:1 char:1
     + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
     + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
     At line:1 char:1
     + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
     + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

Only difference I can see between working and failing ones is their location; they are on two different partitions(?).

So two directories, same location, both identical to a third at a top level, top works fine these two fail differently. ??

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

-----Original Message-----
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Gregory Guthrie
Sent: Monday, December 28, 2020 12:45 PM
To: haskell-cafe at haskell.org
Subject: [Haskell-cafe] cabal errors

I'm having some issues with Cabal ,  wonder if they are known issues.

1) I had a previously working installation of files, hadn't used them for some time, did Haskell upgrades (chocolatey), and tried to recompile.
I got a weird error on running the build - 
     Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration
     is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail At line:1 char:1
     + ./apl
     + ~~~~~.
     At line:1 char:1
     + ./apl
     + ~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed Chasing this all around - no solutions so I started over, in a new location, adding one file at a time.
Worked fine.
2) So I then has a current working build in some top level xTest temporary directory.
      (Just a direct copy of all the files, and "cabal v2-build")
3) So I then just copied all the source files back to a desired installation place, with a longer path name.
4) But there it fails to build:
     PS D:\CS\Courses\long path\Solns\All Solutions> cabal v2-install
     Wrote tarball sdist to D:\CS\Courses\long path\Solns\All Solutions\dist-newstyle\sdist\apl-0.0.1.tar.gz
     Resolving dependencies...
     Build profile: -w ghc-8.10.1 -O1
     In order, the following will be built (use -v for more details):
      - apl-0.0.1 (exe:apl) (requires build)
     cabal.exe: Failed to unpack apl-0.0.1. The exception was:
     dieVerbatim: user error (cabal.exe: Package .cabal file not found in the tarball:
     C:\Users\guthrie\AppData\Local\Temp\cabal-install.-2584\dist-newstyle\tmp\src-2584\apl-0.0.1\apl.cabal)
5) Just copying (again) the same folder of files which is failing to a top level new folder (yTest), deleting the dist-newstyle folder,
     And running "cabal v2-buld" again, all works fine, no errors, executable built.

Three directories, all with the same files - one fails.
?? The only difference I can see is the long path name with blanks in it - is that an issue?

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

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

From guthrie at miu.edu  Wed Dec 30 18:28:49 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Wed, 30 Dec 2020 18:28:49 +0000
Subject: [Haskell-cafe] ghc/cabal problems - mystery?
Message-ID: <DM6PR03MB433107B810F0FC364BD11C90A1D70@DM6PR03MB4331.namprd03.prod.outlook.com>

I reported several odd and inconsistent results that I can't understand, and after some further trials, a few more data points, but still confused. 

A directory of files, cabal build runs fine, then trying to execute; I get three different results;

     Linking D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe ...
Seems fine.

Then; from that same shell (PS) in the same directory -
>From cabal run: Fails
    PS D:\CS\Courses\long path\All Solutions> cabal run
    Up to date
    D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl: createProcess: invalid argument (Invalid argument)

>From using the explicit path: Fails
    PS D:\CS\Courses\long path\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe
    Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration
    is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more
    detailAt line:1 char:1
    + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
    At line:1 char:1
    + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

>From going to the dist folder: runs fine.
   PS D:\CS\Courses\long path\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl
   PS D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl> apl.exe
   "APL: Examples and labs"

I get a few other errors & results sometimes; copy the full directory to somewhere else, "cabal clean",
And it won't build, "no target specified", even though the entire folder is identical.

Again; every time just copying the entire directory, no editing of any files, just running cabal as above.
Any hints or ideas why I am getting these issues & errors?

GHC 8.10.2
Cabal 3.2.0.0
(Windows 10)
------------------------------------------------------------------------
PS: One more...
I (again) copied the entire directory to another place and retested, in that case "cabal run" did run, but gave results from a different file in the directory (multiple tests there, only one run from Main.hs, same .cabal file), and can run it by explicit path or "cabal run".

All results should be "DSem_imp", one is from a different file, "DSem_impc" ??
Certainly looks like they should all be running the same apl.exe. ??

Output""
PS G:\Testing\All Solutions> cabal clean
PS G:\Testing\All Solutions> cabal run
Resolving dependencies...
Build profile: -w ghc-8.10.2 -O1
In order, the following will be built (use -v for more details):
 - apl-0.0.1 (exe:apl) (first run)
Configuring apl-0.0.1...
Preprocessing executable 'apl' for apl-0.0.1..
Building executable 'apl' for apl-0.0.1..
...
Linking G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe ...
"APL: Examples and labs"
"======================"
"------ APL:: DSem_imp"

PS G:\Testing\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe
"APL: Examples and labs"
"======================"
"------ APL:: DSem_imp"

PS G:\Testing\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl
PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> ls
    Directory: G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        12/30/2020  12:18 PM                apl-tmp
d-----        12/30/2020  12:17 PM                autogen
-a----        12/30/2020  12:18 PM       11230184 apl.exe
PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> apl.exe
"APL: Examples and labs"
"======================"
"------ APL:: DSem_impc"



Gregory Guthrie
Maharishi International University
----------------------------------------------------------------


From marian.jancar at gmx.com  Wed Dec 30 19:01:48 2020
From: marian.jancar at gmx.com (Marian Jancar)
Date: Wed, 30 Dec 2020 19:01:48 +0000
Subject: [Haskell-cafe] ghc/cabal problems - mystery?
In-Reply-To: <DM6PR03MB433107B810F0FC364BD11C90A1D70@DM6PR03MB4331.namprd03.prod.outlook.com>
References: <DM6PR03MB433107B810F0FC364BD11C90A1D70@DM6PR03MB4331.namprd03.prod.outlook.com>
Message-ID: <808cd78d-cf27-7f8c-961e-6c28212a3b6d@gmx.com>

I think you are hitting on
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

On 12/30/20 6:28 PM, Gregory Guthrie wrote:
> I reported several odd and inconsistent results that I can't understand, and after some further trials, a few more data points, but still confused.
>
> A directory of files, cabal build runs fine, then trying to execute; I get three different results;
>
>       Linking D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe ...
> Seems fine.
>
> Then; from that same shell (PS) in the same directory -
>  From cabal run: Fails
>      PS D:\CS\Courses\long path\All Solutions> cabal run
>      Up to date
>      D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl: createProcess: invalid argument (Invalid argument)
>
>  From using the explicit path: Fails
>      PS D:\CS\Courses\long path\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe
>      Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration
>      is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more
>      detailAt line:1 char:1
>      + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
>      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
>      At line:1 char:1
>      + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
>      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
>      + FullyQualifiedErrorId : NativeCommandFailed
>
>  From going to the dist folder: runs fine.
>     PS D:\CS\Courses\long path\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl
>     PS D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl> apl.exe
>     "APL: Examples and labs"
>
> I get a few other errors & results sometimes; copy the full directory to somewhere else, "cabal clean",
> And it won't build, "no target specified", even though the entire folder is identical.
>
> Again; every time just copying the entire directory, no editing of any files, just running cabal as above.
> Any hints or ideas why I am getting these issues & errors?
>
> GHC 8.10.2
> Cabal 3.2.0.0
> (Windows 10)
> ------------------------------------------------------------------------
> PS: One more...
> I (again) copied the entire directory to another place and retested, in that case "cabal run" did run, but gave results from a different file in the directory (multiple tests there, only one run from Main.hs, same .cabal file), and can run it by explicit path or "cabal run".
>
> All results should be "DSem_imp", one is from a different file, "DSem_impc" ??
> Certainly looks like they should all be running the same apl.exe. ??
>
> Output""
> PS G:\Testing\All Solutions> cabal clean
> PS G:\Testing\All Solutions> cabal run
> Resolving dependencies...
> Build profile: -w ghc-8.10.2 -O1
> In order, the following will be built (use -v for more details):
>   - apl-0.0.1 (exe:apl) (first run)
> Configuring apl-0.0.1...
> Preprocessing executable 'apl' for apl-0.0.1..
> Building executable 'apl' for apl-0.0.1..
> ...
> Linking G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe ...
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_imp"
>
> PS G:\Testing\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_imp"
>
> PS G:\Testing\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl
> PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> ls
>      Directory: G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl
> Mode                 LastWriteTime         Length Name
> ----                 -------------         ------ ----
> d-----        12/30/2020  12:18 PM                apl-tmp
> d-----        12/30/2020  12:17 PM                autogen
> -a----        12/30/2020  12:18 PM       11230184 apl.exe
> PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> apl.exe
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_impc"
>
>
>
> Gregory Guthrie
> Maharishi International University
> ----------------------------------------------------------------
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>

From guthrie at miu.edu  Wed Dec 30 20:13:26 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Wed, 30 Dec 2020 20:13:26 +0000
Subject: [Haskell-cafe] ghc/cabal problems - mystery?
In-Reply-To: <808cd78d-cf27-7f8c-961e-6c28212a3b6d@gmx.com>
References: <DM6PR03MB433107B810F0FC364BD11C90A1D70@DM6PR03MB4331.namprd03.prod.outlook.com>
 <808cd78d-cf27-7f8c-961e-6c28212a3b6d@gmx.com>
Message-ID: <DM6PR03MB4331E28654D8332573D09650A1D70@DM6PR03MB4331.namprd03.prod.outlook.com>

Thanks - I'll investigate this.

Note, that Cabal adding an additional 7 levels of directory (and ~70 characters) to the path for executables can exacerbate this.


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

-----Original Message-----
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Marian Jancar
Sent: Wednesday, December 30, 2020 1:02 PM
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] ghc/cabal problems - mystery?

I think you are hitting on
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

On 12/30/20 6:28 PM, Gregory Guthrie wrote:
> I reported several odd and inconsistent results that I can't understand, and after some further trials, a few more data points, but still confused.
>
> A directory of files, cabal build runs fine, then trying to execute; I 
> get three different results;
>
>       Linking D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe ...
> Seems fine.
>
> Then; from that same shell (PS) in the same directory -  From cabal 
> run: Fails
>      PS D:\CS\Courses\long path\All Solutions> cabal run
>      Up to date
>      D:\CS\Courses\long path\All 
> Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\buil
> d\apl\apl: createProcess: invalid argument (Invalid argument)
>
>  From using the explicit path: Fails
>      PS D:\CS\Courses\long path\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe
>      Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration
>      is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more
>      detailAt line:1 char:1
>      + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
>      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
>      At line:1 char:1
>      + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
>      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
>      + FullyQualifiedErrorId : NativeCommandFailed
>
>  From going to the dist folder: runs fine.
>     PS D:\CS\Courses\long path\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl
>     PS D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl> apl.exe
>     "APL: Examples and labs"
>
> I get a few other errors & results sometimes; copy the full directory 
> to somewhere else, "cabal clean", And it won't build, "no target specified", even though the entire folder is identical.
>
> Again; every time just copying the entire directory, no editing of any files, just running cabal as above.
> Any hints or ideas why I am getting these issues & errors?
>
> GHC 8.10.2
> Cabal 3.2.0.0
> (Windows 10)
> ----------------------------------------------------------------------
> --
> PS: One more...
> I (again) copied the entire directory to another place and retested, in that case "cabal run" did run, but gave results from a different file in the directory (multiple tests there, only one run from Main.hs, same .cabal file), and can run it by explicit path or "cabal run".
>
> All results should be "DSem_imp", one is from a different file, "DSem_impc" ??
> Certainly looks like they should all be running the same apl.exe. ??
>
> Output""
> PS G:\Testing\All Solutions> cabal clean PS G:\Testing\All Solutions> 
> cabal run Resolving dependencies...
> Build profile: -w ghc-8.10.2 -O1
> In order, the following will be built (use -v for more details):
>   - apl-0.0.1 (exe:apl) (first run)
> Configuring apl-0.0.1...
> Preprocessing executable 'apl' for apl-0.0.1..
> Building executable 'apl' for apl-0.0.1..
> ...
> Linking G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe ...
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_imp"
>
> PS G:\Testing\All Solutions> 
> dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.
> exe
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_imp"
>
> PS G:\Testing\All Solutions> cd 
> dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl
> PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> ls
>      Directory: G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl
> Mode                 LastWriteTime         Length Name
> ----                 -------------         ------ ----
> d-----        12/30/2020  12:18 PM                apl-tmp
> d-----        12/30/2020  12:17 PM                autogen
> -a----        12/30/2020  12:18 PM       11230184 apl.exe
> PS G:\Testing\All 
> Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\buil
> d\apl> apl.exe
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_impc"
>
>
>
> Gregory Guthrie
> Maharishi International University
> ----------------------------------------------------------------
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view 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 guthrie at miu.edu  Wed Dec 30 23:10:32 2020
From: guthrie at miu.edu (Gregory Guthrie)
Date: Wed, 30 Dec 2020 23:10:32 +0000
Subject: [Haskell-cafe] ghc/cabal problems - mystery?
In-Reply-To: <808cd78d-cf27-7f8c-961e-6c28212a3b6d@gmx.com>
References: <DM6PR03MB433107B810F0FC364BD11C90A1D70@DM6PR03MB4331.namprd03.prod.outlook.com>
 <808cd78d-cf27-7f8c-961e-6c28212a3b6d@gmx.com>
Message-ID: <DM6PR03MB43312E8E1C6F8EA3C947F77DA1D70@DM6PR03MB4331.namprd03.prod.outlook.com>

Thanks - but the max path I actually use (down to the apl.exe executable) is 152 characters.

I ran the whole thing on another machine with similar setup, no  apparent problems...


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

-----Original Message-----
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Marian Jancar
Sent: Wednesday, December 30, 2020 1:02 PM
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] ghc/cabal problems - mystery?

I think you are hitting on
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

On 12/30/20 6:28 PM, Gregory Guthrie wrote:
> I reported several odd and inconsistent results that I can't understand, and after some further trials, a few more data points, but still confused.
>
> A directory of files, cabal build runs fine, then trying to execute; I 
> get three different results;
>
>       Linking D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe ...
> Seems fine.
>
> Then; from that same shell (PS) in the same directory -  From cabal 
> run: Fails
>      PS D:\CS\Courses\long path\All Solutions> cabal run
>      Up to date
>      D:\CS\Courses\long path\All 
> Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\buil
> d\apl\apl: createProcess: invalid argument (Invalid argument)
>
>  From using the explicit path: Fails
>      PS D:\CS\Courses\long path\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe
>      Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration
>      is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more
>      detailAt line:1 char:1
>      + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
>      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
>      At line:1 char:1
>      + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ...
>      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
>      + FullyQualifiedErrorId : NativeCommandFailed
>
>  From going to the dist folder: runs fine.
>     PS D:\CS\Courses\long path\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl
>     PS D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl> apl.exe
>     "APL: Examples and labs"
>
> I get a few other errors & results sometimes; copy the full directory 
> to somewhere else, "cabal clean", And it won't build, "no target specified", even though the entire folder is identical.
>
> Again; every time just copying the entire directory, no editing of any files, just running cabal as above.
> Any hints or ideas why I am getting these issues & errors?
>
> GHC 8.10.2
> Cabal 3.2.0.0
> (Windows 10)
> ----------------------------------------------------------------------
> --
> PS: One more...
> I (again) copied the entire directory to another place and retested, in that case "cabal run" did run, but gave results from a different file in the directory (multiple tests there, only one run from Main.hs, same .cabal file), and can run it by explicit path or "cabal run".
>
> All results should be "DSem_imp", one is from a different file, "DSem_impc" ??
> Certainly looks like they should all be running the same apl.exe. ??
>
> Output""
> PS G:\Testing\All Solutions> cabal clean PS G:\Testing\All Solutions> 
> cabal run Resolving dependencies...
> Build profile: -w ghc-8.10.2 -O1
> In order, the following will be built (use -v for more details):
>   - apl-0.0.1 (exe:apl) (first run)
> Configuring apl-0.0.1...
> Preprocessing executable 'apl' for apl-0.0.1..
> Building executable 'apl' for apl-0.0.1..
> ...
> Linking G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe ...
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_imp"
>
> PS G:\Testing\All Solutions> 
> dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.
> exe
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_imp"
>
> PS G:\Testing\All Solutions> cd 
> dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl
> PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> ls
>      Directory: G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl
> Mode                 LastWriteTime         Length Name
> ----                 -------------         ------ ----
> d-----        12/30/2020  12:18 PM                apl-tmp
> d-----        12/30/2020  12:17 PM                autogen
> -a----        12/30/2020  12:18 PM       11230184 apl.exe
> PS G:\Testing\All 
> Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\buil
> d\apl> apl.exe
> "APL: Examples and labs"
> "======================"
> "------ APL:: DSem_impc"
>
>
>
> Gregory Guthrie
> Maharishi International University
> ----------------------------------------------------------------
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view 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 minorinoki at gmail.com  Thu Dec 31 09:08:07 2020
From: minorinoki at gmail.com (ARATA Mizuki)
Date: Thu, 31 Dec 2020 18:08:07 +0900
Subject: [Haskell-cafe] [ANN] fp-ieee v0.1
In-Reply-To: <CAHYVw0wNirKuKYn0c9LMDBJ8PJLee4P_TfnOaK-Qj=K+euwG5w@mail.gmail.com>
References: <44F911D8-A142-412A-8A84-E78BB06A4812@gmail.com>
 <CAHYVw0wNirKuKYn0c9LMDBJ8PJLee4P_TfnOaK-Qj=K+euwG5w@mail.gmail.com>
Message-ID: <F69EDBEE-766D-4A3B-9D8B-FFC1C4C6E4B7@gmail.com>



> 2020/12/29 0:14、Carter Schonwald <carter.schonwald at gmail.com>のメール:
> 
> This is really cool! 

Thanks.

> 
> Is the fall back strategy to do Kahn style compensated arithmetic.  Similar to in Edward Kmett’s compensated library on hackage?

Yes.  My code combines it with "round-to-odd" technique.

> 
> I like how you have both styles of NaN semantics for min and max, with the default being NaN poisoning but also providing the NaN avoiding one some software needs to do. 

It's one of the new things in IEEE 754-"2019" :)

> 
> On Mon, Dec 28, 2020 at 7:06 AM ARATA Mizuki <minorinoki at gmail.com> wrote:
> Hi all,
> 
> I'd like to announce the first release of fp-ieee.
> 
> https://hackage.haskell.org/package/fp-ieee
> 
> This library aims to provide IEEE 754-2019 compliant operations, including
> 
> * fusedMultiplyAdd
> 
> * correctly-rounding versions of fromInteger (GHC's fromInteger for Float and Double do not round correctly; see https://gitlab.haskell.org/ghc/ghc/-/issues/17231)
> 
> * realFloatToFrac: an alternative of realToFrac with well-defined semantics.
> 
> Other notes:
> 
> * Most of the functions are generic, and any RealFloat instance can be used. However, manipulation of NaN's sign and payload requires an additional constraint (RealFloatNaN, provided by this library).
> 
> * Access to floating-point environment is not provided. If you want to control rounding direction, look at my another library: https://hackage.haskell.org/package/rounded-hw
> 
> * Decimal-specific operations (like quantize, quantum) are not provided, and the preferred exponent is not honored.
> 
> * Use of FFI can be disabled via a package flag (maybe useful when using non-native targets).
> 
> 
> Mizuki
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.