From olf at aatal-apotheke.de  Thu Mar  2 10:54:22 2023
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 02 Mar 2023 11:54:22 +0100
Subject: [Haskell-cafe] dynamic web form generation for algebraic data types
Message-ID: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>

Dear Cafe, 

has anyone ever attempted (and maybe succeeded) in building dynamic
forms using one of the Haskell web frameworks (Yesod,Servant,...)? 
By "dynamic" form I mean a form that changes the number of fields based
on selections the user makes in other fields of the form. 

For example, say one has an algebraic data type

    data T = Number Int | Check Bool T

A form for such a type would initially consist of radio buttons or a
drop-down list with options "Number" and "Check" that lets the user
select the constructor. When "Number" is selected, an <input
type="number"> field is shown. When "Check" is selected, an <input
type="checkbox"> is displayed next to another form of this kind. 

In the end, one would use the GHC.Generics machinery to generate forms
for a wide range of algebraic data types. I've seen this in the Clean
language's iTask library [1] and it's very convenient. 
Of course this would involve a lot of JavaScript like
document.createElement() as well as book-keeping how to re-asseble the
fields into a T value upon submission. At least the latter is already
handled by libraries such as yesod-form. 

Olaf

[1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic
[2] https://github.com/haskell-servant/servant-swagger/issues/80


From godzbanebane at gmail.com  Thu Mar  2 13:51:43 2023
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Thu, 2 Mar 2023 15:51:43 +0200
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
 types
In-Reply-To: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
References: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
Message-ID: <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>

Hey Olaf,

This is not an answer to your question, but I was reminded of Grace[0], 
which is a language
with a "browser"[1] that allows you to type in terms and get back 
webpages based on those terms
"automagically", which sounds like exactly what you need. I don't know 
how it's implemented, so I don't know if
it is actually relevant to you, but it is worth noting that Grace itself 
is implemented in Haskell.

Cheers,
Georgi

[0] https://github.com/Gabriella439/grace
[1] https://trygrace.dev/

On 3/2/23 12:54, Olaf Klinke wrote:
> Dear Cafe,
>
> has anyone ever attempted (and maybe succeeded) in building dynamic
> forms using one of the Haskell web frameworks (Yesod,Servant,...)?
> By "dynamic" form I mean a form that changes the number of fields based
> on selections the user makes in other fields of the form.
>
> For example, say one has an algebraic data type
>
>      data T = Number Int | Check Bool T
>
> A form for such a type would initially consist of radio buttons or a
> drop-down list with options "Number" and "Check" that lets the user
> select the constructor. When "Number" is selected, an <input
> type="number"> field is shown. When "Check" is selected, an <input
> type="checkbox"> is displayed next to another form of this kind.
>
> In the end, one would use the GHC.Generics machinery to generate forms
> for a wide range of algebraic data types. I've seen this in the Clean
> language's iTask library [1] and it's very convenient.
> Of course this would involve a lot of JavaScript like
> document.createElement() as well as book-keeping how to re-asseble the
> fields into a T value upon submission. At least the latter is already
> handled by libraries such as yesod-form.
>
> Olaf
>
> [1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic
> [2] https://github.com/haskell-servant/servant-swagger/issues/80
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 olf at aatal-apotheke.de  Thu Mar  2 15:01:37 2023
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 02 Mar 2023 16:01:37 +0100
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
 types
In-Reply-To: <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>
References: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
 <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>
Message-ID: <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>

On Thu, 2023-03-02 at 15:51 +0200, Georgi Lyubenov wrote:
> Hey Olaf,
> 
> This is not an answer to your question, but I was reminded of Grace[0], 
> which is a language
> with a "browser"[1] that allows you to type in terms and get back 
> webpages based on those terms
> "automagically", which sounds like exactly what you need. I don't know 
> how it's implemented, so I don't know if
> it is actually relevant to you, but it is worth noting that Grace itself 
> is implemented in Haskell.
> 
> Cheers,
> Georgi
> 
> [0] https://github.com/Gabriella439/grace
> [1] https://trygrace.dev/
> 
> On 3/2/23 12:54, Olaf Klinke wrote:
> > Dear Cafe,
> > 
> > has anyone ever attempted (and maybe succeeded) in building dynamic
> > forms using one of the Haskell web frameworks (Yesod,Servant,...)?
> > By "dynamic" form I mean a form that changes the number of fields based
> > on selections the user makes in other fields of the form.
> > 
> > For example, say one has an algebraic data type
> > 
> >      data T = Number Int | Check Bool T
> > 
> > A form for such a type would initially consist of radio buttons or a
> > drop-down list with options "Number" and "Check" that lets the user
> > select the constructor. When "Number" is selected, an <input
> > type="number"> field is shown. When "Check" is selected, an <input
> > type="checkbox"> is displayed next to another form of this kind.
> > 
> > In the end, one would use the GHC.Generics machinery to generate forms
> > for a wide range of algebraic data types. I've seen this in the Clean
> > language's iTask library [1] and it's very convenient.
> > Of course this would involve a lot of JavaScript like
> > document.createElement() as well as book-keeping how to re-asseble the
> > fields into a T value upon submission. At least the latter is already
> > handled by libraries such as yesod-form.
> > 
> > Olaf
> > 
> > [1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic
> > [2] https://github.com/haskell-servant/servant-swagger/issues/80
> > 
> > 

Thanks for the pointer! 

The Grace README says under Notable Omissions:

>Recursion or recursive data types
>
>Grace only supports two built-in recursive types, which are List and
>JSON, but does not support user-defined recursion or anonymous
>recursion.
>
>User-defined datatypes
>
>All data types in Grace are anonymous (e.g. anonymous records and
>anonymous unions), and there is no concept of a data declaration

The tutorial shows how Grace function inputs are mapped to forms, where
functions with List input indeed have a form that is "dynamic" in the
sense I defined. Otherwise there is only one input field per function
argument. That means complex types are to be input in JSON syntax and
parsed. 
Instead of a DSL, I'd prefer a shallow embedding into Haskell, so that
one can leverage all the available machinery.  
Yet Grace already goes a long way towards what I am after. 

Olaf



 



From ivanperezdominguez at gmail.com  Thu Mar  2 15:34:56 2023
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Thu, 2 Mar 2023 07:34:56 -0800
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
	types
In-Reply-To: <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>
References: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
 <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>
 <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>
Message-ID: <CACZKWEK8A8sfoZwqB2hUvYQrNCnOrDzY3YGEZcjbyUMBTFi4OQ@mail.gmail.com>

All of this reminds me of Conal Elliott's Tangible Values.

http://conal.net/papers/Eros/

(Not for web but the idea still applies.)

Ivan

On Thu, 2 Mar 2023 at 07:02, Olaf Klinke <olf at aatal-apotheke.de> wrote:

> On Thu, 2023-03-02 at 15:51 +0200, Georgi Lyubenov wrote:
> > Hey Olaf,
> >
> > This is not an answer to your question, but I was reminded of Grace[0],
> > which is a language
> > with a "browser"[1] that allows you to type in terms and get back
> > webpages based on those terms
> > "automagically", which sounds like exactly what you need. I don't know
> > how it's implemented, so I don't know if
> > it is actually relevant to you, but it is worth noting that Grace itself
> > is implemented in Haskell.
> >
> > Cheers,
> > Georgi
> >
> > [0] https://github.com/Gabriella439/grace
> > [1] https://trygrace.dev/
> >
> > On 3/2/23 12:54, Olaf Klinke wrote:
> > > Dear Cafe,
> > >
> > > has anyone ever attempted (and maybe succeeded) in building dynamic
> > > forms using one of the Haskell web frameworks (Yesod,Servant,...)?
> > > By "dynamic" form I mean a form that changes the number of fields based
> > > on selections the user makes in other fields of the form.
> > >
> > > For example, say one has an algebraic data type
> > >
> > >      data T = Number Int | Check Bool T
> > >
> > > A form for such a type would initially consist of radio buttons or a
> > > drop-down list with options "Number" and "Check" that lets the user
> > > select the constructor. When "Number" is selected, an <input
> > > type="number"> field is shown. When "Check" is selected, an <input
> > > type="checkbox"> is displayed next to another form of this kind.
> > >
> > > In the end, one would use the GHC.Generics machinery to generate forms
> > > for a wide range of algebraic data types. I've seen this in the Clean
> > > language's iTask library [1] and it's very convenient.
> > > Of course this would involve a lot of JavaScript like
> > > document.createElement() as well as book-keeping how to re-asseble the
> > > fields into a T value upon submission. At least the latter is already
> > > handled by libraries such as yesod-form.
> > >
> > > Olaf
> > >
> > > [1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic
> > > [2] https://github.com/haskell-servant/servant-swagger/issues/80
> > >
> > >
>
> Thanks for the pointer!
>
> The Grace README says under Notable Omissions:
>
> >Recursion or recursive data types
> >
> >Grace only supports two built-in recursive types, which are List and
> >JSON, but does not support user-defined recursion or anonymous
> >recursion.
> >
> >User-defined datatypes
> >
> >All data types in Grace are anonymous (e.g. anonymous records and
> >anonymous unions), and there is no concept of a data declaration
>
> The tutorial shows how Grace function inputs are mapped to forms, where
> functions with List input indeed have a form that is "dynamic" in the
> sense I defined. Otherwise there is only one input field per function
> argument. That means complex types are to be input in JSON syntax and
> parsed.
> Instead of a DSL, I'd prefer a shallow embedding into Haskell, so that
> one can leverage all the available machinery.
> Yet Grace already goes a long way towards what I am after.
>
> Olaf
>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230302/c9c6a709/attachment.html>

From olf at aatal-apotheke.de  Thu Mar  2 16:40:18 2023
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 02 Mar 2023 17:40:18 +0100
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
 types
In-Reply-To: <CACZKWEK8A8sfoZwqB2hUvYQrNCnOrDzY3YGEZcjbyUMBTFi4OQ@mail.gmail.com>
References: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
 <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>
 <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>
 <CACZKWEK8A8sfoZwqB2hUvYQrNCnOrDzY3YGEZcjbyUMBTFi4OQ@mail.gmail.com>
Message-ID: <28b32b14d74df3d5f8dd9fee3141f22e5623322a.camel@aatal-apotheke.de>

On Thu, 2023-03-02 at 07:34 -0800, Ivan Perez wrote:
> All of this reminds me of Conal Elliott's Tangible Values.
> 
> http://conal.net/papers/Eros/
> 
> (Not for web but the idea still applies.)
> 
> Ivan

Yes, the concept has been re-invented multiple times, as is the case
with most good ideas. TVs are general enough to bolt a web interface on
top, I guess. 

Seems that Conal, too, has not solved the sum type problem. 
The tangible value GADT 
https://hackage.haskell.org/package/TV-0.5.0/docs/Interface-TV-Input.html
has a Pair constructor but not for Sum. I wonder whether there is a
deeper categorical reason for this. 

So I should re-phrase my question: 
Has anyone extended tangible values to Generic types and given them a
modern html interface? 

Olaf

> 
> On Thu, 2 Mar 2023 at 07:02, Olaf Klinke <olf at aatal-apotheke.de> wrote:
> 
> > On Thu, 2023-03-02 at 15:51 +0200, Georgi Lyubenov wrote:
> > > Hey Olaf,
> > > 
> > > This is not an answer to your question, but I was reminded of Grace[0],
> > > which is a language
> > > with a "browser"[1] that allows you to type in terms and get back
> > > webpages based on those terms
> > > "automagically", which sounds like exactly what you need. I don't know
> > > how it's implemented, so I don't know if
> > > it is actually relevant to you, but it is worth noting that Grace itself
> > > is implemented in Haskell.
> > > 
> > > Cheers,
> > > Georgi
> > > 
> > > [0] https://github.com/Gabriella439/grace
> > > [1] https://trygrace.dev/
> > > 
> > > On 3/2/23 12:54, Olaf Klinke wrote:
> > > > Dear Cafe,
> > > > 
> > > > has anyone ever attempted (and maybe succeeded) in building dynamic
> > > > forms using one of the Haskell web frameworks (Yesod,Servant,...)?
> > > > By "dynamic" form I mean a form that changes the number of fields based
> > > > on selections the user makes in other fields of the form.
> > > > 
> > > > For example, say one has an algebraic data type
> > > > 
> > > >      data T = Number Int | Check Bool T
> > > > 
> > > > A form for such a type would initially consist of radio buttons or a
> > > > drop-down list with options "Number" and "Check" that lets the user
> > > > select the constructor. When "Number" is selected, an <input
> > > > type="number"> field is shown. When "Check" is selected, an <input
> > > > type="checkbox"> is displayed next to another form of this kind.
> > > > 
> > > > In the end, one would use the GHC.Generics machinery to generate forms
> > > > for a wide range of algebraic data types. I've seen this in the Clean
> > > > language's iTask library [1] and it's very convenient.
> > > > Of course this would involve a lot of JavaScript like
> > > > document.createElement() as well as book-keeping how to re-asseble the
> > > > fields into a T value upon submission. At least the latter is already
> > > > handled by libraries such as yesod-form.
> > > > 
> > > > Olaf
> > > > 
> > > > [1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic
> > > > [2] https://github.com/haskell-servant/servant-swagger/issues/80
> > > > 
> > > > 
> > 
> > Thanks for the pointer!
> > 
> > The Grace README says under Notable Omissions:
> > 
> > > Recursion or recursive data types
> > > 
> > > Grace only supports two built-in recursive types, which are List and
> > > JSON, but does not support user-defined recursion or anonymous
> > > recursion.
> > > 
> > > User-defined datatypes
> > > 
> > > All data types in Grace are anonymous (e.g. anonymous records and
> > > anonymous unions), and there is no concept of a data declaration
> > 
> > The tutorial shows how Grace function inputs are mapped to forms, where
> > functions with List input indeed have a form that is "dynamic" in the
> > sense I defined. Otherwise there is only one input field per function
> > argument. That means complex types are to be input in JSON syntax and
> > parsed.
> > Instead of a DSL, I'd prefer a shallow embedding into Haskell, so that
> > one can leverage all the available machinery.
> > Yet Grace already goes a long way towards what I am after.
> > 
> > Olaf
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.



From noonsilk at gmail.com  Thu Mar  2 16:47:07 2023
From: noonsilk at gmail.com (Noon van der Silk)
Date: Thu, 2 Mar 2023 16:47:07 +0000
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
	types
In-Reply-To: <28b32b14d74df3d5f8dd9fee3141f22e5623322a.camel@aatal-apotheke.de>
References: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
 <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>
 <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>
 <CACZKWEK8A8sfoZwqB2hUvYQrNCnOrDzY3YGEZcjbyUMBTFi4OQ@mail.gmail.com>
 <28b32b14d74df3d5f8dd9fee3141f22e5623322a.camel@aatal-apotheke.de>
Message-ID: <CAKBUzA2cw_aNoREjdZtaoE9G3evec41_vXec46VVS2bK8P1DyA@mail.gmail.com>

> So I should re-phrase my question:
> Has anyone extended tangible values to Generic types and given them a
> modern html interface?

I think the answer is "no"; and it would be extremely great if someone did.

But I think at least part of the problem is that one is forced to marry
oneself to a particular web framework/JavaScript library, and is therefore
immediately out of date :(

Personally, back in the day I quite like the API put out by Yesod for
auto-generating forms - https://www.yesodweb.com/book/forms - but I don't
think it quite does what you want. Maybe it's a simple adaptation, though
(of course, forcing yourself to use a particular flavour of
javascript/styling approach).


On Thu, 2 Mar 2023 at 16:41, Olaf Klinke <olf at aatal-apotheke.de> wrote:

> On Thu, 2023-03-02 at 07:34 -0800, Ivan Perez wrote:
> > All of this reminds me of Conal Elliott's Tangible Values.
> >
> > http://conal.net/papers/Eros/
> >
> > (Not for web but the idea still applies.)
> >
> > Ivan
>
> Yes, the concept has been re-invented multiple times, as is the case
> with most good ideas. TVs are general enough to bolt a web interface on
> top, I guess.
>
> Seems that Conal, too, has not solved the sum type problem.
> The tangible value GADT
> https://hackage.haskell.org/package/TV-0.5.0/docs/Interface-TV-Input.html
> has a Pair constructor but not for Sum. I wonder whether there is a
> deeper categorical reason for this.
>
> So I should re-phrase my question:
> Has anyone extended tangible values to Generic types and given them a
> modern html interface?
>
> Olaf
>
> >
> > On Thu, 2 Mar 2023 at 07:02, Olaf Klinke <olf at aatal-apotheke.de> wrote:
> >
> > > On Thu, 2023-03-02 at 15:51 +0200, Georgi Lyubenov wrote:
> > > > Hey Olaf,
> > > >
> > > > This is not an answer to your question, but I was reminded of
> Grace[0],
> > > > which is a language
> > > > with a "browser"[1] that allows you to type in terms and get back
> > > > webpages based on those terms
> > > > "automagically", which sounds like exactly what you need. I don't
> know
> > > > how it's implemented, so I don't know if
> > > > it is actually relevant to you, but it is worth noting that Grace
> itself
> > > > is implemented in Haskell.
> > > >
> > > > Cheers,
> > > > Georgi
> > > >
> > > > [0] https://github.com/Gabriella439/grace
> > > > [1] https://trygrace.dev/
> > > >
> > > > On 3/2/23 12:54, Olaf Klinke wrote:
> > > > > Dear Cafe,
> > > > >
> > > > > has anyone ever attempted (and maybe succeeded) in building dynamic
> > > > > forms using one of the Haskell web frameworks (Yesod,Servant,...)?
> > > > > By "dynamic" form I mean a form that changes the number of fields
> based
> > > > > on selections the user makes in other fields of the form.
> > > > >
> > > > > For example, say one has an algebraic data type
> > > > >
> > > > >      data T = Number Int | Check Bool T
> > > > >
> > > > > A form for such a type would initially consist of radio buttons or
> a
> > > > > drop-down list with options "Number" and "Check" that lets the user
> > > > > select the constructor. When "Number" is selected, an <input
> > > > > type="number"> field is shown. When "Check" is selected, an <input
> > > > > type="checkbox"> is displayed next to another form of this kind.
> > > > >
> > > > > In the end, one would use the GHC.Generics machinery to generate
> forms
> > > > > for a wide range of algebraic data types. I've seen this in the
> Clean
> > > > > language's iTask library [1] and it's very convenient.
> > > > > Of course this would involve a lot of JavaScript like
> > > > > document.createElement() as well as book-keeping how to re-asseble
> the
> > > > > fields into a T value upon submission. At least the latter is
> already
> > > > > handled by libraries such as yesod-form.
> > > > >
> > > > > Olaf
> > > > >
> > > > > [1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic
> > > > > [2] https://github.com/haskell-servant/servant-swagger/issues/80
> > > > >
> > > > >
> > >
> > > Thanks for the pointer!
> > >
> > > The Grace README says under Notable Omissions:
> > >
> > > > Recursion or recursive data types
> > > >
> > > > Grace only supports two built-in recursive types, which are List and
> > > > JSON, but does not support user-defined recursion or anonymous
> > > > recursion.
> > > >
> > > > User-defined datatypes
> > > >
> > > > All data types in Grace are anonymous (e.g. anonymous records and
> > > > anonymous unions), and there is no concept of a data declaration
> > >
> > > The tutorial shows how Grace function inputs are mapped to forms, where
> > > functions with List input indeed have a form that is "dynamic" in the
> > > sense I defined. Otherwise there is only one input field per function
> > > argument. That means complex types are to be input in JSON syntax and
> > > parsed.
> > > Instead of a DSL, I'd prefer a shallow embedding into Haskell, so that
> > > one can leverage all the available machinery.
> > > Yet Grace already goes a long way towards what I am after.
> > >
> > > Olaf
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > To (un)subscribe, modify options or view archives go to:
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > Only members subscribed via the mailman list are allowed to post.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Noon van der Silk, ن

http://silky.github.io/

"My programming language is kindness."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230302/881a16aa/attachment.html>

From mail at joachim-breitner.de  Thu Mar  2 17:22:15 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 02 Mar 2023 18:22:15 +0100
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
 types
In-Reply-To: <28b32b14d74df3d5f8dd9fee3141f22e5623322a.camel@aatal-apotheke.de>
References: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
 <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>
 <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>
 <CACZKWEK8A8sfoZwqB2hUvYQrNCnOrDzY3YGEZcjbyUMBTFi4OQ@mail.gmail.com>
 <28b32b14d74df3d5f8dd9fee3141f22e5623322a.camel@aatal-apotheke.de>
Message-ID: <c1195d353f9e51ac6e6991796515cf563ec80e5b.camel@joachim-breitner.de>

Hi,

Am Donnerstag, dem 02.03.2023 um 17:40 +0100 schrieb Olaf Klinke:
> Has anyone extended tangible values to Generic types and given them a
> modern html interface? 

not Haskell, but related: For the Candid Interface Description Language
(https://github.com/dfinity/candid/blob/master/spec/Candid.md), which
has products and sums and recursion, there is Candid UI, which builds
browser forms generically. The screenshot at
https://forum.dfinity.org/t/candid-ui-has-a-new-look/1887
might be helpful; the code is at
https://github.com/dfinity/candid/tree/master/tools/ui
It’s currently all very much tied to the DFINITY blockchain thingy,
although in theory the Candid format can could be used independently
(there is a Haskell implementation), and the UI components could also
be extracted.

So likely not directly useful to you, but certainly related work.

Cheers,
Joachim

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


From godzbanebane at gmail.com  Fri Mar  3 07:58:07 2023
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Fri, 3 Mar 2023 09:58:07 +0200
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
 types
In-Reply-To: <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>
References: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
 <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>
 <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>
Message-ID: <20a8dd70-90c9-f510-d8b0-da2147db54cd@gmail.com>

Hey

With the risk of being annoying, I want to point out that the Grace 
browser does indeed somewhat support
your original use case, because I feel like it might not be something 
obvious (there also is not an example for it, I think).

With the term
```
merge
     { Number: \n -> "The number is " + Real/show n
     , Check: \b -> if b then "checked" else "unchecked"
     }
```
which is equivalent to pattern matching on the input and picking a case, 
we get html with two radio buttons:
* Check - when this is selected, the output is based on whether a 
checkbox is checked
* Number - when this is selected, the output is based on the value in an 
input text field.

Of course, this is still suboptimal - the input text field and checkbox 
are shown at all times,
but I feel like I would have misrepresented the language if I did not 
point out it does support something like this.

Cheers,
Georgi

On 3/2/23 17:01, Olaf Klinke wrote:
> On Thu, 2023-03-02 at 15:51 +0200, Georgi Lyubenov wrote:
>> Hey Olaf,
>>
>> This is not an answer to your question, but I was reminded of Grace[0],
>> which is a language
>> with a "browser"[1] that allows you to type in terms and get back
>> webpages based on those terms
>> "automagically", which sounds like exactly what you need. I don't know
>> how it's implemented, so I don't know if
>> it is actually relevant to you, but it is worth noting that Grace itself
>> is implemented in Haskell.
>>
>> Cheers,
>> Georgi
>>
>> [0] https://github.com/Gabriella439/grace
>> [1] https://trygrace.dev/
>>
>> On 3/2/23 12:54, Olaf Klinke wrote:
>>> Dear Cafe,
>>>
>>> has anyone ever attempted (and maybe succeeded) in building dynamic
>>> forms using one of the Haskell web frameworks (Yesod,Servant,...)?
>>> By "dynamic" form I mean a form that changes the number of fields based
>>> on selections the user makes in other fields of the form.
>>>
>>> For example, say one has an algebraic data type
>>>
>>>       data T = Number Int | Check Bool T
>>>
>>> A form for such a type would initially consist of radio buttons or a
>>> drop-down list with options "Number" and "Check" that lets the user
>>> select the constructor. When "Number" is selected, an <input
>>> type="number"> field is shown. When "Check" is selected, an <input
>>> type="checkbox"> is displayed next to another form of this kind.
>>>
>>> In the end, one would use the GHC.Generics machinery to generate forms
>>> for a wide range of algebraic data types. I've seen this in the Clean
>>> language's iTask library [1] and it's very convenient.
>>> Of course this would involve a lot of JavaScript like
>>> document.createElement() as well as book-keeping how to re-asseble the
>>> fields into a T value upon submission. At least the latter is already
>>> handled by libraries such as yesod-form.
>>>
>>> Olaf
>>>
>>> [1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic
>>> [2] https://github.com/haskell-servant/servant-swagger/issues/80
>>>
>>>
> Thanks for the pointer!
>
> The Grace README says under Notable Omissions:
>
>> Recursion or recursive data types
>>
>> Grace only supports two built-in recursive types, which are List and
>> JSON, but does not support user-defined recursion or anonymous
>> recursion.
>>
>> User-defined datatypes
>>
>> All data types in Grace are anonymous (e.g. anonymous records and
>> anonymous unions), and there is no concept of a data declaration
> The tutorial shows how Grace function inputs are mapped to forms, where
> functions with List input indeed have a form that is "dynamic" in the
> sense I defined. Otherwise there is only one input field per function
> argument. That means complex types are to be input in JSON syntax and
> parsed.
> Instead of a DSL, I'd prefer a shallow embedding into Haskell, so that
> one can leverage all the available machinery.
> Yet Grace already goes a long way towards what I am after.
>
> Olaf
>
>
>
>   
>
>

From alexis.praga at proton.me  Fri Mar  3 12:48:50 2023
From: alexis.praga at proton.me (Alexis Praga)
Date: Fri, 03 Mar 2023 12:48:50 +0000
Subject: [Haskell-cafe] Status of ghcup?
In-Reply-To: <CACUTo6y2rJ=9ti_yYxFP9hMqA3gLiqmEfWrgyDbgtaneexPbEA@mail.gmail.com>
References: <CABU_mxg08GYz9=84Ak9zq19aweKHJ-qSNP+ZgJTaku6KmnTkWw@mail.gmail.com>
 <fLA1soheg5a472iij4q7UoXT4m5J0eWp4kgLipzg4VxZI8TGO3HO9bPnXgSXbxxSEpwaH8PNamL4Dqntr7fOHAvzOI4URIEl4zK9m1IiGbI=@proton.me>
 <b95bc59e-0e51-1eba-eb7c-4362cee56db5@glitchbra.in>
 <132e14c2-7eec-f439-fa55-60cffdaeaf8c@glitchbra.in>
 <Y/em7Qqeozek+B5g@straasha.imrryr.org>
 <CAKFCL4V=znecEGr9ZLZw6PCnZYmxrEpPSSgPOm6HybW3gMQmiw@mail.gmail.com>
 <Y/eoBXo5HK1iGoIp@straasha.imrryr.org>
 <xz2rtIzJ5b59xneH0XgPqBTiGGF0kRLf1sn6Utouo6xDePLYLDfK8tfZ-hZ3aE7qPqUGX9Q6y6Im6EkHNXpXfCHmo_uSj1c4H2kFG5rEJ0I=@proton.me>
 <CACUTo6y2rJ=9ti_yYxFP9hMqA3gLiqmEfWrgyDbgtaneexPbEA@mail.gmail.com>
Message-ID: <PiuyxnBgON8Bj2xdGfX18F0CdcuGJ2GerPy-wwQbwulJf43TfztM3pRu8nUO4XbUjgWTXAVLWkv-xpr0GTiWlnjPlN9PVFgZkxU4jR9svOE=@proton.me>

Hi,

Setting --cacert to the certificate issued by the company with putting in C:\Users\myuser\.curlrc
> cacert = mycertificate.cer
failed almost immediatly with :
> curl: (60) schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN

Disabling SSL in the same .curlrc :
> insecure
failed when mingw tried to download some packages.

Setting capath did not help either.


Alexis


------- Original Message -------
On Tuesday, February 28th, 2023 at 1:15 PM, Bryan Richter <bryan at haskell.foundation> wrote:


> The curl man page suggests the --cacert or --capath option.
> 
> https://www.man7.org/linux/man-pages/man1/curl.1.html
> 
> On Thu, 23 Feb 2023 at 20:00, Alexis Praga via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
> > I do have such a certificate. Do you have any pointer on how to configure curl to use, especially on windows and for ghcup ?
> > 
> > 
> > 
> > 
> > ------- Original Message -------
> > On Thursday, February 23rd, 2023 at 6:53 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> > 
> > 
> > >
> > >
> > > On Thu, Feb 23, 2023 at 12:50:40PM -0500, Brandon Allbery wrote:
> > >
> > > > You're all missing the possibility that the corporate gateway requires
> > > > a specific certificate so it can inspect traffic (anyone remember
> > > > https://arstechnica.com/information-technology/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/)?
> > >
> > >
> > > In which case, that certificate can be configured as trusted by curl,
> > > of course it that case it can't be provided by the ghcup team, and needs
> > > to obtained locally by the user.
> > >
> > > --
> > > 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.

From gusbicalho at gmail.com  Fri Mar  3 12:50:37 2023
From: gusbicalho at gmail.com (Gustavo Bicalho)
Date: Fri, 3 Mar 2023 09:50:37 -0300
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
	types
In-Reply-To: <mailman.0.1677844801.18281.haskell-cafe@haskell.org>
References: <mailman.0.1677844801.18281.haskell-cafe@haskell.org>
Message-ID: <CAEHjts4g9aT=pr859jO=p0QpwgWxNjRjxLtYVRCJ0Tn8Bnf0NA@mail.gmail.com>

>From briefly reading the wiki page
https://wiki.haskell.org/Tangible_Value, it looks like it relies on
Applicative functors for combining values.
So maybe the missing piece for sum-types was Selective functors
https://hackage.haskell.org/package/selective?

Gustavo Bicalho

> ---------- Forwarded message ----------
> From: Olaf Klinke <olf at aatal-apotheke.de>
> To: Ivan Perez <ivanperezdominguez at gmail.com>
> Cc: "Haskell Café" <haskell-cafe at haskell.org>
> Bcc:
> Date: Thu, 02 Mar 2023 17:40:18 +0100
> Subject: Re: [Haskell-cafe] dynamic web form generation for algebraic data types
> On Thu, 2023-03-02 at 07:34 -0800, Ivan Perez wrote:
> > All of this reminds me of Conal Elliott's Tangible Values.
> >
> > http://conal.net/papers/Eros/
> >
> > (Not for web but the idea still applies.)
> >
> > Ivan
>
> Yes, the concept has been re-invented multiple times, as is the case
> with most good ideas. TVs are general enough to bolt a web interface on
> top, I guess.
>
> Seems that Conal, too, has not solved the sum type problem.
> The tangible value GADT
> https://hackage.haskell.org/package/TV-0.5.0/docs/Interface-TV-Input.html
> has a Pair constructor but not for Sum. I wonder whether there is a
> deeper categorical reason for this.
>
> So I should re-phrase my question:
> Has anyone extended tangible values to Generic types and given them a
> modern html interface?
>
> Olaf

From olf at aatal-apotheke.de  Fri Mar  3 16:40:36 2023
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Fri, 03 Mar 2023 17:40:36 +0100
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
 types
In-Reply-To: <20a8dd70-90c9-f510-d8b0-da2147db54cd@gmail.com>
References: <da307d9aa81ff19281d7b42f0ce8b619237a18d2.camel@aatal-apotheke.de>
 <cd520642-07eb-21ab-f1a4-bb8967aaa8ea@gmail.com>
 <2060f680741702b42de34d3c700e7bbb1f4ecc50.camel@aatal-apotheke.de>
 <20a8dd70-90c9-f510-d8b0-da2147db54cd@gmail.com>
Message-ID: <dba132316e09ebcf309f7f0d36602fe9324118cf.camel@aatal-apotheke.de>

Georgi, 

your're absolutely right and I hope that I was clear enough when
stating that Grace *does* have dynamic forms, but with the limitations
stated in the project README. In fact I shall study how they are
realized under the hood. Noon is right in that one should be careful
not to rely on the hippest JavaScript framework which will become
obsolete soon. 
I've experiemented a little and conclude that monads provide a suitable
abstraction for dynamic forms, because >>= facilitates generation of
form parts conditional on results of other form evaluations. 
A proof-of-concept with InputT IO as the monad is published at
https://hub.darcs.net/olf/GenericForm/browse/GenericForm.hs
In its current state, it is capable of generating forms for types such
as Either String (Int,Bool). 

I also realized that while Yesod's MForm is a monad (transformer),
running a form produces a list of FieldView values, which the
programmer must assemble into the actual form html. While hiding some
fields conditionally may be feasible with yesod-form, I think forms for
recursive types are out of the question. As I understand it, the
monadic structure of MForm means that field values are *evaluated*
conditionally, but the fields must be present statically. Maybe Michael
Snoyman can weigh in on this. 

Olaf

On Fri, 2023-03-03 at 09:58 +0200, Georgi Lyubenov wrote:
> Hey
> 
> With the risk of being annoying, I want to point out that the Grace 
> browser does indeed somewhat support
> your original use case, because I feel like it might not be something 
> obvious (there also is not an example for it, I think).
> 
> With the term
> ```
> merge
>      { Number: \n -> "The number is " + Real/show n
>      , Check: \b -> if b then "checked" else "unchecked"
>      }
> ```
> which is equivalent to pattern matching on the input and picking a case, 
> we get html with two radio buttons:
> * Check - when this is selected, the output is based on whether a 
> checkbox is checked
> * Number - when this is selected, the output is based on the value in an 
> input text field.
> 
> Of course, this is still suboptimal - the input text field and checkbox 
> are shown at all times,
> but I feel like I would have misrepresented the language if I did not 
> point out it does support something like this.
> 
> Cheers,
> Georgi
> 
> On 3/2/23 17:01, Olaf Klinke wrote:
> > On Thu, 2023-03-02 at 15:51 +0200, Georgi Lyubenov wrote:
> > > Hey Olaf,
> > > 
> > > This is not an answer to your question, but I was reminded of Grace[0],
> > > which is a language
> > > with a "browser"[1] that allows you to type in terms and get back
> > > webpages based on those terms
> > > "automagically", which sounds like exactly what you need. I don't know
> > > how it's implemented, so I don't know if
> > > it is actually relevant to you, but it is worth noting that Grace itself
> > > is implemented in Haskell.
> > > 
> > > Cheers,
> > > Georgi
> > > 
> > > [0] https://github.com/Gabriella439/grace
> > > [1] https://trygrace.dev/
> > > 
> > > On 3/2/23 12:54, Olaf Klinke wrote:
> > > > Dear Cafe,
> > > > 
> > > > has anyone ever attempted (and maybe succeeded) in building dynamic
> > > > forms using one of the Haskell web frameworks (Yesod,Servant,...)?
> > > > By "dynamic" form I mean a form that changes the number of fields based
> > > > on selections the user makes in other fields of the form.
> > > > 
> > > > For example, say one has an algebraic data type
> > > > 
> > > >       data T = Number Int | Check Bool T
> > > > 
> > > > A form for such a type would initially consist of radio buttons or a
> > > > drop-down list with options "Number" and "Check" that lets the user
> > > > select the constructor. When "Number" is selected, an <input
> > > > type="number"> field is shown. When "Check" is selected, an <input
> > > > type="checkbox"> is displayed next to another form of this kind.
> > > > 
> > > > In the end, one would use the GHC.Generics machinery to generate forms
> > > > for a wide range of algebraic data types. I've seen this in the Clean
> > > > language's iTask library [1] and it's very convenient.
> > > > Of course this would involve a lot of JavaScript like
> > > > document.createElement() as well as book-keeping how to re-asseble the
> > > > fields into a T value upon submission. At least the latter is already
> > > > handled by libraries such as yesod-form.
> > > > 
> > > > Olaf
> > > > 
> > > > [1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic
> > > > [2] https://github.com/haskell-servant/servant-swagger/issues/80
> > > > 
> > > > 
> > Thanks for the pointer!
> > 
> > The Grace README says under Notable Omissions:
> > 
> > > Recursion or recursive data types
> > > 
> > > Grace only supports two built-in recursive types, which are List and
> > > JSON, but does not support user-defined recursion or anonymous
> > > recursion.
> > > 
> > > User-defined datatypes
> > > 
> > > All data types in Grace are anonymous (e.g. anonymous records and
> > > anonymous unions), and there is no concept of a data declaration
> > The tutorial shows how Grace function inputs are mapped to forms, where
> > functions with List input indeed have a form that is "dynamic" in the
> > sense I defined. Otherwise there is only one input field per function
> > argument. That means complex types are to be input in JSON syntax and
> > parsed.
> > Instead of a DSL, I'd prefer a shallow embedding into Haskell, so that
> > one can leverage all the available machinery.
> > Yet Grace already goes a long way towards what I am after.
> > 
> > Olaf
> > 
> > 
> > 
> >   
> > 
> > 
> > 



From ben at well-typed.com  Fri Mar  3 21:57:11 2023
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 03 Mar 2023 16:57:11 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1-rc1 is now available
Message-ID: <87a60tqz1h.fsf@smart-cactus.org>

The GHC team is very pleased to announce the availability of the first
(and likely final) release candidate of GHC 9.6.1. As usual, binaries
and source distributions are available at
[downloads.haskell.org](https://downloads.haskell.org/ghc/9.6.1-rc1/).

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to
WebAssembly and JavaScript. This is an important step towards robust
support for compiling Haskell to the Web, but there are a few caveats to
be aware of in the 9.6 series:

 - Both the Javascript and WebAssembly backends are still at an early
   stage of development and are present in this release as a technology
   preview

 - Using GHC as a cross-compiler is not as easy as we would like it to
   be; in particular, there are challenges related to Template Haskell

 - GHC is not yet run-time retargetable; a given GHC binary targets
   exactly one platform, and both WebAssembly and JavaScript are
   considered platforms for this purpose. Cross-compilers must be built
   from source by their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 will include:

 - Significant latency improvements in the non-moving garbage collector

 - Efficient runtime support for delimited continuations

 - Improvements in compiler error messages

 - Numerous improvements in the compiler's memory usage

See the [release notes][] for a comprehensive accounting of changes in
this release.

As always, one can find a migration guide to aid in transitioning from
older releases on the [GHC Wiki][migration-guide]. We have also recently
started extending our release process to cover a wider set of Linux
distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04
binary distributions which cover RedHat-derivative and distributions
using older `glibc` releases (namely 2.27), respectively.

Please do give this release a try and open a [ticket][] if you see
anything amiss. If all goes well we expect the final release should be
available by late next week.

Happy Haskelling,

~ Ben


[ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
[migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6
[release notes]: https://downloads.haskell.org/ghc/9.6.1-rc1/docs/users_guide/9.6.1-notes.html

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

From mitchellwrosen at gmail.com  Mon Mar  6 16:33:39 2023
From: mitchellwrosen at gmail.com (Mitchell Rosen)
Date: Mon, 6 Mar 2023 11:33:39 -0500
Subject: [Haskell-cafe] Move on with the takeover of unix-compat [Re:
 Takeover request: unix-compat]
In-Reply-To: <CAKYGvgNr-Cp88UOnHgNso8zHUF1VbS80-Ryhfuq378-j7tVXxA@mail.gmail.com>
References: <CAKYGvgOvfXqbCDFukCAzhok6D0W2tE_J7Pj+EzbiLfr=zzithg@mail.gmail.com>
 <8199a844-708c-9939-63d2-9e872145729e@online.de>
 <cc9e5726-e206-ab17-ada1-dd71aad72a02@ifi.lmu.de>
 <CAKYGvgNr-Cp88UOnHgNso8zHUF1VbS80-Ryhfuq378-j7tVXxA@mail.gmail.com>
Message-ID: <CAKYGvgMckFhUpLgOdC2J=RDNObhVsFAg96pbEH2Kbr7aLuwTtA@mail.gmail.com>

No word from hackage-admin at haskell.org after 13 days. I'm not sure anyone
is listening. :/

On Tue, Feb 21, 2023 at 12:05 AM Mitchell Rosen <mitchellwrosen at gmail.com>
wrote:

> Thanks, I've sent an email to the admins.
>
> On Mon, Feb 20, 2023, 2:14 PM Andreas Abel <andreas.abel at ifi.lmu.de>
> wrote:
>
>> On 2023-02-15 21:46, Ben Franksen wrote:
>> > Am 05.02.23 um 16:52 schrieb Mitchell Rosen:
>> >> Hi all, I'd like to take over maintenance responsibility for the
>> >> `unix-compat` package. Unfortunately, I've been unable to get in touch
>> >> with
>> >> the maintainer.
>> >>
>> >> I intend to make a release compatible with `unix-2.8`, and will be
>> around
>> >> to make subsequent bounds bumps and whatnot.
>> >
>> > Hi Mitchell, I made some contributions to unix-compat over the years
>> and
>> > found that the current maintainer, while sometimes a bit slow to
>> respond
>> > to PRs, is actually quite responsive when prompted via email. (Just a
>> > data point, not to suggest you haven't tried that.)
>>
>> @Ben, this might have been so in the past, but recent evidence suggests
>> otherwise.
>>
>> - I alerted Jacob of the situation over a month ago by email, here is
>> the log for this:
>>
>>
>>
>> https://github.com/jacobstanley/unix-compat/issues/63#issuecomment-1386676351
>>
>> - His profile https://github.com/jacobstanley does not even include an
>> email address.  I had to hunt down an email address by searching the web
>> for possible matches.
>>
>> Because unix-compat is quite important for the Haskell ecosystem and (is
>> already not maintained by the original authors), I think we should find
>> a solution quickly and move on with the package takeover.
>>
>> It is anyway good if important packages have co-maintainers that can
>> fill the gap should the current maintainer be unavailable for a longer
>> period of time.
>>
>> @Mitchell:  I think the waiting time has now passed and you can contact
>> the Hackage admins to add you to the maintainers of unix-compat on
>> Hackage.
>>
>> Cheers,
>> Andreas
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230306/0958e60a/attachment.html>

From persiantiger at yandex.ru  Mon Mar  6 20:05:18 2023
From: persiantiger at yandex.ru (Andrey Prokopenko)
Date: Mon, 6 Mar 2023 21:05:18 +0100
Subject: [Haskell-cafe]  Take-over request for: snappy
Message-ID: <75D9B385-6BD8-4F2F-87D0-49B0A63D5590@yandex.ru>

Hello,

- Few months ago Andrew Martin opened PR in `snappy`: https://github.com/bos/snappy/pull/10 <https://github.com/bos/snappy/pull/10>  
- The package is either direct or transient dependency for `tensorflow`, `kafka-client` and few more packages.
- While forks maintenance is a well-known practice it creates burden on maintainers.
- Moreover, I cannot easily fix cabal build for tensorflow for different GHC versions.

Note for Bryan: I haven’t forked `snappy` so there will be no name clashes during the transfer.

I would like to become a maintainer for `snappy` package and keep it up-to-date at least for a next few years.

I have already followed that procedure a few years ago for `blaze-textual` package. (Recently I discovered a flaw in my maintenance setup and fixed it.)
So my intent is to resolve recent PRs and to keep supporting for newer compiler versions and build tools.

Please consider this message as a step 2 in take-over procedure: https://wiki.haskell.org/Taking_over_a_package <https://wiki.haskell.org/Taking_over_a_package> 

Kind Regards,
Andrey Prokopenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230306/32303674/attachment.html>

From ivanperezdominguez at gmail.com  Tue Mar  7 04:36:32 2023
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Mon, 6 Mar 2023 20:36:32 -0800
Subject: [Haskell-cafe] [ANN] dunai-0.10.1 and bearriver-0.14.1
Message-ID: <CACZKWELOogXd94+GK3o2RWQY+Nv1YaxGaky_e8Zru0Od99C2rw@mail.gmail.com>

Dear all,

I'm happy to announce the release of Dunai 0.10.1 and Bearriver 0.14.1!

Dunai is a reactive programming library structured around a notion of
Monadic Stream Functions. Dunai can be used to implement other reactive
and FRP frameworks on top, including Classic FRP and Arrowized FRP
variants.

Dunai comes with:

- bearriver: API-compatible implementation of Yampa. (The Bear River is
  a tributary to the Yampa river.)

- dunai-test: QuickCheck-based temporal testing library that can be
  connected with the testing system haskell-titan.

See https://github.com/ivanperez-keera/dunai#features for details on
Dunai's features.

This new release introduces a breaking change in Monadic Stream
Functions' instance of VectorSpaces. Most code using that instance
should work without changes but, in some cases, the use of 'constantly'
is now necessary. (This case is described in the discussion thread of
issue #298.)

* Summary of Version 0.10.1:

- Implement dot in MSF's instance of VectorSpace (#298).
- Enable FlexibleContexts in VectorSpace instance module (#344).

As always, dunai, dunai-test and bearriver are released in sync. For
details, see:

- https://github.com/ivanperez-keera/dunai/releases/tag/v0.10.1

* Releases

You can explore the current versions at:
- https://hackage.haskell.org/package/dunai
- https://hackage.haskell.org/package/dunai-test
- https://hackage.haskell.org/package/bearriver

* Code

The github repo is located at: https://github.com/ivanperez-keera/dunai

* What's coming

This release comes exactly 2 months after the last release. The next
release is planned for Apr 21, 2023.

There are several issues open that you can contribute to:

https://github.com/ivanperez-keera/dunai/issues

Following our roadmap, the pending changes remain as follows:

- Full conformance to style guide.

- Benchmarks: Facilitate making sound, evidence-based decisions about
  suggested improvements to the implementation, by completing a series
  of benchmarks.

* Donations

Our project is now seeking donations to help continue developing dunai,
create new open source libraries, new material, and give talks.

Special thanks go to @johannes-riecken for sponsoring my work on the
dunai project with a regular contribution.

Github will match the first 5K donated, so if you donate $1/month,
github will donate the same amount.

No donation is too small. Any contribution will absolutely help.

See https://github.com/sponsors/ivanperez-keera for details.

If you can help, please come forward.

All the best,

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

From bryan at haskell.foundation  Tue Mar  7 08:42:46 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Tue, 7 Mar 2023 10:42:46 +0200
Subject: [Haskell-cafe] Move on with the takeover of unix-compat [Re:
 Takeover request: unix-compat]
In-Reply-To: <CAKYGvgMckFhUpLgOdC2J=RDNObhVsFAg96pbEH2Kbr7aLuwTtA@mail.gmail.com>
References: <CAKYGvgOvfXqbCDFukCAzhok6D0W2tE_J7Pj+EzbiLfr=zzithg@mail.gmail.com>
 <8199a844-708c-9939-63d2-9e872145729e@online.de>
 <cc9e5726-e206-ab17-ada1-dd71aad72a02@ifi.lmu.de>
 <CAKYGvgNr-Cp88UOnHgNso8zHUF1VbS80-Ryhfuq378-j7tVXxA@mail.gmail.com>
 <CAKYGvgMckFhUpLgOdC2J=RDNObhVsFAg96pbEH2Kbr7aLuwTtA@mail.gmail.com>
Message-ID: <CACUTo6ykFX7Cq3K7AaD4WcL_=cA9RGcDy+ZCf3fyHGKCrvo7Tg@mail.gmail.com>

Do we need to update the list of Hackage administrators? I know there's
been some turnover in the community in the last couple years.

On Mon, 6 Mar 2023 at 18:34, Mitchell Rosen <mitchellwrosen at gmail.com>
wrote:

> No word from hackage-admin at haskell.org after 13 days. I'm not sure anyone
> is listening. :/
>
> On Tue, Feb 21, 2023 at 12:05 AM Mitchell Rosen <mitchellwrosen at gmail.com>
> wrote:
>
>> Thanks, I've sent an email to the admins.
>>
>> On Mon, Feb 20, 2023, 2:14 PM Andreas Abel <andreas.abel at ifi.lmu.de>
>> wrote:
>>
>>> On 2023-02-15 21:46, Ben Franksen wrote:
>>> > Am 05.02.23 um 16:52 schrieb Mitchell Rosen:
>>> >> Hi all, I'd like to take over maintenance responsibility for the
>>> >> `unix-compat` package. Unfortunately, I've been unable to get in
>>> touch
>>> >> with
>>> >> the maintainer.
>>> >>
>>> >> I intend to make a release compatible with `unix-2.8`, and will be
>>> around
>>> >> to make subsequent bounds bumps and whatnot.
>>> >
>>> > Hi Mitchell, I made some contributions to unix-compat over the years
>>> and
>>> > found that the current maintainer, while sometimes a bit slow to
>>> respond
>>> > to PRs, is actually quite responsive when prompted via email. (Just a
>>> > data point, not to suggest you haven't tried that.)
>>>
>>> @Ben, this might have been so in the past, but recent evidence suggests
>>> otherwise.
>>>
>>> - I alerted Jacob of the situation over a month ago by email, here is
>>> the log for this:
>>>
>>>
>>>
>>> https://github.com/jacobstanley/unix-compat/issues/63#issuecomment-1386676351
>>>
>>> - His profile https://github.com/jacobstanley does not even include an
>>> email address.  I had to hunt down an email address by searching the web
>>> for possible matches.
>>>
>>> Because unix-compat is quite important for the Haskell ecosystem and (is
>>> already not maintained by the original authors), I think we should find
>>> a solution quickly and move on with the package takeover.
>>>
>>> It is anyway good if important packages have co-maintainers that can
>>> fill the gap should the current maintainer be unavailable for a longer
>>> period of time.
>>>
>>> @Mitchell:  I think the waiting time has now passed and you can contact
>>> the Hackage admins to add you to the maintainers of unix-compat on
>>> Hackage.
>>>
>>> Cheers,
>>> Andreas
>>>
>> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230307/0fa6ab6e/attachment.html>

From ryan.gl.scott at gmail.com  Wed Mar  8 12:24:22 2023
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 8 Mar 2023 07:24:22 -0500
Subject: [Haskell-cafe] Call for Talks: Haskell Implementors' Workshop 2023
Message-ID: <CADdQpRA8kbUta4Dw5bOneuu+JSY0xFKc23UOndbgfxXEuE1kWA@mail.gmail.com>

ACM SIGPLAN Haskell Implementors' Workshop
https://icfp23.sigplan.org/home/hiw-2023
Seattle, Washington, United States, September 4, 2023

Co-located with ICFP 2023
https://icfp23.sigplan.org/

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

Deadline: July 4, 2023 (AoE)
Notification: August 4, 2023
Workshop: September 4, 2023

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

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

Scope and target audience
-------------------------

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

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

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

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

Talks
-----

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

Submissions can be made via HotCRP at https://icfphiw23.hotcrp.com
until July 4 (anywhere on earth).

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

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

* Gergő Érdi (Standard Chartered Bank)
* Sebastian Graf (Karlsruhe Institute of Technology)
* Wen Kokke (University of Strathclyde)
* Ryan Scott (Galois, Inc.)
* Rebecca Skinner (Mercury)
* Li-yao Xia (University of Edinburgh)

Contact
-------

* Ryan Scott <ryan.gl.scott at gmail.com>

From ivanperezdominguez at gmail.com  Wed Mar  8 21:58:02 2023
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Wed, 8 Mar 2023 13:58:02 -0800
Subject: [Haskell-cafe] [ANN] Copilot 3.14
Message-ID: <CACZKWE+13v+dzZQDqdsLo09D6GFA2_H5teYOMXexjR+qbQNEqw@mail.gmail.com>

(Apologies if you see this through multiple channels.)

Hi everyone,

I’m very excited to announce Copilot 3.14. Copilot is a stream-based EDSL
in Haskell for writing and monitoring embedded C programs, with an emphasis
on correctness and hard realtime requirements. Copilot is typically used as
a high-level runtime verification framework, and supports temporal logic
(LTL, PTLTL and MTL), clocks and voting algorithms.

Copilot has been used at NASA in drone test flights. Through the NASA tool
Ogma [1] (also written in Haskell), Copilot also serves as a runtime
monitoring backend for the requirements elicitation tool FRET [4], and can
target NASA’s Core Flight System and the Robot Operating System (ROS2)
applications.

This new version provides up-to-date compiler support, simplifies the API,
and improves the documentation. For details, see [2].

As always, we’re releasing exactly 2 months since the last release. Our
next release is scheduled for May 7th, 2023. We have almost completed the
C99 unit tests, and plan to include those in the next version. Copilot is
currently undergoing the qualification process necessary for NASA Class D
Software. Current emphasis is on increasing test coverage, removing
unnecessary dependencies, hiding internal definitions, and formatting the
code to meet our new coding standards. Users are encouraged to participate
by opening issues and asking questions via our github repo [3]

There’s been many more updates on the Copilot front in the last few months.
We’ll be able to announce more soon. Stay tuned.

Happy Haskelling!

Ivan

[1] https://github.com/nasa/ogma

[2] https://github.com/Copilot-Language/copilot/releases/tag/v3.14

[3] https://github.com/Copilot-Language/copilot

[4] https://github.com/NASA-SW-VnV/fret
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230308/d4e4eb8d/attachment.html>

From ty.wang at btq.li  Thu Mar  9 07:03:16 2023
From: ty.wang at btq.li (Ting Wang)
Date: Thu, 9 Mar 2023 15:03:16 +0800
Subject: [Haskell-cafe] Alpha Release of Keelung,
 the New Haskell DSL Designed for Secure and Fast Application
 Development
Message-ID: <CALR3Zw-xcT8TNrMoHMdknHiVujvsHC9QW3FoAVGgks=vfwG=ug@mail.gmail.com>

Hello developers,

I'm Ting with BTQ. We are thrilled to announce the alpha release of
Keelung, a new domain-specific language (DSL) designed to make fast,
private, and secure application development easy for developers.Both
Keelung and its compiler have been implemented in Haskell, enabling you to
produce high-level zero-knowledge proofs protected by Haskell's
cutting-edge type system while leveraging Haskell's extensive ecosystem and
tooling. What's more, Keelung will be 100% open-source, aligning with our
values of transparency, collaboration, and community-driven development.Check
out our blog post <https://www.btq.com/en/blog/keelung-alpha-release> of
Keelung alpha release for more detail. If you're interested in using
Keelung to build privacy-preserving applications, please visit our GitHub
repository <https://github.com/btq-ag/keelung> and Hackage
<https://hackage.haskell.org/package/keelung>. Our documentation
<https://btq.gitbook.io/keelung/> also provides detailed information on how
to use Keelung, including installation instructions, examples, and
tutorials.If you have any questions about Keelung or would like to
contribute to the project, please start a thread on our GitHub discussions
<https://github.com/btq-ag/keelung/discussions> page or reach out to us via
email at desk at btq.li. We're always happy to help and would love to hear
from you!Thank you and we can't wait to see what you build with it!


Ting Wang (Ms.)

Product Manager
ty.wang at btq.li
www.btq.com

[image: twitter] <https://twitter.com/btq_ag>
[image: linkedin] <https://www.linkedin.com/company/btqag/about/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230309/69d3a043/attachment.html>

From andrei.h.popescu at gmail.com  Fri Mar 10 00:11:18 2023
From: andrei.h.popescu at gmail.com (Andrei Popescu)
Date: Fri, 10 Mar 2023 00:11:18 +0000
Subject: [Haskell-cafe] PhD or Postdoc Position at LMU Munich about Verified
	Modal Logics
Message-ID: <CAACfPHr-YDSDEyMT55W8M93eLBn43QQ+jha-Pg-nZDry8V21Hg@mail.gmail.com>

We are looking for a PhD student (4 years) or postdoctoral researcher
(3 years) to work on the Isabelle formalization of modal model theory.
The work will take place within the Chair of Theoretical Computer
Science at LMU Munich under Jasmin Blanchette's supervision with the
participation of two external experts: Cláudia Nalon (University of
Brasília) and Sophie Tourret (Inria Nancy).

Modal logics are extensions of classical logics with operators that
allow for the qualification of truth. Model theory for modal logics is
concerned with the interplay between the language (syntax, i.e., the
set of its formulas) and its meaning (semantics, i.e., the structures
over which the language is interpreted). There are, however, different
ways of characterizing meaning for modal sentences and also several
(well-established) results that allow for restriction on the sets of
structures being considered. This project concerns the formalization
in Isabelle of those results for general Kripke structures for
generalized modal operators (i.e., of any arity). The goal is to
produce a library that could then be used (and possibly extended) for
specific applications, in particular those related to proof theory.

The position is categorized as TV-L E13 according to the German salary
scale. It includes some teaching obligations. The starting date is
flexible. Please contact Jasmin Blanchette
(jasmin.blanchette at ifi.lmu.de) for more information or if you want to
apply. The application deadline is 15 April 2023.

From david.feuer at gmail.com  Fri Mar 10 02:01:01 2023
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 9 Mar 2023 21:01:01 -0500
Subject: [Haskell-cafe] ANN: atomic-modify-general
Message-ID: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>

I just put together a new package, atomic-modify-general, for
generalizations of the `atomicModifyIORef` operation. In particular:

1. Versions that allow a result of an arbitrary type (not necessarily
a pair), where the caller passes in an extraction function. These work
with `Array` and `SmallArray` from `primitive` as well as `IORef`.
2. A version that works with record types (not just pairs) whose first
field is the new value to install in the `IORef`. This uses
implementation details of the `atomicModifyMutVar#` primop as well as
GHC's heap object layout to achieve better performance.

Please try it out and let me know how it goes, and what extras you may want!

Hackage: https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0

From x at tomsmeding.com  Fri Mar 10 08:26:36 2023
From: x at tomsmeding.com (Tom Smeding)
Date: Fri, 10 Mar 2023 09:26:36 +0100
Subject: [Haskell-cafe] ANN: atomic-modify-general
In-Reply-To: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>
References: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>
Message-ID: <eb51d6a0-3eb8-d539-b563-3e4453f8be58@tomsmeding.com>

Hi David,

Fancy stuffs!

Wondering how much magic was going on in implementing this, I saw that 
atomicModifyIORef2Native misses the haddock marker '|' in the source; 
thus your extensive doc comment doesn't show up on hackage.

Cheers,
Tom

On 10/03/2023 03:01, David Feuer wrote:
> I just put together a new package, atomic-modify-general, for
> generalizations of the `atomicModifyIORef` operation. In particular:
>
> 1. Versions that allow a result of an arbitrary type (not necessarily
> a pair), where the caller passes in an extraction function. These work
> with `Array` and `SmallArray` from `primitive` as well as `IORef`.
> 2. A version that works with record types (not just pairs) whose first
> field is the new value to install in the `IORef`. This uses
> implementation details of the `atomicModifyMutVar#` primop as well as
> GHC's heap object layout to achieve better performance.
>
> Please try it out and let me know how it goes, and what extras you may want!
>
> Hackage: https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


From heraldhoi at gmail.com  Fri Mar 10 08:30:40 2023
From: heraldhoi at gmail.com (Geraldus)
Date: Fri, 10 Mar 2023 11:30:40 +0300
Subject: [Haskell-cafe] Nearly lens examples
Message-ID: <CAB2YT55vREzMz8v8wX970XjDaZH9+0u7DwgP7yu_HZSdAZcW5g@mail.gmail.com>

Dear all! Do you have good usage examples of *nearly* lens, especially in
composition with other lenses / prisms?

Sincerely yours, Arthur.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230310/fe189a45/attachment.html>

From david.feuer at gmail.com  Fri Mar 10 08:45:41 2023
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 10 Mar 2023 03:45:41 -0500
Subject: [Haskell-cafe] ANN: atomic-modify-general
In-Reply-To: <eb51d6a0-3eb8-d539-b563-3e4453f8be58@tomsmeding.com>
References: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>
 <eb51d6a0-3eb8-d539-b563-3e4453f8be58@tomsmeding.com>
Message-ID: <CAMgWh9svyCMosmMU0-esPVRfqoKKVz0wmm_KuM3t_8c6v77-pA@mail.gmail.com>

Whoops! Thanks for pointing that out. I'll fix it and push new docs.
There's not much magic in that part of the code itself; the nasty magic is
knowing that the first pointer in any record is in the same position in its
heap object as the first component of a pair. Speaking of which, do you
have any idea if it'll work for non-record types whose constructors all
have the same first field? I'm guessing yes, but I haven't experimented yet.

On Fri, Mar 10, 2023, 3:27 AM Tom Smeding <x at tomsmeding.com> wrote:

> Hi David,
>
> Fancy stuffs!
>
> Wondering how much magic was going on in implementing this, I saw that
> atomicModifyIORef2Native misses the haddock marker '|' in the source;
> thus your extensive doc comment doesn't show up on hackage.
>
> Cheers,
> Tom
>
> On 10/03/2023 03:01, David Feuer wrote:
> > I just put together a new package, atomic-modify-general, for
> > generalizations of the `atomicModifyIORef` operation. In particular:
> >
> > 1. Versions that allow a result of an arbitrary type (not necessarily
> > a pair), where the caller passes in an extraction function. These work
> > with `Array` and `SmallArray` from `primitive` as well as `IORef`.
> > 2. A version that works with record types (not just pairs) whose first
> > field is the new value to install in the `IORef`. This uses
> > implementation details of the `atomicModifyMutVar#` primop as well as
> > GHC's heap object layout to achieve better performance.
> >
> > Please try it out and let me know how it goes, and what extras you may
> want!
> >
> > Hackage:
> https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230310/9d90e38b/attachment.html>

From x at tomsmeding.com  Fri Mar 10 09:09:53 2023
From: x at tomsmeding.com (Tom Smeding)
Date: Fri, 10 Mar 2023 10:09:53 +0100
Subject: [Haskell-cafe] ANN: atomic-modify-general
In-Reply-To: <CAMgWh9svyCMosmMU0-esPVRfqoKKVz0wmm_KuM3t_8c6v77-pA@mail.gmail.com>
References: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>
 <eb51d6a0-3eb8-d539-b563-3e4453f8be58@tomsmeding.com>
 <CAMgWh9svyCMosmMU0-esPVRfqoKKVz0wmm_KuM3t_8c6v77-pA@mail.gmail.com>
Message-ID: <50fdf76d-436e-abd9-5b5e-ecd0977e36b9@tomsmeding.com>

I'm not the person to ask :) Maybe someone else on the list can chip in 
here.

Another question if you don't mind (I'm learning here): you say below 
that in atomicModifyIORef2Native, you rely on heap object layout to 
unsafeCoerce between a pair and any object with an interesting value in 
the first field. But looking at the source [1], it seems you only do 
this for base < 4.13, i.e. GHC < 8.8.4. That's been a while.

Is it true that for GHCs since 8.8.4 you can just use a primop to do 
what you want directly, without the magic Generic stuff? If so, perhaps 
you can even drop the Generic constraints for high enough GHC versions 
(by extending the scope of the CPP slightly)? 8.6.5 is still popular, 
but simultaneously a whole bunch of applications don't care about GHCs 
<9 anymore.

- Tom

[1]: 
https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0/docs/src/Data.IORef.AtomicModify.Generic.html#atomicModifyIORef2Native

On 10/03/2023 09:45, David Feuer wrote:
> Whoops! Thanks for pointing that out. I'll fix it and push new docs. 
> There's not much magic in that part of the code itself; the nasty 
> magic is knowing that the first pointer in any record is in the same 
> position in its heap object as the first component of a pair. Speaking 
> of which, do you have any idea if it'll work for non-record types 
> whose constructors all have the same first field? I'm guessing yes, 
> but I haven't experimented yet.
>
> On Fri, Mar 10, 2023, 3:27 AM Tom Smeding <x at tomsmeding.com> wrote:
>
>     Hi David,
>
>     Fancy stuffs!
>
>     Wondering how much magic was going on in implementing this, I saw
>     that
>     atomicModifyIORef2Native misses the haddock marker '|' in the source;
>     thus your extensive doc comment doesn't show up on hackage.
>
>     Cheers,
>     Tom
>
>     On 10/03/2023 03:01, David Feuer wrote:
>     > I just put together a new package, atomic-modify-general, for
>     > generalizations of the `atomicModifyIORef` operation. In particular:
>     >
>     > 1. Versions that allow a result of an arbitrary type (not
>     necessarily
>     > a pair), where the caller passes in an extraction function.
>     These work
>     > with `Array` and `SmallArray` from `primitive` as well as `IORef`.
>     > 2. A version that works with record types (not just pairs) whose
>     first
>     > field is the new value to install in the `IORef`. This uses
>     > implementation details of the `atomicModifyMutVar#` primop as
>     well as
>     > GHC's heap object layout to achieve better performance.
>     >
>     > Please try it out and let me know how it goes, and what extras
>     you may want!
>     >
>     > Hackage:
>     https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0
>     > _______________________________________________
>     > Haskell-Cafe mailing list
>     > To (un)subscribe, modify options or view archives go to:
>     > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     > Only members subscribed via the mailman list are allowed to post.
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view 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/20230310/83045769/attachment.html>

From david.feuer at gmail.com  Fri Mar 10 14:05:42 2023
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 10 Mar 2023 09:05:42 -0500
Subject: [Haskell-cafe] ANN: atomic-modify-general
In-Reply-To: <50fdf76d-436e-abd9-5b5e-ecd0977e36b9@tomsmeding.com>
References: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>
 <eb51d6a0-3eb8-d539-b563-3e4453f8be58@tomsmeding.com>
 <CAMgWh9svyCMosmMU0-esPVRfqoKKVz0wmm_KuM3t_8c6v77-pA@mail.gmail.com>
 <50fdf76d-436e-abd9-5b5e-ecd0977e36b9@tomsmeding.com>
Message-ID: <CAMgWh9v7gaDmqJ+MaU3=qR-C5OoU7z7bP-3ju3TF7niXuku2aw@mail.gmail.com>

Unfortunately not. The type the type checker is told for the
`atomicModifyMutVar2#` primop is a lie (too permissive). The type
documented in its Haddocks is also a lie (too restrictive). Its most
precise type, as I understand it, is (translating away the unboxed stuff
and the internal I/O representation)

atomicModifyMutVar2
  :: IORef a
  -> (a -> t)
  -> IO (a, t)
-- with the condition that `t` is a record whose first field that is
represented by a pointer (what we call BoxedRep) has a type with the same
memory representation as `a`.

While it would be possible to express that fairly precisely using the
Generics approach, I think it's too hard to think about "the first pointer
field", and the "same memory representation" bit mucks with type inference.
So I restricted it a little to "the first field, which must be a pointer",
and "with type `a`".

There's a sort of "hidden unsafeCoerce" in the primop call, where we know
that the "selector thunk" it builds (a thunk applying a record selector, in
this case fst) will extract the field we want out of what we give it. The
type checker is clueless and just accepts whatever.


On Fri, Mar 10, 2023, 4:09 AM Tom Smeding <x at tomsmeding.com> wrote:

> I'm not the person to ask :) Maybe someone else on the list can chip in
> here.
>
> Another question if you don't mind (I'm learning here): you say below that
> in atomicModifyIORef2Native, you rely on heap object layout to
> unsafeCoerce between a pair and any object with an interesting value in the
> first field. But looking at the source [1], it seems you only do this for
> base < 4.13, i.e. GHC < 8.8.4. That's been a while.
>
> Is it true that for GHCs since 8.8.4 you can just use a primop to do what
> you want directly, without the magic Generic stuff? If so, perhaps you can
> even drop the Generic constraints for high enough GHC versions (by
> extending the scope of the CPP slightly)? 8.6.5 is still popular, but
> simultaneously a whole bunch of applications don't care about GHCs <9
> anymore.
>
> - Tom
>
> [1]:
> https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0/docs/src/Data.IORef.AtomicModify.Generic.html#atomicModifyIORef2Native
>
> On 10/03/2023 09:45, David Feuer wrote:
>
> Whoops! Thanks for pointing that out. I'll fix it and push new docs.
> There's not much magic in that part of the code itself; the nasty magic is
> knowing that the first pointer in any record is in the same position in its
> heap object as the first component of a pair. Speaking of which, do you
> have any idea if it'll work for non-record types whose constructors all
> have the same first field? I'm guessing yes, but I haven't experimented yet.
>
> On Fri, Mar 10, 2023, 3:27 AM Tom Smeding <x at tomsmeding.com> wrote:
>
>> Hi David,
>>
>> Fancy stuffs!
>>
>> Wondering how much magic was going on in implementing this, I saw that
>> atomicModifyIORef2Native misses the haddock marker '|' in the source;
>> thus your extensive doc comment doesn't show up on hackage.
>>
>> Cheers,
>> Tom
>>
>> On 10/03/2023 03:01, David Feuer wrote:
>> > I just put together a new package, atomic-modify-general, for
>> > generalizations of the `atomicModifyIORef` operation. In particular:
>> >
>> > 1. Versions that allow a result of an arbitrary type (not necessarily
>> > a pair), where the caller passes in an extraction function. These work
>> > with `Array` and `SmallArray` from `primitive` as well as `IORef`.
>> > 2. A version that works with record types (not just pairs) whose first
>> > field is the new value to install in the `IORef`. This uses
>> > implementation details of the `atomicModifyMutVar#` primop as well as
>> > GHC's heap object layout to achieve better performance.
>> >
>> > Please try it out and let me know how it goes, and what extras you may
>> want!
>> >
>> > Hackage:
>> https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20230310/35dbad92/attachment.html>

From allbery.b at gmail.com  Fri Mar 10 14:12:28 2023
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 10 Mar 2023 09:12:28 -0500
Subject: [Haskell-cafe] ANN: atomic-modify-general
In-Reply-To: <CAMgWh9v7gaDmqJ+MaU3=qR-C5OoU7z7bP-3ju3TF7niXuku2aw@mail.gmail.com>
References: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>
 <eb51d6a0-3eb8-d539-b563-3e4453f8be58@tomsmeding.com>
 <CAMgWh9svyCMosmMU0-esPVRfqoKKVz0wmm_KuM3t_8c6v77-pA@mail.gmail.com>
 <50fdf76d-436e-abd9-5b5e-ecd0977e36b9@tomsmeding.com>
 <CAMgWh9v7gaDmqJ+MaU3=qR-C5OoU7z7bP-3ju3TF7niXuku2aw@mail.gmail.com>
Message-ID: <CAKFCL4W4GHW=62+B4tP0qaqvhwkwkdq5uCFLFVrhJbtKXGaizw@mail.gmail.com>

I expect it also can't know if the first field got unpacked. (or will
be unpacked? I think that hasn't happened at typechecking time)

On Fri, Mar 10, 2023 at 9:06 AM David Feuer <david.feuer at gmail.com> wrote:
>
> Unfortunately not. The type the type checker is told for the `atomicModifyMutVar2#` primop is a lie (too permissive). The type documented in its Haddocks is also a lie (too restrictive). Its most precise type, as I understand it, is (translating away the unboxed stuff and the internal I/O representation)
>
> atomicModifyMutVar2
>   :: IORef a
>   -> (a -> t)
>   -> IO (a, t)
> -- with the condition that `t` is a record whose first field that is represented by a pointer (what we call BoxedRep) has a type with the same memory representation as `a`.
>
> While it would be possible to express that fairly precisely using the Generics approach, I think it's too hard to think about "the first pointer field", and the "same memory representation" bit mucks with type inference. So I restricted it a little to "the first field, which must be a pointer", and "with type `a`".
>
> There's a sort of "hidden unsafeCoerce" in the primop call, where we know that the "selector thunk" it builds (a thunk applying a record selector, in this case fst) will extract the field we want out of what we give it. The type checker is clueless and just accepts whatever.
>
>
> On Fri, Mar 10, 2023, 4:09 AM Tom Smeding <x at tomsmeding.com> wrote:
>>
>> I'm not the person to ask :) Maybe someone else on the list can chip in here.
>>
>> Another question if you don't mind (I'm learning here): you say below that in atomicModifyIORef2Native, you rely on heap object layout to unsafeCoerce between a pair and any object with an interesting value in the first field. But looking at the source [1], it seems you only do this for base < 4.13, i.e. GHC < 8.8.4. That's been a while.
>>
>> Is it true that for GHCs since 8.8.4 you can just use a primop to do what you want directly, without the magic Generic stuff? If so, perhaps you can even drop the Generic constraints for high enough GHC versions (by extending the scope of the CPP slightly)? 8.6.5 is still popular, but simultaneously a whole bunch of applications don't care about GHCs <9 anymore.
>>
>> - Tom
>>
>> [1]: https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0/docs/src/Data.IORef.AtomicModify.Generic.html#atomicModifyIORef2Native
>>
>> On 10/03/2023 09:45, David Feuer wrote:
>>
>> Whoops! Thanks for pointing that out. I'll fix it and push new docs. There's not much magic in that part of the code itself; the nasty magic is knowing that the first pointer in any record is in the same position in its heap object as the first component of a pair. Speaking of which, do you have any idea if it'll work for non-record types whose constructors all have the same first field? I'm guessing yes, but I haven't experimented yet.
>>
>> On Fri, Mar 10, 2023, 3:27 AM Tom Smeding <x at tomsmeding.com> wrote:
>>>
>>> Hi David,
>>>
>>> Fancy stuffs!
>>>
>>> Wondering how much magic was going on in implementing this, I saw that
>>> atomicModifyIORef2Native misses the haddock marker '|' in the source;
>>> thus your extensive doc comment doesn't show up on hackage.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On 10/03/2023 03:01, David Feuer wrote:
>>> > I just put together a new package, atomic-modify-general, for
>>> > generalizations of the `atomicModifyIORef` operation. In particular:
>>> >
>>> > 1. Versions that allow a result of an arbitrary type (not necessarily
>>> > a pair), where the caller passes in an extraction function. These work
>>> > with `Array` and `SmallArray` from `primitive` as well as `IORef`.
>>> > 2. A version that works with record types (not just pairs) whose first
>>> > field is the new value to install in the `IORef`. This uses
>>> > implementation details of the `atomicModifyMutVar#` primop as well as
>>> > GHC's heap object layout to achieve better performance.
>>> >
>>> > Please try it out and let me know how it goes, and what extras you may want!
>>> >
>>> > Hackage: https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0
>>> > _______________________________________________
>>> > Haskell-Cafe mailing list
>>> > To (un)subscribe, modify options or view archives go to:
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> > Only members subscribed via the mailman list are allowed to post.
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From x at tomsmeding.com  Fri Mar 10 14:15:04 2023
From: x at tomsmeding.com (Tom Smeding)
Date: Fri, 10 Mar 2023 15:15:04 +0100
Subject: [Haskell-cafe] ANN: atomic-modify-general
In-Reply-To: <CAMgWh9v7gaDmqJ+MaU3=qR-C5OoU7z7bP-3ju3TF7niXuku2aw@mail.gmail.com>
References: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>
 <eb51d6a0-3eb8-d539-b563-3e4453f8be58@tomsmeding.com>
 <CAMgWh9svyCMosmMU0-esPVRfqoKKVz0wmm_KuM3t_8c6v77-pA@mail.gmail.com>
 <50fdf76d-436e-abd9-5b5e-ecd0977e36b9@tomsmeding.com>
 <CAMgWh9v7gaDmqJ+MaU3=qR-C5OoU7z7bP-3ju3TF7niXuku2aw@mail.gmail.com>
Message-ID: <8d69cce2-59d6-4d8d-5c71-571ca4f50208@tomsmeding.com>

Ooh, that's decidedly nasty. I suppose I should have read the docs of 
the primop before drawing conclusions, but then, being lazy is part of 
the deal here... ;)

Thanks for the explanation!

- Tom

On 10/03/2023 15:05, David Feuer wrote:
> Unfortunately not. The type the type checker is told for the 
> `atomicModifyMutVar2#` primop is a lie (too permissive). The type 
> documented in its Haddocks is also a lie (too restrictive). Its most 
> precise type, as I understand it, is (translating away the unboxed 
> stuff and the internal I/O representation)
>
> atomicModifyMutVar2
>   :: IORef a
>   -> (a -> t)
>   -> IO (a, t)
> -- with the condition that `t` is a record whose first field that is 
> represented by a pointer (what we call BoxedRep) has a type with the 
> same memory representation as `a`.
>
> While it would be possible to express that fairly precisely using the 
> Generics approach, I think it's too hard to think about "the first 
> pointer field", and the "same memory representation" bit mucks with 
> type inference. So I restricted it a little to "the first field, which 
> must be a pointer", and "with type `a`".
>
> There's a sort of "hidden unsafeCoerce" in the primop call, where we 
> know that the "selector thunk" it builds (a thunk applying a record 
> selector, in this case fst) will extract the field we want out of what 
> we give it. The type checker is clueless and just accepts whatever.
>
>
> On Fri, Mar 10, 2023, 4:09 AM Tom Smeding <x at tomsmeding.com> wrote:
>
>     I'm not the person to ask :) Maybe someone else on the list can
>     chip in here.
>
>     Another question if you don't mind (I'm learning here): you say
>     below that in atomicModifyIORef2Native, you rely on heap object
>     layout to unsafeCoerce between a pair and any object with an
>     interesting value in the first field. But looking at the source
>     [1], it seems you only do this for base < 4.13, i.e. GHC < 8.8.4.
>     That's been a while.
>
>     Is it true that for GHCs since 8.8.4 you can just use a primop to
>     do what you want directly, without the magic Generic stuff? If so,
>     perhaps you can even drop the Generic constraints for high enough
>     GHC versions (by extending the scope of the CPP slightly)? 8.6.5
>     is still popular, but simultaneously a whole bunch of applications
>     don't care about GHCs <9 anymore.
>
>     - Tom
>
>     [1]:
>     https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0/docs/src/Data.IORef.AtomicModify.Generic.html#atomicModifyIORef2Native
>
>     On 10/03/2023 09:45, David Feuer wrote:
>>     Whoops! Thanks for pointing that out. I'll fix it and push new
>>     docs. There's not much magic in that part of the code itself; the
>>     nasty magic is knowing that the first pointer in any record is in
>>     the same position in its heap object as the first component of a
>>     pair. Speaking of which, do you have any idea if it'll work for
>>     non-record types whose constructors all have the same first
>>     field? I'm guessing yes, but I haven't experimented yet.
>>
>>     On Fri, Mar 10, 2023, 3:27 AM Tom Smeding <x at tomsmeding.com> wrote:
>>
>>         Hi David,
>>
>>         Fancy stuffs!
>>
>>         Wondering how much magic was going on in implementing this, I
>>         saw that
>>         atomicModifyIORef2Native misses the haddock marker '|' in the
>>         source;
>>         thus your extensive doc comment doesn't show up on hackage.
>>
>>         Cheers,
>>         Tom
>>
>>         On 10/03/2023 03:01, David Feuer wrote:
>>         > I just put together a new package, atomic-modify-general, for
>>         > generalizations of the `atomicModifyIORef` operation. In
>>         particular:
>>         >
>>         > 1. Versions that allow a result of an arbitrary type (not
>>         necessarily
>>         > a pair), where the caller passes in an extraction function.
>>         These work
>>         > with `Array` and `SmallArray` from `primitive` as well as
>>         `IORef`.
>>         > 2. A version that works with record types (not just pairs)
>>         whose first
>>         > field is the new value to install in the `IORef`. This uses
>>         > implementation details of the `atomicModifyMutVar#` primop
>>         as well as
>>         > GHC's heap object layout to achieve better performance.
>>         >
>>         > Please try it out and let me know how it goes, and what
>>         extras you may want!
>>         >
>>         > Hackage:
>>         https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0
>>         > _______________________________________________
>>         > Haskell-Cafe mailing list
>>         > To (un)subscribe, modify options or view archives go to:
>>         > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>         > Only members subscribed via the mailman list are allowed to
>>         post.
>>
>>         _______________________________________________
>>         Haskell-Cafe mailing list
>>         To (un)subscribe, modify options or view 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/20230310/5abb0621/attachment.html>

From david.feuer at gmail.com  Fri Mar 10 14:48:32 2023
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 10 Mar 2023 09:48:32 -0500
Subject: [Haskell-cafe] ANN: atomic-modify-general
In-Reply-To: <CAKFCL4W4GHW=62+B4tP0qaqvhwkwkdq5uCFLFVrhJbtKXGaizw@mail.gmail.com>
References: <CAMgWh9se+9Z1Fk6brpvLYvD_FYs3gMZ7MExvwbzX0Gvi8hft6A@mail.gmail.com>
 <eb51d6a0-3eb8-d539-b563-3e4453f8be58@tomsmeding.com>
 <CAMgWh9svyCMosmMU0-esPVRfqoKKVz0wmm_KuM3t_8c6v77-pA@mail.gmail.com>
 <50fdf76d-436e-abd9-5b5e-ecd0977e36b9@tomsmeding.com>
 <CAMgWh9v7gaDmqJ+MaU3=qR-C5OoU7z7bP-3ju3TF7niXuku2aw@mail.gmail.com>
 <CAKFCL4W4GHW=62+B4tP0qaqvhwkwkdq5uCFLFVrhJbtKXGaizw@mail.gmail.com>
Message-ID: <CAMgWh9s6SJEYhg0H2KxhBhmGdkbdAvRgVZ+-3_wGwy69wv8Hhw@mail.gmail.com>

You're right that the type checker doesn't know that about the primop, but
it *is* known at type checking time, so my little package makes sure it's
not unpacked. It's's available in the Generic metadata as
DecidedStrictness, which will be 'DecidedUnpack for a field that is
actually unpacked, and that can be inspected by a type family or class
instance.

On Fri, Mar 10, 2023, 9:12 AM Brandon Allbery <allbery.b at gmail.com> wrote:

> I expect it also can't know if the first field got unpacked. (or will
> be unpacked? I think that hasn't happened at typechecking time)
>
> On Fri, Mar 10, 2023 at 9:06 AM David Feuer <david.feuer at gmail.com> wrote:
> >
> > Unfortunately not. The type the type checker is told for the
> `atomicModifyMutVar2#` primop is a lie (too permissive). The type
> documented in its Haddocks is also a lie (too restrictive). Its most
> precise type, as I understand it, is (translating away the unboxed stuff
> and the internal I/O representation)
> >
> > atomicModifyMutVar2
> >   :: IORef a
> >   -> (a -> t)
> >   -> IO (a, t)
> > -- with the condition that `t` is a record whose first field that is
> represented by a pointer (what we call BoxedRep) has a type with the same
> memory representation as `a`.
> >
> > While it would be possible to express that fairly precisely using the
> Generics approach, I think it's too hard to think about "the first pointer
> field", and the "same memory representation" bit mucks with type inference.
> So I restricted it a little to "the first field, which must be a pointer",
> and "with type `a`".
> >
> > There's a sort of "hidden unsafeCoerce" in the primop call, where we
> know that the "selector thunk" it builds (a thunk applying a record
> selector, in this case fst) will extract the field we want out of what we
> give it. The type checker is clueless and just accepts whatever.
> >
> >
> > On Fri, Mar 10, 2023, 4:09 AM Tom Smeding <x at tomsmeding.com> wrote:
> >>
> >> I'm not the person to ask :) Maybe someone else on the list can chip in
> here.
> >>
> >> Another question if you don't mind (I'm learning here): you say below
> that in atomicModifyIORef2Native, you rely on heap object layout to
> unsafeCoerce between a pair and any object with an interesting value in the
> first field. But looking at the source [1], it seems you only do this for
> base < 4.13, i.e. GHC < 8.8.4. That's been a while.
> >>
> >> Is it true that for GHCs since 8.8.4 you can just use a primop to do
> what you want directly, without the magic Generic stuff? If so, perhaps you
> can even drop the Generic constraints for high enough GHC versions (by
> extending the scope of the CPP slightly)? 8.6.5 is still popular, but
> simultaneously a whole bunch of applications don't care about GHCs <9
> anymore.
> >>
> >> - Tom
> >>
> >> [1]:
> https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0/docs/src/Data.IORef.AtomicModify.Generic.html#atomicModifyIORef2Native
> >>
> >> On 10/03/2023 09:45, David Feuer wrote:
> >>
> >> Whoops! Thanks for pointing that out. I'll fix it and push new docs.
> There's not much magic in that part of the code itself; the nasty magic is
> knowing that the first pointer in any record is in the same position in its
> heap object as the first component of a pair. Speaking of which, do you
> have any idea if it'll work for non-record types whose constructors all
> have the same first field? I'm guessing yes, but I haven't experimented yet.
> >>
> >> On Fri, Mar 10, 2023, 3:27 AM Tom Smeding <x at tomsmeding.com> wrote:
> >>>
> >>> Hi David,
> >>>
> >>> Fancy stuffs!
> >>>
> >>> Wondering how much magic was going on in implementing this, I saw that
> >>> atomicModifyIORef2Native misses the haddock marker '|' in the source;
> >>> thus your extensive doc comment doesn't show up on hackage.
> >>>
> >>> Cheers,
> >>> Tom
> >>>
> >>> On 10/03/2023 03:01, David Feuer wrote:
> >>> > I just put together a new package, atomic-modify-general, for
> >>> > generalizations of the `atomicModifyIORef` operation. In particular:
> >>> >
> >>> > 1. Versions that allow a result of an arbitrary type (not necessarily
> >>> > a pair), where the caller passes in an extraction function. These
> work
> >>> > with `Array` and `SmallArray` from `primitive` as well as `IORef`.
> >>> > 2. A version that works with record types (not just pairs) whose
> first
> >>> > field is the new value to install in the `IORef`. This uses
> >>> > implementation details of the `atomicModifyMutVar#` primop as well as
> >>> > GHC's heap object layout to achieve better performance.
> >>> >
> >>> > Please try it out and let me know how it goes, and what extras you
> may want!
> >>> >
> >>> > Hackage:
> https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0
> >>> > _______________________________________________
> >>> > Haskell-Cafe mailing list
> >>> > To (un)subscribe, modify options or view archives go to:
> >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>> > Only members subscribed via the mailman list are allowed to post.
> >>>
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> To (un)subscribe, modify options or view archives go to:
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>> Only members subscribed via the mailman list are allowed to post.
> >>
> >>
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230310/eb9ed179/attachment.html>

From simon at joyful.com  Fri Mar 10 22:42:51 2023
From: simon at joyful.com (Simon Michael)
Date: Fri, 10 Mar 2023 12:42:51 -1000
Subject: [Haskell-cafe] ANN: Haskell Tiny Game Jam 2023 Results
Message-ID: <1388EFCC-4E1A-4065-AE12-5C66DB85918F@joyful.com>

We are very pleased to announce.. the results of Haskell Tiny Game Jam 2023 !
Congratulations and thanks to all participants!

- 55 entries in 4 categories from 28 entrants in 3 weeks
- 109 reviews, 5 winners and 6 honourable mentions from 2 judges
- Shell script to browse and play the games on all major platforms (single binary coming later maybe)
- Readable source versions, useful development tips, informative blog posts

This was the first Haskell game dev contest.
The prize.. glory! Also fun, learning, and advancing Haskell's suitability for game dev and programming in the small.
We invite you to come and play, read, and get inspired for the next one!

https://github.com/haskell-game/tiny-games-hs


From simon at joyful.com  Sun Mar 12 00:18:44 2023
From: simon at joyful.com (Simon Michael)
Date: Sat, 11 Mar 2023 14:18:44 -1000
Subject: [Haskell-cafe] ANN: hledger-1.29
Message-ID: <B83BFF9F-DCE6-4273-95A2-A9F296848D6D@joyful.com>

I'm pleased to announce hledger 1.29 !

https://github.com/simonmichael/hledger/releases/1.29
https://hledger.org/install
https://hledger.org/release-notes.html#hledger-1-29

Highlights:

Tag checking, 
flexible multi-period start dates, 
flexible cost/conversion posting combining,
new commands list,
hledger manual reorg,
easier close command,
10% more Ledger file compatible.

Thank you to release contributors Chris Lemaire, Caleb Maclennan,
Jonathan Dowland, J. B. Rainsberger, Michael Grünewald, Robert Nielsen,
and Yann Büchau.

What is hledger ?

- Fast, reliable, free, multicurrency, double-entry, plain text
  accounting[1] software that runs on unix, mac, windows, and the web

- Built around human-readable, version-controllable plain text files

- Inspired by and largely compatible with Ledger CLI[2];
  convertible to and from Beancount[3]

- Written in Haskell for correctness and longevity.

For help getting started, or more info, see https://hledger.org
and join our chat via Matrix or IRC: https://hledger.org/support
Newcomers, experts, contributors, sponsors, feedback are welcome!

Aloha,
-Simon


[1] https://plaintextaccounting.org
[2] https://ledger-cli.org
[3] https://beancount.github.io

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

From ben at well-typed.com  Sun Mar 12 02:14:12 2023
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 11 Mar 2023 21:14:12 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1 is now available
Message-ID: <87edpupvhh.fsf@smart-cactus.org>


The GHC team is very pleased to announce the availability of GHC 9.6.1.
As usual, binaries and source distributions are available at
downloads.haskell.org:

    https://downloads.haskell.org/ghc/9.6.1/

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to
WebAssembly and JavaScript. This is an important step towards robust
support for compiling Haskell to the Web, but there are a few caveats to be
aware of in the 9.6 series:

 - Both the Javascript and WebAssembly backends are still at an early
   stage of development and are present in this release as a technology preview

 - Using GHC as a cross-compiler is not as easy as we would like it to
   be; in particular, there are challenges related to Template Haskell

 - GHC is not yet run-time retargetable; a given GHC binary targets
   exactly one platform, and both WebAssembly and JavaScript are considered
   platforms for this purpose. Cross-compilers must be built from source by
   their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 includes:

 - Significant latency improvements in the non-moving garbage collector

 - Efficient runtime support for delimited continuations

 - Improvements in compiler error messages

 - Numerous improvements in the compiler's memory usage

See the [release notes] for a comprehensive accounting of changes in this
release.

As always, one can find a migration guide to aid in transitioning from older
releases on the [GHC Wiki][migration-guide]. We have also recently started
extending our release process to cover a wider set of Linux distributions. In
particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which
cover RedHat-derivative and distributions using older glibc releases
(namely 2.27), respectively.

Thanks to everyone who has contributed code, documentation, testing, and
tickets to this release process. As this release represents upstream GHC's
first step towards supporting web targets, we are very excited to have this
release out the door!

Cheers,

- Ben


[ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
[migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6
[release notes]: https://downloads.haskell.org/ghc/9.6.1/docs/users_guide/9.6.1-notes.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 905 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230311/b1df7409/attachment.sig>

From ietf-dane at dukhovni.org  Sun Mar 12 21:23:47 2023
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 12 Mar 2023 17:23:47 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1 is now available
In-Reply-To: <87edpupvhh.fsf@smart-cactus.org>
References: <87edpupvhh.fsf@smart-cactus.org>
Message-ID: <ZA5C4/OqgN5DQVop@straasha.imrryr.org>

On Sat, Mar 11, 2023 at 09:14:12PM -0500, Ben Gamari wrote:

> The GHC team is very pleased to announce the availability of GHC 9.6.1.
> As usual, binaries and source distributions are available at
> downloads.haskell.org:
> 
>     https://downloads.haskell.org/ghc/9.6.1/

Is anyone else having trouble building 9.6.1 from upstream source.

    a58c028a18 (HEAD -> ghc-9.6, tag: ghc-9.6.1-release, origin/ghc-9.6) Fix TBA in base changelog
    1f5bce0db8 Set RELEASE=YES
    87ab8e353f Bump haddock submodule to 2.28
    ...

My attempts on a Fedora 36 system are so far unsuccessful, with both GCC
and Clang-14 as the C compilers, and GHC 9.4.4 as the bootstrap GHC.

The build fails when "HsBase.h" is not found during the "stage1" build
of the ghc-bignum library.

-- 
    Viktor.

From mikolaj at well-typed.com  Mon Mar 13 10:53:45 2023
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 13 Mar 2023 11:53:45 +0100
Subject: [Haskell-cafe] Just released: cabal 3.10.1.0
Message-ID: <CAHFo2uox+JpKEc89EXUBwM0U_w3eWc=vRmoDv54sgU+2E-8H8g@mail.gmail.com>

Dear cabal users and contributors,

The cabal team is proud to announce the release of cabal 3.10.1.0.
This is mainly a bugfix release, but it has some new features and
enhancements as well. The thread about the release, including
troubleshooting and porting discussions, is at

https://discourse.haskell.org/t/just-released-cabal-3-10-1-0/5978

The changelogs and release notes are at

https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.10.1.0.md

and, if your code depends on the Cabal library, at

https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.10.1.0.md

Two backward (in)compatibility notes may be of particular interest:
the XDG Base Directory Specification (conditionally) replacing
~/.cabal and the `--enable-documentation` option by default added to
all `cabal haddock` invocations. Please look them up at the links
above.

Let me finish by thanking our esteemed benefactors, past and present,
contributing code, devops, testing, feedback, comments. Representing
these are the authors of all PRs included in the 3.10.1.0 release,
honourably mentioned in the list of fame below.

Abastro
Alexander Biehl
Alexey Radkov
amigalemming
Andrea Bedini
Andreas Abel
Andreas Klebinger
Artem Pelenitsyn
Ben Gamari
Bodigrim
Brandon Chinn
Bryan Richter
Byron Johnson
Cheng Shao
chowells79
Cmdv
Colton Clemmer
cydparser
Daniel Gröber
deltaspace0
Evgenii Akentev
fendor
Francesco Ariis
Francesco Gazzetta
Gautier DI FOLCO
Georgi Lyubenov
Gershom Bazerman
Guillaume Genestier
Hécate Moonlight
Ikko Ashimine
instinctive
Jade Lovelace
James Hobson
Jan Synáček
Jappie Klooster
Javier Neira
John Ericson
Kobayashi
Marcin Szamotulski
Martijn Bastiaan
Matthew Pickering
Max Amanshauser
Miezhiko
Mike Pilgrem
Musab Guma'a
Patrick Dougherty
Paweł Dybiec
Pierre Le Marre
Robert Vollmert
Ross Paterson
Saad Ahmed
Sergey Vinokurov
sheaf
Sören Tempel
Sylvain Henry
Tom McLaughlin
Troels Henriksen
Vilius Panevėžys
Vladislav Zavialov
Wismill

From olf at aatal-apotheke.de  Tue Mar 14 21:03:47 2023
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Tue, 14 Mar 2023 22:03:47 +0100
Subject: [Haskell-cafe] dynamic web form generation for algebraic data
 types
Message-ID: <b4245b0542af3b45d63c0c889f7fc66e37746aa0.camel@aatal-apotheke.de>

> > From briefly reading the wiki page
> https://wiki.haskell.org/Tangible_Value, it looks like it relies on
> Applicative functors for combining values.
> So maybe the missing piece for sum-types was Selective functors
> https://hackage.haskell.org/package/selective?
> 
> Gustavo Bicalho
> 

Well spotted! I did not know selective applicative functors (SAFs),
thanks for mentioning! Indeed `branch` seems to be all that is
necessary to get forms for sum types going. In the talk [1] Andrey
mentions that SAFs have a bind, but only for enumerable inputs. 
The papers state that "all effects are declared statically". If we
equate "effect" with "form input" then for recursive types like lists
this would mean to pre-define an infinite number of fields and have the
user select a finite number of them. I wonder whether that is feasible
with html forms. 
Maybe forms (in the html sense) are a red herring for what I am after.
Both the Grace and tangible values demos immediately process changes to
inputs, there is no distinction between inputting the data and having
the data processed: they are event-driven systems. As is JavaScript
with its `oninput` and `onchange` functions. 
So there are two sub-problems here: The first problem is to
programmatically generate html elements by JavaScript functions that
can build all finite values of a given Generic Haskell type, and
nothing else. The second problem is to scrape the thusly generated
elements and re-assemble them into a Haskell value on the server side.
The second problem is usually solved by html forms, but there may be
other means. 

Olaf

[1] https://dl.acm.org/doi/abs/10.1145/3341694#




From Graham.Hutton at nottingham.ac.uk  Thu Mar 16 08:45:14 2023
From: Graham.Hutton at nottingham.ac.uk (Graham Hutton)
Date: Thu, 16 Mar 2023 08:45:14 +0000
Subject: [Haskell-cafe] Call for Papers,
	Functional Software Architecture - FP in the Large
Message-ID: <8C0E688B-F17D-4DA6-B691-988FB0CB840A@nottingham.ac.uk>

Dear all,

We're delighted to announce that the first ACM SIGPLAN Workshop on
"Functional Software Architecture - FP in the Large" will be held
in Seattle, USA in September 2023, co-located with the ICFP conference.

Please share, and submit your best papers, experience reports, and
architectural pearls on large-scale functional programming!

Best wishes,

Mike Sperber and Graham Hutton
Program Chairs, FUNARCH 2023


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

               *** FUNARCH 2023 -- CALL FOR PAPERS ***

                  The First ACM SIGPLAN Workshop on
         Functional Software Architecture - FP in the Large

            8th September 2023, Seattle, Washington, USA
                      Co-located with ICFP 2023

                    https://tinyurl.com/FUNARCH23

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

TIMELINE:

Paper submission	1st June 2023
Author notification	28th June 2023
Camera ready copy	18th July 2023
Workshop		8th Sept 2023 (date to be confirmed)

BACKGROUND:

"Functional Software Architecture" refers to methods of construction
and structure of large and long-lived software projects that are
implemented in functional languages and released to real users,
typically in industry.  The goals for the workshop are:

- To assemble a community interested in software architecture
  techniques and technologies specific to functional programming;

- To identify, categorize, and document topics relevant to
  the field of functional software architecture;

- To connect the functional programming community to the software
  architecture community to cross-pollinate between the two.

The workshop follows on from the Functional Software Architecture
open space that was held at ICFP 2022 in Slovenia.

SCOPE:

The workshop seeks submissions in a range of categories:

- You're a member of the FP community and have thought about how
  to support programming in the large, for example by framing
  functional ideas in architectural terms or vice verse, comparing
  different languages in terms of their architectural capabilities,
  clarifying architectural roles played by formal methods, proof
  assistants and DSLs, or observing how functional concepts are
  used in other language and architecture communities.

  Great, submit a research paper!

- You're a member of the architecture community, and have thought
  about how your discipline might help functional programmers, for
  example by applying domain-driven design, implementing hexagonal
  architecture, or designing self-contained systems.

  Excellent, submit a research paper!

- You've worked on a large project using functional programming,
  and it's worked out well, or terribly, or a mix of both; bonus
  points for deriving architectural principles from your experience.

  Wonderful, submit an experience report!

- You know a neat architectural idiom or pattern that may be useful
  to others developing large functional software systems.

  Fabulous, submit an architectural pearl!

- You have something that doesn't fit the above categories, but
  that still relates to functional software architecture, such 
  as something that can be written up, or that could be part of
  the workshop format like a panel debate or a fishbowl.

  Superb, submit to the open category!

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

Experience reports and architectural pearls need not necessarily
report original research results.  The key criterion for such papers
is that they make a contribution from which others can benefit.
It is not enough simply to describe a large software system, or
to present ideas that are specific to a particular system.

Open category submissions that are not intended for publication 
are not required to follow the formatting guidelines, and can 
submit in PDF, word or plain text format as preferred.

If you are unsure whether your contribution is suitable, or if
you need any kind of help with your submission, please email
the program chairs at <funarch2023 at easychair.org>.

SUBMISSION:

Papers must be submitted by 1st June 2023 using EasyChair, via the
following link: https://tinyurl.com/FUNARCH23-submit

Formatting: submissions intended for publication must be in PDF
format and follow the ACM SIGPLAN style guidelines, using the
acmart format and the sigplan sub-format.  Please use the review
option, as this enables line numbers for easy reference in reviews.
For further details, see: https://tinyurl.com/sigplan-acmart

If your submission is not a research paper, please mark this using
a subtitle (Experience Report, Architectural Pearl, Open Category).

Length: submissions must adhere to the limits specified below.
However, there is no requirement or expectation that all pages
are used, and authors are encouraged to strive for brevity.

Research papers		5 to 12+ pages
Architectural pearls	5 to 12 pages
Experience reports	3 to 6 pages
Open category		1 to 6 pages

Publication: The proceedings of FUNARCH 2023 will be published in
the ACM Digital Library, and authors of accepted papers are required
to agree to one of the standard ACM licensing options.  Accepted
papers must be presented at the workshop by one of the authors,
but in special cases we may consider remote presentation. 

The official publication date is the date the proceedings are
made available in the ACM Digital Library.  This date may be up
to two weeks prior to the first day of the workshop.

PROGRAM CHAIRS:

Mike Sperber 		Active Group, Germany
Graham Hutton 		University of Nottingham, UK

PROGRAM COMMITTEE:

Joachim Breitner	Germany
Manuel Chakravarty	Tweak & IOG, The Netherlands
Ron Garcia		University of British Columbia, Canada
Debasish Ghosh		LeadIQ, India
Lars Hupel		Giesecke+Devrient, Germany
Andy Keep		Meta, USA
Shriram Krishnamurthi	Brown University, USA
Andres Löh		Well-Typed, Germany
Anil Madhavapeddy	University of Cambridge, UK
José Pedro Magalhães	Standard Chartered, UK
Simon Marlow		Meta, UK
Hannes Mehnert		Robur, Germany
Erik Meijer		USA
Ivan Perez		KBR / NASA Ames Research Center, USA
Stefanie Schirmer	DuckDuckGo, Germany
Perdita Stevens		University of Edinburgh, UK
Stefan Wehr		Hochschule Offenburg, Germany
Scott Wlaschin		FPbridge, UK

WORKSHOP VENUE:

The workshop will be co-located with the ICFP 2023 conference at
The Westin Seattle Hotel, Seattle, Washington, United States.

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





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.





From W.S.Swierstra at uu.nl  Thu Mar 16 10:47:56 2023
From: W.S.Swierstra at uu.nl (Swierstra, W.S. (Wouter))
Date: Thu, 16 Mar 2023 10:47:56 +0000
Subject: [Haskell-cafe] Utrecht Summer School on Advanced Functional
	Programming 2023
Message-ID: <c51f5d02-068b-46ec-5c41-bc97f36d2771@uu.nl>


# Call for Participation

   SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING

     Utrecht, the Netherlands, 03 July – 07 July 2023

   http://www.afp.school

**Please register before June 15th **

## ABOUT

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

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

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

The summer school will be held in Utrecht and consists of a mix of
lectures, labs, and a busy social program.

## PREREQUISITES

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

## DATES

**Registration deadline: June 15th, 2023**
School: 03 July – 07 July 2023

## COSTS

   750 euro - Profession registration fee
   250 euro - Student registration fee
   200 euro - Housing fee

We will charge a registration fee of 750 euros (or 250 euros for
students) to cover our expenses. If this is problematic for you for
any reason at all, please email the organisers and we can try to offer
you a discounted rate or a fee waiver. We have a limited number of
scholarships or discounts available for students that would not be
able to attend otherwise, especially for women and under-represented
minorities.

## FURTHER INFORMATION

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

   http://www.afp.school

From professional at brechtserckx.be  Thu Mar 16 21:42:02 2023
From: professional at brechtserckx.be (Brecht Serckx)
Date: Thu, 16 Mar 2023 21:42:02 +0000
Subject: [Haskell-cafe] Package takeover: OpenSCAD
Message-ID: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>

Hi all,

I would like to take over the OpenSCAD[1] package, of which I believe the maintainer is no longer active.
The maintainer hasn't replied to my ticket[2] on the issue tracker or to an email to the listed email-address for over a year.
On my fork[3] I have implemented multiple bugfixes and features already, and I have some ideas for future improvements.

Best regards,

Brecht

[1] https://hackage.haskell.org/package/OpenSCAD
[2] https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
[3] https://github.com/BrechtSerckx/OpenSCAD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230316/299e0d68/attachment.html>

From twilson at csufresno.edu  Fri Mar 17 01:33:27 2023
From: twilson at csufresno.edu (Todd Wilson)
Date: Thu, 16 Mar 2023 18:33:27 -0700
Subject: [Haskell-cafe] Basic list exercise
Message-ID: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>

Dear Cafe,

Here's a basic exercise in list processing: define a function

runs :: Ord a => [a] -> [[a]]

that breaks up its input list into a list of increasing "runs"; e.g.,

runs [3,4,5,6,2,3,4,1,2,1]  --->  [[3,4,5,6],[2,3,4],[1,2],[1]]

A natural solution is the following:

runs [] = []
runs (x:xs) = let (ys, zs) = run x xs
              in (x:ys) : runs zs
  where
    run x [] = ([], [])
    run x (y:ys) = if x <= y
                   then let (us, vs) = run y ys
                        in (y:us, vs)
                   else ([], y:ys)

My question: can we do better than this? It seems that this solution is
constantly building and breaking apart pairs. (Or is it, when optimized?)

Todd Wilson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230316/2c5dd128/attachment.html>

From zemyla at gmail.com  Fri Mar 17 01:38:36 2023
From: zemyla at gmail.com (Zemyla)
Date: Thu, 16 Mar 2023 20:38:36 -0500
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
Message-ID: <CAK7nUjgP_xjgRXSTQ1VeRYC_V3cMCbBAj-Mj4ufoLsS4G0qD3A@mail.gmail.com>

If you use a case statement instead of a let statement in the recursive
case, then GHC will know the pairs are being made and immediately taken
apart, and will optimize it to use unboxed pairs internally.

On Thu, Mar 16, 2023, 20:33 Todd Wilson <twilson at csufresno.edu> wrote:

> Dear Cafe,
>
> Here's a basic exercise in list processing: define a function
>
> runs :: Ord a => [a] -> [[a]]
>
> that breaks up its input list into a list of increasing "runs"; e.g.,
>
> runs [3,4,5,6,2,3,4,1,2,1]  --->  [[3,4,5,6],[2,3,4],[1,2],[1]]
>
> A natural solution is the following:
>
> runs [] = []
> runs (x:xs) = let (ys, zs) = run x xs
>               in (x:ys) : runs zs
>   where
>     run x [] = ([], [])
>     run x (y:ys) = if x <= y
>                    then let (us, vs) = run y ys
>                         in (y:us, vs)
>                    else ([], y:ys)
>
> My question: can we do better than this? It seems that this solution is
> constantly building and breaking apart pairs. (Or is it, when optimized?)
>
> Todd Wilson
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230316/6b0a3806/attachment.html>

From twilson at csufresno.edu  Fri Mar 17 02:58:52 2023
From: twilson at csufresno.edu (Todd Wilson)
Date: Thu, 16 Mar 2023 19:58:52 -0700
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CAK7nUjgP_xjgRXSTQ1VeRYC_V3cMCbBAj-Mj4ufoLsS4G0qD3A@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
 <CAK7nUjgP_xjgRXSTQ1VeRYC_V3cMCbBAj-Mj4ufoLsS4G0qD3A@mail.gmail.com>
Message-ID: <CA+-99oJ0Pwbd93Co9f_6CPTgOgceAqhL=D85c0qtJgXXp3AZCg@mail.gmail.com>

By "using unboxed pairs", do you mean that Haskell optimizes this so that
it is equivalent somehow to the following Prolog version of my program?

runs([], []).
runs([X|Xs], [[X|Ys]|Rs]) :-
    run(X, Xs, Ys, Zs),
    runs(Zs, Rs).

run(_, [], [], []) :- !.
run(X, [Y|Ys], [Y|Us], Vs) :- X =< Y, !, run(Y, Ys, Us, Vs).
run(_, Ys, [], Ys).


Here, it is clear that, in the second clause for `runs`, computation is
happening on two fronts -- `Ys` and `Rs` -- and we can build the two conses
in the return value before we do the calls that fill in the missing
parts, so this ends up being a tail recursion. When the computation that
produces `Ys` finishes, the computation that produces `Rs` can resume.
Maybe this can best be explained functionally using continuations?

Todd Wilson

On Thu, Mar 16, 2023 at 6:38 PM Zemyla <zemyla at gmail.com> wrote:

> If you use a case statement instead of a let statement in the recursive
> case, then GHC will know the pairs are being made and immediately taken
> apart, and will optimize it to use unboxed pairs internally.
>
> On Thu, Mar 16, 2023, 20:33 Todd Wilson <twilson at csufresno.edu> wrote:
>
>> Dear Cafe,
>>
>> Here's a basic exercise in list processing: define a function
>>
>> runs :: Ord a => [a] -> [[a]]
>>
>> that breaks up its input list into a list of increasing "runs"; e.g.,
>>
>> runs [3,4,5,6,2,3,4,1,2,1]  --->  [[3,4,5,6],[2,3,4],[1,2],[1]]
>>
>> A natural solution is the following:
>>
>> runs [] = []
>> runs (x:xs) = let (ys, zs) = run x xs
>>               in (x:ys) : runs zs
>>   where
>>     run x [] = ([], [])
>>     run x (y:ys) = if x <= y
>>                    then let (us, vs) = run y ys
>>                         in (y:us, vs)
>>                    else ([], y:ys)
>>
>> My question: can we do better than this? It seems that this solution is
>> constantly building and breaking apart pairs. (Or is it, when optimized?)
>>
>> Todd Wilson
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20230316/67e2f71c/attachment.html>

From jclites at mac.com  Fri Mar 17 03:58:34 2023
From: jclites at mac.com (Jeff Clites)
Date: Thu, 16 Mar 2023 20:58:34 -0700
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
Message-ID: <91D66FD5-DF85-4A6A-B1F0-CE62BC91E30E@mac.com>

> It seems that this solution is constantly building and breaking apart pairs.

At first glance it seems fine. In order to pull a sublist off the front of a list you’ll need to build a new list for that part, so the disassemble/reassemble is necessary there.

You can use an “as pattern” to avoid re-creating `y:ys` in your else clause, but that’s somewhat minor. I don’t see anywhere else where you are pulling something apart and then recreating the same thing.

Regarding the other response, an unboxed pair is just an optimization whereby a pair of values can be returned from a function without actually allocating heap storage, but it’s just reducing memory allocation, nothing conceptually more fancy.

Jeff

> On Mar 16, 2023, at 6:34 PM, Todd Wilson <twilson at csufresno.edu> wrote:
> 
> 
> Dear Cafe,
> 
> Here's a basic exercise in list processing: define a function
> runs :: Ord a => [a] -> [[a]]
> that breaks up its input list into a list of increasing "runs"; e.g.,
> runs [3,4,5,6,2,3,4,1,2,1]  --->  [[3,4,5,6],[2,3,4],[1,2],[1]]
> A natural solution is the following:
> runs [] = []
> runs (x:xs) = let (ys, zs) = run x xs
>               in (x:ys) : runs zs
>   where
>     run x [] = ([], [])
>     run x (y:ys) = if x <= y
>                    then let (us, vs) = run y ys
>                         in (y:us, vs)
>                    else ([], y:ys)
> My question: can we do better than this? It seems that this solution is constantly building and breaking apart pairs. (Or is it, when optimized?)
> 
> Todd Wilson
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230316/a24f39f8/attachment.html>

From ietf-dane at dukhovni.org  Fri Mar 17 04:09:45 2023
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 17 Mar 2023 00:09:45 -0400
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
Message-ID: <ZBPoCcBkmAV0kAhQ@straasha.imrryr.org>

On Thu, Mar 16, 2023 at 06:33:27PM -0700, Todd Wilson wrote:

> Here's a basic exercise in list processing: define a function
> 
> runs :: Ord a => [a] -> [[a]]
> 
> that breaks up its input list into a list of increasing "runs"; e.g.,
> 
> runs [3,4,5,6,2,3,4,1,2,1]  --->  [[3,4,5,6],[2,3,4],[1,2],[1]]
> 
> A natural solution is the following:
> 
> runs [] = []
> runs (x:xs) = let (ys, zs) = run x xs
>               in (x:ys) : runs zs
>   where
>     run x [] = ([], [])
>     run x (y:ys) = if x <= y
>                    then let (us, vs) = run y ys
>                         in (y:us, vs)
>                    else ([], y:ys)
>
> My question: can we do better than this? It seems that this solution is
> constantly building and breaking apart pairs. (Or is it, when optimized?)

The key feature of this solution is that it is lazy in the tail of the
list of runs.  For example, the below completes quickly despite
ostensibly working with an infinite list of runs.  It is able to "emit"
the first run as soon as a successort is smaller than its predecessor.

    {-# LANGUAGE ScopedTypeVariables #-}
    module Main (main) where

    runs :: forall a. Ord a => [a] -> [[a]]
    runs [] = []
    runs (x:xs) = let (ys, zs) = run x xs
                  in (x:ys) : runs zs
      where
        run :: a -> [a] -> ([a], [a])
        run x [] = ([], [])
        run x l@(y:ys) = if x <= y
                       then let (us, vs) = run y ys
                            in (y:us, vs)
                       else ([], l)

    main :: IO ()
    main = print $ sum $ map sum $ take 100 $ runs $ concat $ map (\i -> [0..i]) [0..]

It is also able to generate the leading elements of an infinite first run:

    main :: IO ()
    main = print $ sum $ take 100 $ head $ runs $ [0..]

Any constant factors are less important.

-- 
    Viktor.

From jondrews at fastmail.com  Fri Mar 17 07:55:19 2023
From: jondrews at fastmail.com (Jonathan Drews)
Date: Fri, 17 Mar 2023 01:55:19 -0600
Subject: [Haskell-cafe] Emily Pillmore to talk about Haskell
Message-ID: <ZBQc5xjX/VqbTu+w@leo.my.domain>

Folks:

 On March 21st, at 7:00 Pm EDT, Emily Pillmore, The CTO of the Haskell
Foundation, will give a presentation on Haskell. The presentation is
online and hosted by http://www.semibug.org/. This online event will
be conducted through Jitsi. The Jitsi link will be posted here on 
Monday, March 20th. 

Please do tell your friends about this event as this is going to be a
great presentation on Haskel by one of its most consummate
practioners.

--
Kind regards,
Jonathan


From carter.schonwald at gmail.com  Sun Mar 19 02:41:52 2023
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 18 Mar 2023 22:41:52 -0400
Subject: [Haskell-cafe] Package takeover: OpenSCAD
In-Reply-To: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
References: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
Message-ID: <CAHYVw0wD0RAU80siZF+fFah3x7n-SELUS=tanMZvPRh=xVZUFQ@mail.gmail.com>

first start the process for a non-maintainer update, then after thats
happened can the take over process start :)

On Thu, Mar 16, 2023 at 5:43 PM Brecht Serckx <professional at brechtserckx.be>
wrote:

> Hi all,
>
> I would like to take over the OpenSCAD[1] package, of which I believe the
> maintainer is no longer active.
> The maintainer hasn't replied to my ticket[2] on the issue tracker or to
> an email to the listed email-address for over a year.
> On my fork[3] I have implemented multiple bugfixes and features already,
> and I have some ideas for future improvements.
>
> Best regards,
>
> Brecht
>
> [1] https://hackage.haskell.org/package/OpenSCAD
> [2]
> https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
> [3] https://github.com/BrechtSerckx/OpenSCAD
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230318/b357f4d4/attachment.html>

From gk at ninebynine.org  Sun Mar 19 12:39:12 2023
From: gk at ninebynine.org (Graham Klyne)
Date: Sun, 19 Mar 2023 12:39:12 +0000
Subject: [Haskell-cafe] CSG options for 3D printing (was: Package takeover:
	OpenSCAD)
In-Reply-To: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
References: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
Message-ID: <1094427d-9a95-78c3-ee81-29065afdbe09@ninebynine.org>

Hello Brecht,

This is interesting, in that it's the first I've heard of there being an 
OpenSCAD package for Haskell 😯.

I've been doing a fair bit of OpenSCAD design recently, and have frequently felt 
it would be nice express these constructs in Haskell or similar more fully 
featured functional source language.  A previous search uncovered Haskell CSG 
packages, but I didn't see anything suitable for generating 3D printing files.  
(A search just now discovered https://hackage.haskell.org/package/mecha, which 
also offers OpenSCAD output.)

I understand that one of the problems with OpenSCAD as a target language is that 
it only exports to STL files, with no primitive recognition of curved entities.  
I believe there are other 3D model representations (OBJ, 3MF?) that have 
primitives for curved elements, which in turn can be handled more smoothly by 
GCode generation software.

(For non-3D printing folks reading this: GCode being the low level "machine" 
code that drives most personal 3D printers).

Anyway, I've tagged your fork of OpenCSG and will aim to try it out sometime 
😀.   Thanks!

#g


On 16/03/2023 21:42, Brecht Serckx wrote:
> Hi all,
>
> I would like to take over the OpenSCAD[1] package, of which I believe the 
> maintainer is no longer active.
> The maintainer hasn't replied to my ticket[2] on the issue tracker or to an 
> email to the listed email-address for over a year.
> On my fork[3] I have implemented multiple bugfixes and features already, and I 
> have some ideas for future improvements.
>
> Best regards,
>
> Brecht
>
> [1] https://hackage.haskell.org/package/OpenSCAD
> [2] https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
> [3] https://github.com/BrechtSerckx/OpenSCAD
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-- 
Graham Klyne
mailto:gk at ninebynine.org
http://www.ninebynine.org
Mastodon: @gklyne at indieweb.social
GitHub/Skype: @gklyne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230319/6e14f1be/attachment.html>

From jondrews at fastmail.com  Mon Mar 20 06:17:37 2023
From: jondrews at fastmail.com (Jonathan Drews)
Date: Mon, 20 Mar 2023 00:17:37 -0600
Subject: [Haskell-cafe] Presentaion on Haskell by Emily Pillmore
Message-ID: <ZBf6gaO1vZX0F0pv@leo.my.domain>

Hello Folks:

 On 03/21/23, at 7:00 PM EDT, Emily Pillmore, former CTO of the Haskell
Foundation, will give a presentation on Haskell. She will cover the
rudiments of functional programming and an overview of CABAL (Common
Architecture for Building Applications and Libraries). The link is:

https://meet.jit.si/SEMI-BUGHaskellTalk

 Ms. Pillmore is a profesional programmer and has a degree in
Mathematics. She is a member of the Haskell Core Libraries team. She
is also a member of the Haskell.org committee

This is a great opportunity to get an overview of a pure functional
programming language.

--
Kind regards,
Jonathan
http://www.semibug.org/


From nikivazou at gmail.com  Tue Mar 21 11:19:16 2023
From: nikivazou at gmail.com (Niki Vazou)
Date: Tue, 21 Mar 2023 12:19:16 +0100
Subject: [Haskell-cafe] CfP: Haskell Symposium 2023
Message-ID: <CAG9wkeXCBTU9XzDiLfP6t=rDT52Lxc0TyOXRWUd4UPspH30wbw@mail.gmail.com>

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

                             Haskell Symposium 2023

                                Seattle, WA, USA
                         Fri 8 -- Sat 9 September, 2023

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

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

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

As with last year, Haskell'23 will use a single-track submission process. That
is, we will only have the regular track and no early track.

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

Topics of interest include:

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

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

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

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

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

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

  * Functional Pearls, being elegant and instructive programming examples;

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

  * Tutorials, to document how to use a particular language feature, programming
    technique, tool or library within the Haskell ecosystem;

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

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

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

Like an experience report and a functional pearl, tutorials should make a
contribution from which other Haskellers can benefit. What distinguishes a
tutorial is that its focus is on explaining an aspect of the Haskell language
and/or ecosystem in a way that is generally useful to a Haskell audience.
Tutorials for many such topics can be found online; the distinction here is that
by writing it up for formal review it will be vetted by experts and formally
published.

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

If your contribution is not a research paper, please mark the title of your
experience report, functional pearl, tutorial or system demonstration as such,
by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper,
System Demonstration).

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

Formatting
----------

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

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

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

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

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

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

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

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

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

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

The length of submissions should not exceed the following limits:

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

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

Deadlines
---------

Paper submission:        1 June 2023      (Thu)
Notification:            4 July 2023      (Tue)
Camera ready:           18 July 2023      (Tue)

Deadlines are anywhere on Earth.

Submission
----------

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

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

Papers should be submitted through HotCRP at:

  https://haskell23.hotcrp.com/

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

Supplementary material: Authors have the option to attach supplementary material
to a submission, on the understanding that reviewers may choose not to look at
it. This supplementary material should not be submitted as part of the main
document; instead, it should be uploaded as a separate PDF document or tarball.
Supplementary material should be uploaded at submission time, not by providing a
URL in the paper that points to an external repository. Authors can distinguish
between anonymised and non-anonymised supplementary material. Anonymised
supplementary material will be visible to reviewers immediately; non-anonymised
supplementary material will be revealed to reviewers only after they have
submitted their review of the paper and learned the identity of the author(s).

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

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

Accepted papers will be included in the ACM Digital Library. Their authors will
be required to choose one of the following options:

  - Author retains copyright of the work and grants ACM a non-exclusive
    permission-to-publish license (and, optionally, licenses the work with a
    Creative Commons license);

  - Author retains copyright of the work and grants ACM an exclusive
    permission-to-publish license;

  - Author transfers copyright of the work to ACM.

For more information, please see ACM Copyright Policy
(http://www.acm.org/publications/policies/copyright-policy) and ACM Author
Rights (http://authors.acm.org/main.html).

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

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

Artefacts
=========

Authors are encouraged to make auxiliary material (artefacts like source code,
test data, etc.) available with their paper. Authors can opt to have these
artefacts published alongside their paper in the ACM Digital Library (copyright
of artefacts remains with the authors). Artefacts must be included as part of
their submission to HotCRP and should consist of a .zip file containing the
artefact materials, a README explaining the contents of the artefact and how it
should be used, and a LICENSE file.

If an accepted paper's artefacts are made permanently available for retrieval in
a publicly accessible archival repository like the ACM Digital Library, that
paper qualifies for an Artefact badge
(https://www.acm.org/publications/policies/artifact-review-badging).

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

Alexander Green                 Standard Chartered, UK
David Thrane Christiansen       The Haskell Foundation, Denmark
Edsko de Vries                  Well-Typed LLP, Netherlands
Exequiel Rivas                  Tallinn University of Technology
Facundo Domínguez               Tweag
Florian Zuleger                 TU Vienna, Austria
Graham Hutton                   University of Nottingham, UK
Jasper Van der Jeugt            Snyk, Switzerland
Jennifer Paykin                 Intel, USA
Jesper Cockx                    Delft University of Technology, Netherlands
Jose Nuno Oliveira              University of Minho & INESC TEC, Portugal
Michael Sperber                 Active Group GmbH, Germany
Michel Steuwer                  University of Edinburgh, UK
Niki Vazou (chair)              IMDEA Software Institute, Spain
Rumyana Neykova                 Brunel University London, UK
Trevor L. McDonell (co-chair)   Utrecht University, Netherlands
Ugo Dal Lago                    University of Bologna, Italy & INRIA, France
Wen Kokke                       University of Edinburgh, UK
Leonidas Lampropoulos           University of Maryland, College Park, USA

If you have questions, please contact the chairs at
niki.vazou at imdea.org andt.l.mcdonell at uu.nl.

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

From professional at brechtserckx.be  Tue Mar 21 11:28:36 2023
From: professional at brechtserckx.be (Brecht Serckx)
Date: Tue, 21 Mar 2023 11:28:36 +0000
Subject: [Haskell-cafe] Package takeover: OpenSCAD
In-Reply-To: <CAHYVw0wD0RAU80siZF+fFah3x7n-SELUS=tanMZvPRh=xVZUFQ@mail.gmail.com>
References: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
 <CAHYVw0wD0RAU80siZF+fFah3x7n-SELUS=tanMZvPRh=xVZUFQ@mail.gmail.com>
Message-ID: <a-SHtIds873EQWkuy3Pz_9XXb17XTq9L8IdSugE8ngL2w-E6xs8z1DUM4XVD9ghfGC6cX3OV_MbTMzt5MviIxkiwL13L2klLA9oXOJW8AWc=@brechtserckx.be>

Hi Carter, can you link me to the process? I don't see anything about that on the [wiki](https://wiki.haskell.org/Taking_over_a_package).

Kind regards,
Brecht

------- Original Message -------
On Sunday, March 19th, 2023 at 3:41 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> first start the process for a non-maintainer update, then after thats happened can the take over process start :)
>
> On Thu, Mar 16, 2023 at 5:43 PM Brecht Serckx <professional at brechtserckx.be> wrote:
>
>> Hi all,
>>
>> I would like to take over the OpenSCAD[1] package, of which I believe the maintainer is no longer active.
>> The maintainer hasn't replied to my ticket[2] on the issue tracker or to an email to the listed email-address for over a year.
>> On my fork[3] I have implemented multiple bugfixes and features already, and I have some ideas for future improvements.
>>
>> Best regards,
>>
>> Brecht
>>
>> [1] https://hackage.haskell.org/package/OpenSCAD
>> [2] https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
>> [3] https://github.com/BrechtSerckx/OpenSCAD
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20230321/2c7bbde7/attachment.html>

From professional at brechtserckx.be  Tue Mar 21 11:37:29 2023
From: professional at brechtserckx.be (Brecht Serckx)
Date: Tue, 21 Mar 2023 11:37:29 +0000
Subject: [Haskell-cafe] CSG options for 3D printing (was: Package
	takeover: OpenSCAD)
In-Reply-To: <1094427d-9a95-78c3-ee81-29065afdbe09@ninebynine.org>
References: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
 <1094427d-9a95-78c3-ee81-29065afdbe09@ninebynine.org>
Message-ID: <4jX9zUTOe3fAg9KLVclpQpawigDqjZ-VFXtE5xhgugFcCKXU4rNSp9irRp6292UtSdKmNzaq6A_rL9nDOPsfkr-JExfsdvQXZqpFnp3Uxsk=@brechtserckx.be>

Hi Graham,

You might also be interested in https://hackage.haskell.org/package/implicit.
I don't know if it's more powerful, last time I tried it I had issues with 2D models though.

Kind regards,

Brecht

------- Original Message -------
On Sunday, March 19th, 2023 at 1:39 PM, Graham Klyne <gk at ninebynine.org> wrote:

> Hello Brecht,
>
> This is interesting, in that it's the first I've heard of there being an OpenSCAD package for Haskell 😯.
>
> I've been doing a fair bit of OpenSCAD design recently, and have frequently felt it would be nice express these constructs in Haskell or similar more fully featured functional source language. A previous search uncovered Haskell CSG packages, but I didn't see anything suitable for generating 3D printing files. (A search just now discovered https://hackage.haskell.org/package/mecha, which also offers OpenSCAD output.)
>
> I understand that one of the problems with OpenSCAD as a target language is that it only exports to STL files, with no primitive recognition of curved entities. I believe there are other 3D model representations (OBJ, 3MF?) that have primitives for curved elements, which in turn can be handled more smoothly by GCode generation software.
>
> (For non-3D printing folks reading this: GCode being the low level "machine" code that drives most personal 3D printers).
>
> Anyway, I've tagged your fork of OpenCSG and will aim to try it out sometime 😀. Thanks!
>
> #g
>
> On 16/03/2023 21:42, Brecht Serckx wrote:
>
>> Hi all,
>>
>> I would like to take over the OpenSCAD[1] package, of which I believe the maintainer is no longer active.
>> The maintainer hasn't replied to my ticket[2] on the issue tracker or to an email to the listed email-address for over a year.
>> On my fork[3] I have implemented multiple bugfixes and features already, and I have some ideas for future improvements.
>>
>> Best regards,
>>
>> Brecht
>>
>> [1] https://hackage.haskell.org/package/OpenSCAD
>> [2] https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
>> [3] https://github.com/BrechtSerckx/OpenSCAD
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> --
> Graham Klyne
> mailto:gk at ninebynine.org
>
> http://www.ninebynine.org
> Mastodon: @gklyne at indieweb.social
> GitHub/Skype: @gklyne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230321/745200d7/attachment.html>

From carter.schonwald at gmail.com  Tue Mar 21 17:36:21 2023
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 21 Mar 2023 13:36:21 -0400
Subject: [Haskell-cafe] Package takeover: OpenSCAD
In-Reply-To: <a-SHtIds873EQWkuy3Pz_9XXb17XTq9L8IdSugE8ngL2w-E6xs8z1DUM4XVD9ghfGC6cX3OV_MbTMzt5MviIxkiwL13L2klLA9oXOJW8AWc=@brechtserckx.be>
References: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
 <CAHYVw0wD0RAU80siZF+fFah3x7n-SELUS=tanMZvPRh=xVZUFQ@mail.gmail.com>
 <a-SHtIds873EQWkuy3Pz_9XXb17XTq9L8IdSugE8ngL2w-E6xs8z1DUM4XVD9ghfGC6cX3OV_MbTMzt5MviIxkiwL13L2klLA9oXOJW8AWc=@brechtserckx.be>
Message-ID: <CAHYVw0wqYEKL4p9PTsNdHeKLF7Eh=mTrb8r8-puKUyUQ0tUw1A@mail.gmail.com>

https://wiki.haskell.org/Hackage_trustees last i was involved in this
stuff, you open a ticket on the gh issue tracker and document what the
patch set is and trustees/hackage admins can work with you to see about
gettinga bug fix out

On Tue, Mar 21, 2023 at 7:28 AM Brecht Serckx <professional at brechtserckx.be>
wrote:

> Hi Carter, can you link me to the process? I don't see anything about that
> on the wiki <https://wiki.haskell.org/Taking_over_a_package>.
>
> Kind regards,
>
> Brecht
>
> ------- Original Message -------
> On Sunday, March 19th, 2023 at 3:41 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
> first start the process for a non-maintainer update, then after thats
> happened can the take over process start :)
>
> On Thu, Mar 16, 2023 at 5:43 PM Brecht Serckx <
> professional at brechtserckx.be> wrote:
>
>> Hi all,
>>
>> I would like to take over the OpenSCAD[1] package, of which I believe the
>> maintainer is no longer active.
>> The maintainer hasn't replied to my ticket[2] on the issue tracker or to
>> an email to the listed email-address for over a year.
>> On my fork[3] I have implemented multiple bugfixes and features already,
>> and I have some ideas for future improvements.
>>
>> Best regards,
>>
>> Brecht
>>
>> [1] https://hackage.haskell.org/package/OpenSCAD
>> [2]
>> https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
>> [3] https://github.com/BrechtSerckx/OpenSCAD
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20230321/6f17a6de/attachment.html>

From andrew.lelechenko at gmail.com  Tue Mar 21 23:09:20 2023
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Tue, 21 Mar 2023 23:09:20 +0000
Subject: [Haskell-cafe] Package takeover: OpenSCAD
In-Reply-To: <CAHYVw0wqYEKL4p9PTsNdHeKLF7Eh=mTrb8r8-puKUyUQ0tUw1A@mail.gmail.com>
References: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
 <CAHYVw0wD0RAU80siZF+fFah3x7n-SELUS=tanMZvPRh=xVZUFQ@mail.gmail.com>
 <a-SHtIds873EQWkuy3Pz_9XXb17XTq9L8IdSugE8ngL2w-E6xs8z1DUM4XVD9ghfGC6cX3OV_MbTMzt5MviIxkiwL13L2klLA9oXOJW8AWc=@brechtserckx.be>
 <CAHYVw0wqYEKL4p9PTsNdHeKLF7Eh=mTrb8r8-puKUyUQ0tUw1A@mail.gmail.com>
Message-ID: <71D336FF-271E-45E6-BA1D-85EB459A66DD@gmail.com>

Hi Brecht,

Please carry on with takeover; non-maintainer uploads are reserved for rare cases when there is no one willing to pick up maintainership. 

Best regards,
Andrew

> On 21 Mar 2023, at 17:36, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> https://wiki.haskell.org/Hackage_trustees last i was involved in this stuff, you open a ticket on the gh issue tracker and document what the patch set is and trustees/hackage admins can work with you to see about gettinga bug fix out
> 
> On Tue, Mar 21, 2023 at 7:28 AM Brecht Serckx <professional at brechtserckx.be <mailto:professional at brechtserckx.be>> wrote:
>> Hi Carter, can you link me to the process? I don't see anything about that on the wiki <https://wiki.haskell.org/Taking_over_a_package>.
>> 
>> Kind regards,
>> 
>> Brecht
>> 
>> ------- Original Message -------
>> On Sunday, March 19th, 2023 at 3:41 AM, Carter Schonwald <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>> 
>>> first start the process for a non-maintainer update, then after thats happened can the take over process start :) 
>>> 
>>> On Thu, Mar 16, 2023 at 5:43 PM Brecht Serckx <professional at brechtserckx.be <mailto:professional at brechtserckx.be>> wrote:
>>>> Hi all,
>>>> 
>>>> I would like to take over the OpenSCAD[1] package, of which I believe the maintainer is no longer active.
>>>> The maintainer hasn't replied to my ticket[2] on the issue tracker or to an email to the listed email-address for over a year.
>>>> On my fork[3] I have implemented multiple bugfixes and features already, and I have some ideas for future improvements.
>>>> 
>>>> Best regards,
>>>> 
>>>> Brecht
>>>> 
>>>> [1] https://hackage.haskell.org/package/OpenSCAD
>>>> [2] https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
>>>> [3] https://github.com/BrechtSerckx/OpenSCAD
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view 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/20230321/09643e06/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 22 01:16:07 2023
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 21 Mar 2023 21:16:07 -0400
Subject: [Haskell-cafe] Package takeover: OpenSCAD
In-Reply-To: <71D336FF-271E-45E6-BA1D-85EB459A66DD@gmail.com>
References: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
 <CAHYVw0wD0RAU80siZF+fFah3x7n-SELUS=tanMZvPRh=xVZUFQ@mail.gmail.com>
 <a-SHtIds873EQWkuy3Pz_9XXb17XTq9L8IdSugE8ngL2w-E6xs8z1DUM4XVD9ghfGC6cX3OV_MbTMzt5MviIxkiwL13L2klLA9oXOJW8AWc=@brechtserckx.be>
 <CAHYVw0wqYEKL4p9PTsNdHeKLF7Eh=mTrb8r8-puKUyUQ0tUw1A@mail.gmail.com>
 <71D336FF-271E-45E6-BA1D-85EB459A66DD@gmail.com>
Message-ID: <CAHYVw0xJ4qg5ARSz7YpEvUPRkRbUrhB1cGU5074nGjvEBj5s4g@mail.gmail.com>

really? thats new, i thought we first assume the maintainer will return,
and are careful about the takeover process and respecting the rights of
maintainers.

On Tue, Mar 21, 2023 at 7:09 PM Andrew Lelechenko <
andrew.lelechenko at gmail.com> wrote:

> Hi Brecht,
>
> Please carry on with takeover; non-maintainer uploads are reserved for
> rare cases when there is no one willing to pick up maintainership.
>
> Best regards,
> Andrew
>
> On 21 Mar 2023, at 17:36, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> https://wiki.haskell.org/Hackage_trustees last i was involved in this
> stuff, you open a ticket on the gh issue tracker and document what the
> patch set is and trustees/hackage admins can work with you to see about
> gettinga bug fix out
>
> On Tue, Mar 21, 2023 at 7:28 AM Brecht Serckx <
> professional at brechtserckx.be> wrote:
>
>> Hi Carter, can you link me to the process? I don't see anything about
>> that on the wiki <https://wiki.haskell.org/Taking_over_a_package>.
>>
>> Kind regards,
>>
>> Brecht
>>
>> ------- Original Message -------
>> On Sunday, March 19th, 2023 at 3:41 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>> first start the process for a non-maintainer update, then after thats
>> happened can the take over process start :)
>>
>> On Thu, Mar 16, 2023 at 5:43 PM Brecht Serckx <
>> professional at brechtserckx.be> wrote:
>>
>>> Hi all,
>>>
>>> I would like to take over the OpenSCAD[1] package, of which I believe
>>> the maintainer is no longer active.
>>> The maintainer hasn't replied to my ticket[2] on the issue tracker or to
>>> an email to the listed email-address for over a year.
>>> On my fork[3] I have implemented multiple bugfixes and features already,
>>> and I have some ideas for future improvements.
>>>
>>> Best regards,
>>>
>>> Brecht
>>>
>>> [1] https://hackage.haskell.org/package/OpenSCAD
>>> [2]
>>> https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
>>> [3] https://github.com/BrechtSerckx/OpenSCAD
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view 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/20230321/7ce9280c/attachment.html>

From andrew.lelechenko at gmail.com  Wed Mar 22 01:38:21 2023
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Wed, 22 Mar 2023 01:38:21 +0000
Subject: [Haskell-cafe] Package takeover: OpenSCAD
In-Reply-To: <CAHYVw0xJ4qg5ARSz7YpEvUPRkRbUrhB1cGU5074nGjvEBj5s4g@mail.gmail.com>
References: <KTH3ZOmBZOQS0Lz6PhtpyKAiyzVeF5JZmKnocmJ1i4lr_LhAzrIfdk5lArrJUKN4FjGnwb6MFsg0ue-CAlrXmDBibOsfTQDmRgWh6RLsL3E=@brechtserckx.be>
 <CAHYVw0wD0RAU80siZF+fFah3x7n-SELUS=tanMZvPRh=xVZUFQ@mail.gmail.com>
 <a-SHtIds873EQWkuy3Pz_9XXb17XTq9L8IdSugE8ngL2w-E6xs8z1DUM4XVD9ghfGC6cX3OV_MbTMzt5MviIxkiwL13L2klLA9oXOJW8AWc=@brechtserckx.be>
 <CAHYVw0wqYEKL4p9PTsNdHeKLF7Eh=mTrb8r8-puKUyUQ0tUw1A@mail.gmail.com>
 <71D336FF-271E-45E6-BA1D-85EB459A66DD@gmail.com>
 <CAHYVw0xJ4qg5ARSz7YpEvUPRkRbUrhB1cGU5074nGjvEBj5s4g@mail.gmail.com>
Message-ID: <92A32A73-35B5-47A1-B1CF-15890B77281D@gmail.com>

Nothing new here, non-maintainer uploads (NMUs) are an extreme and undesirable scenario in which Hackage Trustees risk to be caught in quasi-maintainership for indefinitely long. This is normally reserved for “boring" packages, which no volunteer fancies to maintain, but which are for some reason systemically important, so Trustees keep them afloat. If there is a willing to-be-maintainer for a non-mainstream package, it would be reckless to do an NMU, especially given that changes in question are non-trivial.

The rights of original maintainers are well protected, they can reclaim the package back unconditionally within a year, see the last paragraph of https://wiki.haskell.org/Taking_over_a_package

Best regards,
Andrew

> On 22 Mar 2023, at 01:16, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> really? thats new, i thought we first assume the maintainer will return, and are careful about the takeover process and respecting the rights of maintainers. 
> 
> On Tue, Mar 21, 2023 at 7:09 PM Andrew Lelechenko <andrew.lelechenko at gmail.com <mailto:andrew.lelechenko at gmail.com>> wrote:
>> Hi Brecht,
>> 
>> Please carry on with takeover; non-maintainer uploads are reserved for rare cases when there is no one willing to pick up maintainership. 
>> 
>> Best regards,
>> Andrew
>> 
>>> On 21 Mar 2023, at 17:36, Carter Schonwald <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>>> 
>>> https://wiki.haskell.org/Hackage_trustees last i was involved in this stuff, you open a ticket on the gh issue tracker and document what the patch set is and trustees/hackage admins can work with you to see about gettinga bug fix out
>>> 
>>> On Tue, Mar 21, 2023 at 7:28 AM Brecht Serckx <professional at brechtserckx.be <mailto:professional at brechtserckx.be>> wrote:
>>>> Hi Carter, can you link me to the process? I don't see anything about that on the wiki <https://wiki.haskell.org/Taking_over_a_package>.
>>>> 
>>>> Kind regards,
>>>> 
>>>> Brecht
>>>> 
>>>> ------- Original Message -------
>>>> On Sunday, March 19th, 2023 at 3:41 AM, Carter Schonwald <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>>>> 
>>>>> first start the process for a non-maintainer update, then after thats happened can the take over process start :) 
>>>>> 
>>>>> On Thu, Mar 16, 2023 at 5:43 PM Brecht Serckx <professional at brechtserckx.be <mailto:professional at brechtserckx.be>> wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> I would like to take over the OpenSCAD[1] package, of which I believe the maintainer is no longer active.
>>>>>> The maintainer hasn't replied to my ticket[2] on the issue tracker or to an email to the listed email-address for over a year.
>>>>>> On my fork[3] I have implemented multiple bugfixes and features already, and I have some ideas for future improvements.
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> Brecht
>>>>>> 
>>>>>> [1] https://hackage.haskell.org/package/OpenSCAD
>>>>>> [2] https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b
>>>>>> [3] https://github.com/BrechtSerckx/OpenSCAD
>>>>>> _______________________________________________
>>>>>> Haskell-Cafe mailing list
>>>>>> To (un)subscribe, modify options or view 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/20230322/85f19ec4/attachment.html>

From abela at chalmers.se  Thu Mar 23 07:27:50 2023
From: abela at chalmers.se (Andreas Abel)
Date: Thu, 23 Mar 2023 08:27:50 +0100
Subject: [Haskell-cafe] Intend to take over package filelock
Message-ID: <ba821013-6e6b-dd86-8b5a-68049f4b3f60@chalmers.se>

See 
https://discourse.haskell.org/t/take-over-filelock-package/6037?u=andreasabel 
:

I intend to take over https://hackage.haskell.org/package/filelock.
It is a dependency of crucial Haskell infrastructure such as `pantry` 
and `haskell-server` (via `acid-state`).
I needs a fix to work with `unix-2.8` as released with GHC 9.6:
- https://github.com/takano-akio/filelock/pull/13

I have been trying to communicate this on github to the maintainer 
Takano Akio since 2023-02-08.
I have tried to contact the maintainer by email 2023-03-12, but have 
gotten no response.

Preferably, the maintainer would come back, but I do not have much hope, 
their last public github activity was 2021-08-22.

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www.cse.chalmers.se/~abela/

From anthony.d.clayden at gmail.com  Thu Mar 23 23:51:43 2023
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Fri, 24 Mar 2023 12:51:43 +1300
Subject: [Haskell-cafe] Basic list exercise
Message-ID: <CABU_mxiBJsyRZ5OoGoxbdE-C65QQ3TOmJs1RweRGnnp7o9=YNw@mail.gmail.com>

On Thu, Mar 16, 2023, 20:33 Todd Wilson <twilson at csufresno.edu
<http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>>
wrote:

> ...

> My question: can we do better than this? It seems that this solution is

> constantly building and breaking apart pairs. (Or is it, when optimized?)


I don't think we can do better (as others have commented). Laziness is a
benefit for peeling off only the beginning(s) of possibly-infinite
(sub-)lists.

Possibly splitting off the head to call sub-function `run x xs` is also
"breaking apart". If you don't like pairs, you can split the returned list
itself to give the pairing.

Using `l@(y:zs)` as did Viktor might help a little if the compiler is
particularly dumb. (GHC isn't.)

>    runs :: Ord a => [a] -> [[a]]
>
>    runs   []  = []
>    runs l@[x] = [l]
>    runs (x: l@(y:zs))
>        | x <= y    = let (ys:zs) = runs l in ((x:ys) : zs)
>        | otherwise = ([x]: runs l)

This solution appears to  achieve the same level of laziness as Viktor's.

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

From jerzy.karczmarczuk at unicaen.fr  Fri Mar 24 01:27:42 2023
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Fri, 24 Mar 2023 02:27:42 +0100
Subject: [Haskell-cafe] Never-ending discussion... Was: Basic list exercise
In-Reply-To: <CABU_mxiBJsyRZ5OoGoxbdE-C65QQ3TOmJs1RweRGnnp7o9=YNw@mail.gmail.com>
References: <CABU_mxiBJsyRZ5OoGoxbdE-C65QQ3TOmJs1RweRGnnp7o9=YNw@mail.gmail.com>
Message-ID: <aac5dbb7-ec28-5488-f534-869200965b0f@unicaen.fr>


Le 24/03/2023 à 00:51, Anthony Clayden a écrit :
> On Thu, Mar 16, 2023, 20:33 Todd Wilson <twilson at csufresno.edu  <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote:
> > ...
>
> > My question: can we do better than this? It seems that this solution is
> > constantly building and breaking apart pairs. (Or is it, when optimized?)
> I don't think we can do better (as others have commented). Laziness is 
> a benefit for peeling off only the beginning(s) of possibly-infinite 
> (sub-)lists.

I believe that there is more to say about this function "runs" than just 
concentrate on the issue of rebuilding the result list. This is one of 
quite classical pedagogical exercises in list processing in Haskell, and 
has been discussed at least twice on StackOverflow

E.g.,

https://stackoverflow.com/questions/14403293/need-to-partition-a-list-into-lists-based-on-breaks-in-ascending-order-of-elemen

Such recursive schemas as proposed by Todd Wilson should be -- of course 
-- mastered, but, suppose that your students have already heard about 
combinators, and all them zips, folds, maps, etc. , and they need now 
some training. What about the following?

runs xs = ru (zip xs (False : zipWith (<) xs (tail xs)))
   where
   ru (z:zq) =
       let (a,b) = span snd zq
       in  (map fst (z:a) :  ru b)
   ru [] = []

When I gave this exercise (some centuries ago), I didn't care about 
having manufactured  auxiliary structures, but I gently asked the 
students to /*understand*/ this code, to realize that it is easy to 
"transmute" a (binary) relation between neighbours in a list into a 
unary predicate, which could then be used by *span*.

Jerzy Karczmarczuk



-- 
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230324/09158b13/attachment.html>

From ivanperezdominguez at gmail.com  Fri Mar 24 03:04:16 2023
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Thu, 23 Mar 2023 20:04:16 -0700
Subject: [Haskell-cafe] ANN: NASA's Ogma 1.0.8 -- with FPrime support
Message-ID: <CACZKWELG15q1ns2soqoS3=QLSN3WZkpnWRm1x-8BkAHC_R-AyQ@mail.gmail.com>

Hi everyone!

I'm thrilled to announce the release of Ogma 1.0.8!

Ogma is a NASA tool that facilitates integrating runtime monitors or
runtime verification applications into other systems.

This is one of the biggest releases of Ogma ever: We can now generate
monitors for FPrime [1], a component-based flight software framework
used in many NASA missions, including the Ingenuity Mars Helicopter.

Since the last release, Ogma also has officially become one of the
solutions recommended for monitoring in Space ROS applications [2].

Use cases supported by Ogma also include producing Robot Operating
System (ROS 2) packages [3] and NASA Core Flight System (cFS) monitoring
applications [4], and generating monitors directly from requirements
specified using a structured natural language framework [5]. Ogma
leverages existing Haskell work, like the Copilot language [6] (also
funded by NASA) and BNFC [7].

For more details, including videos of monitors being generated and flown
in simulators, see:
https://github.com/nasa/ogma

* Releases

Ogma is released as a collection of packages in Hackage. The entry point
is https://hackage.haskell.org/package/ogma-cli.

* Code

The github repo is located at: https://github.com/nasa/ogma.

* What's coming

The next release is planned for May 21st, 2023.

Ogma is currently undergoing the qualification process necessary for
NASA Class D Software. Apart from the changes required by that process,
we also have the following in our roadmap:

- Extend ROS 2 monitors with further information about sources of
  violations.

- Add tests to generated code.

- Simplify NASA cFS monitor generation process.

We hope that you are as excited as we are and that our work demonstrates
that, with the right support, Haskell can reach farther than we ever
thought possible.

Happy Haskelling!

Ivan

[1] https://github.com/nasa/fprime

[2] https://space.ros.org/

[3] https://www.ros.org/

[4] https://github.com/nasa/cFS

[5] https://github.com/NASA-SW-VnV/fret

[6] https://github.com/Copilot-Language/copilot

[7] https://github.com/BNFC/bnfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230323/d31de6df/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Fri Mar 24 17:44:54 2023
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Fri, 24 Mar 2023 18:44:54 +0100
Subject: [Haskell-cafe] Basic list exercise
Message-ID: <ad3be3eb-ae6d-89d5-98ca-4600f58a558e@htwk-leipzig.de>

 > can we do better than this?

Does the implementation in Data.List do better?

https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#sort

note that 'ascending' does some trickery there -
perhaps exactly to solve the problem you describe?

Since this is about "exercise" - I would expect my students
to find that code, so perhaps I'd point them to it right away,
and give the task to "understand it" (= argue that it is correct).
Arguing about cost seems harder.


NB: 'descending' is different here, and that's no surprise
since lists are asymmetric. We do have a symmetric (and strict) 
implementation of sequences - how do we sort these?

https://hackage.haskell.org/package/containers-0.6.7/docs/src/Data.Sequence.Internal.Sorting.html#sortBy

That's not exactly an advertisement for functional programming,
as it has "state" written all over the place?
But it makes for a nice exercise reading the types.

I needed some time to understand that the mouse-over block
for an identifier contains _two_ types:
the instantiated one (for the use site)
and, below that, the general one (from the definition).


- J.W.

From migmit at gmail.com  Fri Mar 24 17:52:31 2023
From: migmit at gmail.com (MigMit)
Date: Fri, 24 Mar 2023 18:52:31 +0100
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <ad3be3eb-ae6d-89d5-98ca-4600f58a558e@htwk-leipzig.de>
References: <ad3be3eb-ae6d-89d5-98ca-4600f58a558e@htwk-leipzig.de>
Message-ID: <5810E4E8-FB85-4F06-8367-4B9B1E44916E@gmail.com>

If I understand correcly, Data.List is building a lot of closures — basically, a CPS transform. I though about it, but I'm not sure it is better.

> On 24 Mar 2023, at 18:44, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> wrote:
> 
> > can we do better than this?
> 
> Does the implementation in Data.List do better?
> 
> https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#sort
> 
> note that 'ascending' does some trickery there -
> perhaps exactly to solve the problem you describe?
> 
> Since this is about "exercise" - I would expect my students
> to find that code, so perhaps I'd point them to it right away,
> and give the task to "understand it" (= argue that it is correct).
> Arguing about cost seems harder.
> 
> 
> NB: 'descending' is different here, and that's no surprise
> since lists are asymmetric. We do have a symmetric (and strict) implementation of sequences - how do we sort these?
> 
> https://hackage.haskell.org/package/containers-0.6.7/docs/src/Data.Sequence.Internal.Sorting.html#sortBy
> 
> That's not exactly an advertisement for functional programming,
> as it has "state" written all over the place?
> But it makes for a nice exercise reading the types.
> 
> I needed some time to understand that the mouse-over block
> for an identifier contains _two_ types:
> the instantiated one (for the use site)
> and, below that, the general one (from the definition).
> 
> 
> - J.W.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



From jclites at mac.com  Fri Mar 24 18:38:56 2023
From: jclites at mac.com (Jeff Clites)
Date: Fri, 24 Mar 2023 11:38:56 -0700
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <5810E4E8-FB85-4F06-8367-4B9B1E44916E@gmail.com>
References: <5810E4E8-FB85-4F06-8367-4B9B1E44916E@gmail.com>
Message-ID: <7B9EAF01-B470-4A38-BA76-2DFB7A48B2DA@mac.com>

Yes, I think that technique is equivalent to building the list you want backwards, and then reversing it at the end. (This is because the closures are forming a structure which is essentially a linked list, and when finally applied to an argument they build the desired actual list by traversing the closures in reverse order relative to how they were allocated.)

So I agree, I don’t think it’s better in terms of allocation.

Jeff

> On Mar 24, 2023, at 10:53 AM, MigMit <migmit at gmail.com> wrote:
> 
> If I understand correcly, Data.List is building a lot of closures — basically, a CPS transform. I though about it, but I'm not sure it is better.
> 
>>> On 24 Mar 2023, at 18:44, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> wrote:
>>> 
>>> can we do better than this?
>> 
>> Does the implementation in Data.List do better?
>> 
>> https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#sort
>> 
>> note that 'ascending' does some trickery there -
>> perhaps exactly to solve the problem you describe?
>> 
>> Since this is about "exercise" - I would expect my students
>> to find that code, so perhaps I'd point them to it right away,
>> and give the task to "understand it" (= argue that it is correct).
>> Arguing about cost seems harder.
>> 
>> 
>> NB: 'descending' is different here, and that's no surprise
>> since lists are asymmetric. We do have a symmetric (and strict) implementation of sequences - how do we sort these?
>> 
>> https://hackage.haskell.org/package/containers-0.6.7/docs/src/Data.Sequence.Internal.Sorting.html#sortBy
>> 
>> That's not exactly an advertisement for functional programming,
>> as it has "state" written all over the place?
>> But it makes for a nice exercise reading the types.
>> 
>> I needed some time to understand that the mouse-over block
>> for an identifier contains _two_ types:
>> the instantiated one (for the use site)
>> and, below that, the general one (from the definition).
>> 
>> 
>> - 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.
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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  Fri Mar 24 21:10:54 2023
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Fri, 24 Mar 2023 22:10:54 +0100
Subject: [Haskell-cafe] Never-ending discussion... Was: Basic list
	exercise
Message-ID: <53e13b10-b019-7311-13cf-e7208be44bfe@htwk-leipzig.de>

@Jerzy : I like your plan to use combinators.
Then let's remove (visible) recursion completely:

map (map fst ) $ groupBy (const snd)
                $ zip xs ( True : zipWith (<=) xs (tail xs))



From anthony.d.clayden at gmail.com  Fri Mar 24 21:11:41 2023
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Sat, 25 Mar 2023 10:11:41 +1300
Subject: [Haskell-cafe] Basic list exercise
Message-ID: <CABU_mxgd6mN_CZOZOQR+av9qPPpzjxVb8ddVsX94k9KFCvCfDQ@mail.gmail.com>

>* On 24 Mar 2023, at 18:44, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote:
*> >* ...
*>* Does the implementation in Data.List do better?
*>


Data.List's sort is doing a different thing. So I'm not seeing the
relevance. Specifically, sort doesn't pay any attention to the
incoming list's ordering.


>* Since this is about "exercise" - I would expect my students
*>* to find that code, so perhaps I'd point them to it right away,
*>* and give the task to "understand it" (= argue that it is correct).
*>* Arguing about cost seems harder.
*>

This (ex-)student would wonder why you'd sent me to that code. (Perhaps the
lesson is: first read the question.)

Why does the correctness (or otherwise) of a sort bear any relation to
preserving list sequence and chopping up a list into ascending
sublists?


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

From david.feuer at gmail.com  Fri Mar 24 22:05:38 2023
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 24 Mar 2023 18:05:38 -0400
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CABU_mxgd6mN_CZOZOQR+av9qPPpzjxVb8ddVsX94k9KFCvCfDQ@mail.gmail.com>
References: <CABU_mxgd6mN_CZOZOQR+av9qPPpzjxVb8ddVsX94k9KFCvCfDQ@mail.gmail.com>
Message-ID: <CAMgWh9upwH5mVboYrc+qG8gpWSJY_z2q4Ah0RMCuNwS3Yr999Q@mail.gmail.com>

The correctness argument he was referring to was about understanding code
in an educational context. The relevance is that Data.List.sort breaks up
the input list into maximal "runs" of ascending or descending elements, to
take advantage of any pre-existing organization. It then merges up runs
rather than individual elements.

On Fri, Mar 24, 2023, 5:12 PM Anthony Clayden <anthony.d.clayden at gmail.com>
wrote:

> >* On 24 Mar 2023, at 18:44, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote:
> *> >* ...
> *>* Does the implementation in Data.List do better?
> *>
>
>
> Data.List's sort is doing a different thing. So I'm not seeing the relevance. Specifically, sort doesn't pay any attention to the incoming list's ordering.
>
>
> >* Since this is about "exercise" - I would expect my students
> *>* to find that code, so perhaps I'd point them to it right away,
> *>* and give the task to "understand it" (= argue that it is correct).
> *>* Arguing about cost seems harder.
> *>
>
> This (ex-)student would wonder why you'd sent me to that code. (Perhaps
> the lesson is: first read the question.)
>
> Why does the correctness (or otherwise) of a sort bear any relation to preserving list sequence and chopping up a list into ascending sublists?
>
>
> AntC
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230324/799f5761/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Sat Mar 25 00:04:26 2023
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Sat, 25 Mar 2023 01:04:26 +0100
Subject: [Haskell-cafe] Never-ending discussion... Was: Basic list
 exercise
In-Reply-To: <53e13b10-b019-7311-13cf-e7208be44bfe@htwk-leipzig.de>
References: <53e13b10-b019-7311-13cf-e7208be44bfe@htwk-leipzig.de>
Message-ID: <3b9af7ac-91ec-6c75-178a-007b4563e65b@unicaen.fr>

We continue the separation of ascending subequences...

Le 24/03/2023 à 22:10, Johannes Waldmann a écrit :
> @Jerzy : I like your plan to use combinators.
> Then let's remove (visible) recursion completely:
>
> *map (map fst ) $ groupBy (const snd)
>                $ zip xs ( True : zipWith (<=) xs (tail xs)) *

Hmmm, I didn't find it... Perhaps at that time I didn't acquire yet a 
sufficient level of perversion...

Well, the truth is that I had problems with groupBy! People discovered 
that the "standard" groupBy, which was sometimes thought of as an 
iterator which compared neighbours, didn't. If it behaved as some people 
wished, then we could simply write

*groupBy (<) [3,4,5,6,2,3,4,1,2,1]*

and get : *[[3,4,5,6],[2,3,4],[1,2],[1]] *

Actually ... It works!! But unfortunately this is accidental. The 
following example doesn't:

*groupBy (<) [5,3,1,2,8,6,3,7,2,5,9]
[[5],[3],[1,2,8,6,3,7,2,5,9]]*

This was discovered apparently more than once. Look up

*http://brandon.si/code/an-alternative-definition-for-datalistgroupby/*

Brandon Simmons gives his alternative definition, which defines its own 
version of span:

*groupBy' :: (a -> a -> Bool) -> [a] -> [[a]]
groupBy' c [] = []
groupBy' c (a:as) = (a:ys) : groupBy' c zs
     where (ys,zs) = spanC a as
           spanC _ [] = ([], [])
           spanC a' (x:xs)
             | a' `c` x = let (ps,qs) = spanC x xs
                           in (x:ps,qs)
             | otherwise = ([], x:xs)*

which yields the following result:

*groupBy' (<) [5,3,1,2,8,6,3,7,2,5,9]
[[5],[3],[1,2,8],[6],[3,7],[2,5,9]]*

Look also:

*https://hackage.haskell.org/package/groupBy-0.1.0.0/docs/Data-List-GroupBy.html*

by Donnacha Oisín Kidney (c) 2018; but I didn't verify his variant.

==

Jerzy Karczmarczuk



-- 
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230325/dc4921e6/attachment.html>

From anthony.d.clayden at gmail.com  Sat Mar 25 01:10:56 2023
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Sat, 25 Mar 2023 14:10:56 +1300
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CAMgWh9upwH5mVboYrc+qG8gpWSJY_z2q4Ah0RMCuNwS3Yr999Q@mail.gmail.com>
References: <CABU_mxgd6mN_CZOZOQR+av9qPPpzjxVb8ddVsX94k9KFCvCfDQ@mail.gmail.com>
 <CAMgWh9upwH5mVboYrc+qG8gpWSJY_z2q4Ah0RMCuNwS3Yr999Q@mail.gmail.com>
Message-ID: <CABU_mxi8hDFB6s=u5tvudaTAGM1xT5Gwat2Fn_Ox6NiDpL=NcQ@mail.gmail.com>

(A word of counsel to the O.P.: the cafe is a place your q is liable to get
sidetracked into all sorts of places you didn't ask about. When you get to
a certain level of comfort with Haskell, that can be a learning experience.
Meantime you might find it better to ask on the Beginners' list, or
Stackoverflow -- as @Jerzy links to.)

On Sat, 25 Mar 2023 at 11:05, David Feuer <david.feuer at gmail.com> wrote:

> The correctness argument he was referring to was about understanding code
> in an educational context. The relevance is that Data.List.sort breaks up
> the input list into maximal "runs" of ascending or descending elements, to
> take advantage of any pre-existing organization. It then merges up runs
> rather than individual elements.
>
>
Thank you David. Let me take this opportunity to demonstrate why the
Haskell community is so off-putting to learners ...

The first thing the learner will come across at Johannes' link is

>    sortBy
<https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#sortBy>
:: (a
<https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#local-6989586621679636970>
-> a
<https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#local-6989586621679636970>
-> Ordering
<https://hackage.haskell.org/package/base-4.18.0.0/docs/https://hackage.haskell.org/package/ghc-prim-0.10.0/docs/src/GHC.Types.html#Ordering/GHC.Types.html#Ordering>
) -> [a
<https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#local-6989586621679636970>
] -> [a
<https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#local-6989586621679636970>
]

So now they have to find out about `Ordering` and generic compare functions.

The next thing they might know is that sorting can't emit anything until
it's read the whole input -- just in case the least element is also the
last. So the gentle work @Viktor's answer did in extolling the benefits of
laziness is undone.

Now the O.P.'s concern was "constantly building and breaking apart pairs".
This is a rather naieve q, showing over-much procedural thinking IMO; but
the way to allay those fears is exactly _not_ what's going on inside `sort`.

* `ascending` is using a short-circuited form of `append` -- famous for
being inefficient.
* `descending` is using a short-circuited form of `reverse` -- also famous
for being inefficient.

Now the short-circuiting allays some of those inefficiencies (maybe, for a
smart compiler); but at first reading the code is doing far more "building
and breaking apart".

So a) Johannes' post hasn't answered the sub-text of the O.P.; b) it has
sent the learner on a wild goose chase.

Now, I don't know if this style of response is typical from Haskell
instructors. It is certainly not the warm and sympathetic welcome I
experienced when learning Haskell 12~15 years ago (before there was
StackOverflow). So if this is what @DavidF means by the
"educational context" for Haskell, I as a learner would have been inclined
to abandon Haskell as soon as my course allowed it.

I can only take it that "an educational context" means for those on track
to a PhD in advanced type theory and convoluted data structuring; and
exclude others from the ivory tower at the earliest opportunity.

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

From johannes.waldmann at htwk-leipzig.de  Sun Mar 26 17:31:04 2023
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Sun, 26 Mar 2023 19:31:04 +0200
Subject: [Haskell-cafe] Basic list exercise
Message-ID: <7e098397-96ac-a699-0ea2-0ca59f98762c@htwk-leipzig.de>

Dear Anthony, and Cafe,


 > ... get sidetracked into all sorts of places you didn't ask about

that's the semantics of "-cafe"? I think we agree.
In that spirit, allow me to continue with some more tangential remarks.


 > Haskell community is so off-putting to learners ...

I think a language (or other tool) is best for learning
if it shows the concepts (that are the subject of the study)
most clearly, instead of ignoring, hiding, or sugarcoating them.

 > So now they have to find out about `Ordering`
 > and generic compare functions.

Yes - that's algebraic data types, higher order functions,
generic polymorphism. You don't get Haskell without that.
(By definition: functional, strongly typed)

Now we might argue whether that's really the concepts
that are needed to answer the original question of this thread.
In a way, yes - it is about runs in a list,
and a run is defined with respect to an order,
so it feels natural that the order is an input of the problem.


In another way, no (I think that is your point) -
it was about efficient implementation, and that could as well
be discussed with a monomorphic type and some fixed order.

I found the original question interesting, and I thought
that authors of the standard library must have asked
the same thing, and the resulting library source code seems
to confirm what the OP conjectured: there is no easy way to get
ascending runs. How bad is it? I made this experiment:

import Criterion.Main
import qualified Data.List as L

main = do
   let up = [1 .. 10^7 :: Int]
       down = reverse up
   print (sum  up, sum down)
   defaultMain
     [ bench "length up"   $ nf length up
     , bench "length down" $ nf length down
     , bench "sort up"   $ nf L.sort up
     , bench "sort down" $ nf L.sort down
     ]

and it shows that sorting an ascending list
(which just builds the one ascending run)
takes three times the work of just traversing it,
but sorting a descending list (building
one descending run) only two times.


Now, I am not too much worried about efficiency
of these particular functions (ascending/descending/sort)
because I firmly believe that: 1. using a list as a container
is wrong (did you mean Data.Sequence?) 2. sorting lists
is more wrong  (use Data.Set from the start) 3. writing a sort
function yourself is most wrong, - of course with the caveat:
0. unless you get this as homework. Then you should absolutely do it
(and then learn from it, and then forget the concrete instance).


What worries me here much more deeply is
https://github.com/haskell/criterion/issues/273
yes, that's another thing the OP did not ask about.


- J.W.

From twilson at csufresno.edu  Sun Mar 26 17:59:13 2023
From: twilson at csufresno.edu (Todd Wilson)
Date: Sun, 26 Mar 2023 10:59:13 -0700
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
Message-ID: <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>

I want to thank all of those who contributed to this thread. If I can
summarize the contributions (feel free to clarify any misrepresentations):

   - The code I provided for this problem is probably optimal, except
   perhaps for the small point about using an @-pattern in `run` to avoid
   reconstructing `y:ys` in the last line -- but isn't this also something the
   compiler could easily discover and take advantage of without explicit
   direction?
   - The compiler will avoid breaking down and reconstructing pairs on each
   recursive call, even though that is how it is coded.
   - Although nobody commented on my Prolog version (perhaps because this
   is a Haskell list!), the point I made there about compiling this as a tail
   call that doesn't grow the stack should also apply to Haskell (does it?).
   One thing that's clear from the Prolog code is that it goes down the input
   list and distributes the elements to one of two places -- the end of the
   current run or the beginning of a new run -- interspersed with some
   cons-cell creation. Is that what's happening in Haskell also?
   - Reference was made to Haskell's `sort` implementation, which
   essentially finds runs (increasing and decreasing) in the input before
   repeatedly merging them in pairs until one run remains. Decreasing runs can
   be turned into increasing ones by using a tail call with a list
   accumulator, the way iterative reverse works. But increasing runs are
   handled in the same way that my Prolog code does, essentially by using what
   appears to be the Haskell equivalent of Prolog's difference-lists:
   functions whose arguments are the extendible ends of lists.

I'm intrigued by the idea mentioned in this last bullet point. Is this
functional equivalent of Prolog's difference lists -- essentially partial
data structures that are grown top-down rather than bottom-up, actually
efficient? Is there an overhead penalty to be paid for using functions
here, or is it compiled away into Prolog-like tail calls that fill in the
missing parts of the data structure?

Todd Wilson

On Thu, Mar 16, 2023 at 6:33 PM Todd Wilson <twilson at csufresno.edu> wrote:

> Dear Cafe,
>
> Here's a basic exercise in list processing: define a function
>
> runs :: Ord a => [a] -> [[a]]
>
> that breaks up its input list into a list of increasing "runs"; e.g.,
>
> runs [3,4,5,6,2,3,4,1,2,1]  --->  [[3,4,5,6],[2,3,4],[1,2],[1]]
>
> A natural solution is the following:
>
> runs [] = []
> runs (x:xs) = let (ys, zs) = run x xs
>               in (x:ys) : runs zs
>   where
>     run x [] = ([], [])
>     run x (y:ys) = if x <= y
>                    then let (us, vs) = run y ys
>                         in (y:us, vs)
>                    else ([], y:ys)
>
> My question: can we do better than this? It seems that this solution is
> constantly building and breaking apart pairs. (Or is it, when optimized?)
>
> Todd Wilson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230326/1a5b331d/attachment.html>

From ietf-dane at dukhovni.org  Sun Mar 26 19:07:03 2023
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 26 Mar 2023 15:07:03 -0400
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
 <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
Message-ID: <ZCCX16+jsvlfhDER@straasha.imrryr.org>

On Sun, Mar 26, 2023 at 10:59:13AM -0700, Todd Wilson wrote:

> Is there an overhead penalty to be paid for using functions here, or
> is it compiled away into Prolog-like tail calls that fill in the
> missing parts of the data structure?

Efficient implementations of functional langauges make extensive use of
tail call optimisation.

I don't know whether looking at the GHC-generated "Core" for your
implementation will answer any of your questions, but here it is:

  Haskell:
    runs (x:xs) = let (ys, zs) = run x xs in (x:ys) : runs zs
      where
        run x [] = ([], [])
        run x (y:ys) = if x <= y
                       then let (us, vs) = run y ys
                            in (y:us, vs)
                       else ([], y:ys)

  Core (with some added comments):
    -- Unpack the "Ord" dictionary to extract just the required "<="
    -- function and call the "$wruns" worker ("ww3" is "<=", and "ds"
    -- is the list to be transformed:
    --
    runs :: forall a. Ord a => [a] -> [[a]]
    runs
      = \ (@a) ($dOrd :: Ord a) (ds :: [a]) ->
          case $dOrd of { C:Ord ww ww1 ww2 ww3 ww4 ww5 ww6 ww7 ->
          $wruns ww3 ds
          }

    Rec {
    $wruns :: forall {a}. (a -> a -> Bool) -> [a] -> [[a]]
    $wruns
      = \ (@a) (ww :: a -> a -> Bool) (ds :: [a]) ->
          case ds of {
            [] -> [];           -- runs [] = []
            : x xs ->           -- runs (x:xs) = let (ys, zs) = run x xs in (x:ys) : runs zs
              let {
                ds1 :: ([a], [a])  -- A lazily evaluated thunk for (run x xs)
                ds1
                  = letrec {
                      -- Internal recursion in "run" returns strict unboxed pairs
                      -- (on the stack) avoiding heap or thunk allocation for the tuple.
                      $wrun :: a -> [a] -> (# [a], [a] #)
                      $wrun
                        = \ (x1 :: a) (ds2 :: [a]) ->
                            case ds2 of wild1 {         -- (y:ys) is "wild1"
                              [] -> (# [], [] #);       -- run x [] = ([], [])
                              : y ys ->
                                case ww x1 y of {       -- x <= y ?
                                  False -> (# [], wild1 #);  -- else ([], y:ys)
                                  True ->                    -- then let (us, vs) = run y ys in (y:us, vs)
                                    let {
                                      ds3 :: ([a], [a])      -- A "thunk" for (run y ys) evaluated lazily
                                      ds3 = case $wrun y ys of { (# ww1, ww2 #) -> (ww1, ww2) } } in
                                    (# : y (case ds3 of { (us, vs) -> us }),
                                       case ds3 of { (us, vs) -> vs } #)
                                }
                            }; } in
                    case $wrun x xs of { (# ww1, ww2 #) -> (ww1, ww2) } } in
              : (: x (case ds1 of { (ys, zs) -> ys }))
                (case ds1 of { (ys, zs) -> $wruns ww zs })
          }
    end Rec }

So for a non-empty cons-cell (: x ...) the result is a new cons cell:

    : (x : (fst ds1)) (runs (snd ds1))
           ---------   --------------

in which both underline parts are computed lazily (on demand) from the
thunk "ds1":

    λ> head $ head $ runs $ 42 : undefined
    42

When we do want the successor of the first element, we look no futher
than necessary:

    λ> head $ runs $ 42 : 0 : undefined
    [42]

    λ> take 2 $ head $ runs $ 42 : 43 : undefined
    [42,43]

Does this help?  FWIW, the (simplified) Core output was generated via:

    hscore() {
        ghc -ddump-simpl -dsuppress-idinfo -dsuppress-coercions -dsuppress-type-applications -dsuppress-uniques -dsuppress-module-prefixes "$@"
    }
    hscore -O2 Runs.hs > Runs.core

-- 
    Viktor.

From david.feuer at gmail.com  Sun Mar 26 19:53:00 2023
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 26 Mar 2023 15:53:00 -0400
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
 <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
Message-ID: <CAMgWh9uDquy6kx2NWYdJCaB2+i4agqpiOjhE+ZvnUVNNzOZLjg@mail.gmail.com>

I don't know prolog, but I believe the answer to your last question is no.
The functions will actually be function closures in this case. There's no
way to leave a (native) Haskell list open to being extended at the end,
except to the extent that lazy evaluation does so. Somewhat separately,
while it would be possible for a Haskell implementation to construct
strict-spined list-like structures with constant stack space using tail
recursion modulo cons, GHC doesn't do that.

On Sun, Mar 26, 2023, 1:59 PM Todd Wilson <twilson at csufresno.edu> wrote:

> I want to thank all of those who contributed to this thread. If I can
> summarize the contributions (feel free to clarify any misrepresentations):
>
>    - The code I provided for this problem is probably optimal, except
>    perhaps for the small point about using an @-pattern in `run` to avoid
>    reconstructing `y:ys` in the last line -- but isn't this also something the
>    compiler could easily discover and take advantage of without explicit
>    direction?
>    - The compiler will avoid breaking down and reconstructing pairs on
>    each recursive call, even though that is how it is coded.
>    - Although nobody commented on my Prolog version (perhaps because this
>    is a Haskell list!), the point I made there about compiling this as a tail
>    call that doesn't grow the stack should also apply to Haskell (does it?).
>    One thing that's clear from the Prolog code is that it goes down the input
>    list and distributes the elements to one of two places -- the end of the
>    current run or the beginning of a new run -- interspersed with some
>    cons-cell creation. Is that what's happening in Haskell also?
>    - Reference was made to Haskell's `sort` implementation, which
>    essentially finds runs (increasing and decreasing) in the input before
>    repeatedly merging them in pairs until one run remains. Decreasing runs can
>    be turned into increasing ones by using a tail call with a list
>    accumulator, the way iterative reverse works. But increasing runs are
>    handled in the same way that my Prolog code does, essentially by using what
>    appears to be the Haskell equivalent of Prolog's difference-lists:
>    functions whose arguments are the extendible ends of lists.
>
> I'm intrigued by the idea mentioned in this last bullet point. Is this
> functional equivalent of Prolog's difference lists -- essentially partial
> data structures that are grown top-down rather than bottom-up, actually
> efficient? Is there an overhead penalty to be paid for using functions
> here, or is it compiled away into Prolog-like tail calls that fill in the
> missing parts of the data structure?
>
> Todd Wilson
>
> On Thu, Mar 16, 2023 at 6:33 PM Todd Wilson <twilson at csufresno.edu> wrote:
>
>> Dear Cafe,
>>
>> Here's a basic exercise in list processing: define a function
>>
>> runs :: Ord a => [a] -> [[a]]
>>
>> that breaks up its input list into a list of increasing "runs"; e.g.,
>>
>> runs [3,4,5,6,2,3,4,1,2,1]  --->  [[3,4,5,6],[2,3,4],[1,2],[1]]
>>
>> A natural solution is the following:
>>
>> runs [] = []
>> runs (x:xs) = let (ys, zs) = run x xs
>>               in (x:ys) : runs zs
>>   where
>>     run x [] = ([], [])
>>     run x (y:ys) = if x <= y
>>                    then let (us, vs) = run y ys
>>                         in (y:us, vs)
>>                    else ([], y:ys)
>>
>> My question: can we do better than this? It seems that this solution is
>> constantly building and breaking apart pairs. (Or is it, when optimized?)
>>
>> Todd Wilson
>>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230326/fb540e3b/attachment.html>

From keith.wygant at gmail.com  Sun Mar 26 21:33:50 2023
From: keith.wygant at gmail.com (Keith)
Date: Sun, 26 Mar 2023 21:33:50 +0000
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <ZCCX16+jsvlfhDER@straasha.imrryr.org>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
 <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
 <ZCCX16+jsvlfhDER@straasha.imrryr.org>
Message-ID: <CC3BCB14-5B89-4A7B-BA7F-F06E6AAED976@gmail.com>

YMMV, but based on some benchmarking I've done, the default implementation using `compareBy` seems to optimize better than trying to force dictionary unpacking. The only way I've been able to generically sort faster than base's `compareBy` is to use nonempty list structures for runs.
—
Sent from my phone with K-9 Mail.

On 26 March 2023 19:07:03 UTC, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>On Sun, Mar 26, 2023 at 10:59:13AM -0700, Todd Wilson wrote:
>
>> Is there an overhead penalty to be paid for using functions here, or
>> is it compiled away into Prolog-like tail calls that fill in the
>> missing parts of the data structure?
>
>Efficient implementations of functional langauges make extensive use of
>tail call optimisation.
>
>I don't know whether looking at the GHC-generated "Core" for your
>implementation will answer any of your questions, but here it is:
>
>  Haskell:
>    runs (x:xs) = let (ys, zs) = run x xs in (x:ys) : runs zs
>      where
>        run x [] = ([], [])
>        run x (y:ys) = if x <= y
>                       then let (us, vs) = run y ys
>                            in (y:us, vs)
>                       else ([], y:ys)
>
>  Core (with some added comments):
>    -- Unpack the "Ord" dictionary to extract just the required "<="
>    -- function and call the "$wruns" worker ("ww3" is "<=", and "ds"
>    -- is the list to be transformed:
>    --
>    runs :: forall a. Ord a => [a] -> [[a]]
>    runs
>      = \ (@a) ($dOrd :: Ord a) (ds :: [a]) ->
>          case $dOrd of { C:Ord ww ww1 ww2 ww3 ww4 ww5 ww6 ww7 ->
>          $wruns ww3 ds
>          }
>
>    Rec {
>    $wruns :: forall {a}. (a -> a -> Bool) -> [a] -> [[a]]
>    $wruns
>      = \ (@a) (ww :: a -> a -> Bool) (ds :: [a]) ->
>          case ds of {
>            [] -> [];           -- runs [] = []
>            : x xs ->           -- runs (x:xs) = let (ys, zs) = run x xs in (x:ys) : runs zs
>              let {
>                ds1 :: ([a], [a])  -- A lazily evaluated thunk for (run x xs)
>                ds1
>                  = letrec {
>                      -- Internal recursion in "run" returns strict unboxed pairs
>                      -- (on the stack) avoiding heap or thunk allocation for the tuple.
>                      $wrun :: a -> [a] -> (# [a], [a] #)
>                      $wrun
>                        = \ (x1 :: a) (ds2 :: [a]) ->
>                            case ds2 of wild1 {         -- (y:ys) is "wild1"
>                              [] -> (# [], [] #);       -- run x [] = ([], [])
>                              : y ys ->
>                                case ww x1 y of {       -- x <= y ?
>                                  False -> (# [], wild1 #);  -- else ([], y:ys)
>                                  True ->                    -- then let (us, vs) = run y ys in (y:us, vs)
>                                    let {
>                                      ds3 :: ([a], [a])      -- A "thunk" for (run y ys) evaluated lazily
>                                      ds3 = case $wrun y ys of { (# ww1, ww2 #) -> (ww1, ww2) } } in
>                                    (# : y (case ds3 of { (us, vs) -> us }),
>                                       case ds3 of { (us, vs) -> vs } #)
>                                }
>                            }; } in
>                    case $wrun x xs of { (# ww1, ww2 #) -> (ww1, ww2) } } in
>              : (: x (case ds1 of { (ys, zs) -> ys }))
>                (case ds1 of { (ys, zs) -> $wruns ww zs })
>          }
>    end Rec }
>
>So for a non-empty cons-cell (: x ...) the result is a new cons cell:
>
>    : (x : (fst ds1)) (runs (snd ds1))
>           ---------   --------------
>
>in which both underline parts are computed lazily (on demand) from the
>thunk "ds1":
>
>    λ> head $ head $ runs $ 42 : undefined
>    42
>
>When we do want the successor of the first element, we look no futher
>than necessary:
>
>    λ> head $ runs $ 42 : 0 : undefined
>    [42]
>
>    λ> take 2 $ head $ runs $ 42 : 43 : undefined
>    [42,43]
>
>Does this help?  FWIW, the (simplified) Core output was generated via:
>
>    hscore() {
>        ghc -ddump-simpl -dsuppress-idinfo -dsuppress-coercions -dsuppress-type-applications -dsuppress-uniques -dsuppress-module-prefixes "$@"
>    }
>    hscore -O2 Runs.hs > Runs.core
>
>-- 
>    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/20230326/814ab939/attachment.html>

From twilson at csufresno.edu  Sun Mar 26 23:24:09 2023
From: twilson at csufresno.edu (Todd Wilson)
Date: Sun, 26 Mar 2023 16:24:09 -0700
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <ZCCX16+jsvlfhDER@straasha.imrryr.org>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
 <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
 <ZCCX16+jsvlfhDER@straasha.imrryr.org>
Message-ID: <CA+-99oLVfTJtce4piNNOsScgGt32-4AsAAb_uzzcXytY+wZKhA@mail.gmail.com>

Thanks, Viktor, for that information, especially the macro for getting
Haskel core output at the end, which I will try to use in the future and
perhaps avoid having to query this list to get such answers! I have a few
follow-up questions on this code, however:

On Sun, Mar 26, 2023 at 12:07 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> I don't know whether looking at the GHC-generated "Core" for your
> implementation will answer any of your questions, but here it is:
>
>   Haskell:
>     runs (x:xs) = let (ys, zs) = run x xs in (x:ys) : runs zs
>       where
>         run x [] = ([], [])
>         run x (y:ys) = if x <= y
>                        then let (us, vs) = run y ys
>                             in (y:us, vs)
>                        else ([], y:ys)
>
>   Core (with some added comments):
>     -- Unpack the "Ord" dictionary to extract just the required "<="
>     -- function and call the "$wruns" worker ("ww3" is "<=", and "ds"
>     -- is the list to be transformed:
>     --
>     runs :: forall a. Ord a => [a] -> [[a]]
>     runs
>       = \ (@a) ($dOrd :: Ord a) (ds :: [a]) ->
>           case $dOrd of { C:Ord ww ww1 ww2 ww3 ww4 ww5 ww6 ww7 ->
>           $wruns ww3 ds
>           }
>
>     Rec {
>     $wruns :: forall {a}. (a -> a -> Bool) -> [a] -> [[a]]
>     $wruns
>       = \ (@a) (ww :: a -> a -> Bool) (ds :: [a]) ->
>           case ds of {
>             [] -> [];           -- runs [] = []
>             : x xs ->           -- runs (x:xs) = let (ys, zs) = run x xs
> in (x:ys) : runs zs
>               let {
>                 ds1 :: ([a], [a])  -- A lazily evaluated thunk for (run x
> xs)
>                 ds1
>                   = letrec {
>                       -- Internal recursion in "run" returns strict
> unboxed pairs
>                       -- (on the stack) avoiding heap or thunk allocation
> for the tuple.
>                       $wrun :: a -> [a] -> (# [a], [a] #)
>                       $wrun
>                         = \ (x1 :: a) (ds2 :: [a]) ->
>                             case ds2 of wild1 {         -- (y:ys) is
> "wild1"
>                               [] -> (# [], [] #);       -- run x [] = ([],
> [])
>                               : y ys ->
>                                 case ww x1 y of {       -- x <= y ?
>                                   False -> (# [], wild1 #);  -- else ([],
> y:ys)
>                                   True ->                    -- then let
> (us, vs) = run y ys in (y:us, vs)
>                                     let {
>                                       ds3 :: ([a], [a])      -- A "thunk"
> for (run y ys) evaluated lazily
>

Why doesn't ds3 have an explicitly unboxed pair type, and does that have
any performance implications? For example, ...


>                                       ds3 = case $wrun y ys of { (# ww1,
> ww2 #) -> (ww1, ww2) } } in
>                                     (# : y (case ds3 of { (us, vs) -> us
> }),
>                                        case ds3 of { (us, vs) -> vs } #)
>

Granted I'm not that familiar with core, but It sure looks like this code
breaks apart pairs (with the equivalent of fst and snd) and rebuilds them


>                                 }
>                             }; } in
>                     case $wrun x xs of { (# ww1, ww2 #) -> (ww1, ww2) } }
> in
>               : (: x (case ds1 of { (ys, zs) -> ys }))
>                 (case ds1 of { (ys, zs) -> $wruns ww zs })
>           }
>     end Rec }
>
> So for a non-empty cons-cell (: x ...) the result is a new cons cell:
>
>     : (x : (fst ds1)) (runs (snd ds1))
>            ---------   --------------
>
> in which both underline parts are computed lazily (on demand) from the
> thunk "ds1":
>
>     λ> head $ head $ runs $ 42 : undefined
>     42
>
> When we do want the successor of the first element, we look no futher
> than necessary:
>
>     λ> head $ runs $ 42 : 0 : undefined
>     [42]
>
>     λ> take 2 $ head $ runs $ 42 : 43 : undefined
>     [42,43]
>
> Does this help?


Yes, it does, thanks, although I was aware of this aspect of the laziness
of my code from the beginning and was concerned more with how the output
lists were built.


> FWIW, the (simplified) Core output was generated via:
>     hscore() {
>         ghc -ddump-simpl -dsuppress-idinfo -dsuppress-coercions
> -dsuppress-type-applications -dsuppress-uniques -dsuppress-module-prefixes
> "$@"
>     }
>     hscore -O2 Runs.hs > Runs.core
>

Thanks again for this, it will be helpful going forward.

--Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230326/30d8c2da/attachment.html>

From twilson at csufresno.edu  Sun Mar 26 23:52:11 2023
From: twilson at csufresno.edu (Todd Wilson)
Date: Sun, 26 Mar 2023 16:52:11 -0700
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CAMgWh9uDquy6kx2NWYdJCaB2+i4agqpiOjhE+ZvnUVNNzOZLjg@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
 <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
 <CAMgWh9uDquy6kx2NWYdJCaB2+i4agqpiOjhE+ZvnUVNNzOZLjg@mail.gmail.com>
Message-ID: <CA+-99oJkePo1OO1u4y9nZk5A6ANTf0N82Y1cX1=wUS5ttpk-8A@mail.gmail.com>

Interesting. So one consequence of this, if I understand correctly, is that
the aforementioned library implementation
<https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.html#sort>
of `sort` could actually be improved by rewriting the `ascending` function
there so that it returned a pair, as in my code, rather than had a
"difference-list" functional accumulator argument that is finally applied
in the base case.

--Todd

On Sun, Mar 26, 2023 at 12:53 PM David Feuer <david.feuer at gmail.com> wrote:

> I don't know prolog, but I believe the answer to your last question is no.
> The functions will actually be function closures in this case. There's no
> way to leave a (native) Haskell list open to being extended at the end,
> except to the extent that lazy evaluation does so. Somewhat separately,
> while it would be possible for a Haskell implementation to construct
> strict-spined list-like structures with constant stack space using tail
> recursion modulo cons, GHC doesn't do that.
>
> On Sun, Mar 26, 2023, 1:59 PM Todd Wilson <twilson at csufresno.edu> wrote:
>
>> I want to thank all of those who contributed to this thread. If I can
>> summarize the contributions (feel free to clarify any misrepresentations):
>>
>>    - The code I provided for this problem is probably optimal, except
>>    perhaps for the small point about using an @-pattern in `run` to avoid
>>    reconstructing `y:ys` in the last line -- but isn't this also something the
>>    compiler could easily discover and take advantage of without explicit
>>    direction?
>>    - The compiler will avoid breaking down and reconstructing pairs on
>>    each recursive call, even though that is how it is coded.
>>    - Although nobody commented on my Prolog version (perhaps because
>>    this is a Haskell list!), the point I made there about compiling this as a
>>    tail call that doesn't grow the stack should also apply to Haskell (does
>>    it?). One thing that's clear from the Prolog code is that it goes down the
>>    input list and distributes the elements to one of two places -- the end of
>>    the current run or the beginning of a new run -- interspersed with some
>>    cons-cell creation. Is that what's happening in Haskell also?
>>    - Reference was made to Haskell's `sort` implementation, which
>>    essentially finds runs (increasing and decreasing) in the input before
>>    repeatedly merging them in pairs until one run remains. Decreasing runs can
>>    be turned into increasing ones by using a tail call with a list
>>    accumulator, the way iterative reverse works. But increasing runs are
>>    handled in the same way that my Prolog code does, essentially by using what
>>    appears to be the Haskell equivalent of Prolog's difference-lists:
>>    functions whose arguments are the extendible ends of lists.
>>
>> I'm intrigued by the idea mentioned in this last bullet point. Is this
>> functional equivalent of Prolog's difference lists -- essentially partial
>> data structures that are grown top-down rather than bottom-up, actually
>> efficient? Is there an overhead penalty to be paid for using functions
>> here, or is it compiled away into Prolog-like tail calls that fill in the
>> missing parts of the data structure?
>>
>> Todd Wilson
>>
>> On Thu, Mar 16, 2023 at 6:33 PM Todd Wilson <twilson at csufresno.edu>
>> wrote:
>>
>>> Dear Cafe,
>>>
>>> Here's a basic exercise in list processing: define a function
>>>
>>> runs :: Ord a => [a] -> [[a]]
>>>
>>> that breaks up its input list into a list of increasing "runs"; e.g.,
>>>
>>> runs [3,4,5,6,2,3,4,1,2,1]  --->  [[3,4,5,6],[2,3,4],[1,2],[1]]
>>>
>>> A natural solution is the following:
>>>
>>> runs [] = []
>>> runs (x:xs) = let (ys, zs) = run x xs
>>>               in (x:ys) : runs zs
>>>   where
>>>     run x [] = ([], [])
>>>     run x (y:ys) = if x <= y
>>>                    then let (us, vs) = run y ys
>>>                         in (y:us, vs)
>>>                    else ([], y:ys)
>>>
>>> My question: can we do better than this? It seems that this solution is
>>> constantly building and breaking apart pairs. (Or is it, when optimized?)
>>>
>>> Todd Wilson
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20230326/0278fd78/attachment.html>

From ietf-dane at dukhovni.org  Mon Mar 27 00:00:34 2023
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 26 Mar 2023 20:00:34 -0400
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <CA+-99oLVfTJtce4piNNOsScgGt32-4AsAAb_uzzcXytY+wZKhA@mail.gmail.com>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
 <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
 <ZCCX16+jsvlfhDER@straasha.imrryr.org>
 <CA+-99oLVfTJtce4piNNOsScgGt32-4AsAAb_uzzcXytY+wZKhA@mail.gmail.com>
Message-ID: <ZCDcogSZffG92SZz@straasha.imrryr.org>

On Sun, Mar 26, 2023 at 04:24:09PM -0700, Todd Wilson wrote:

> >   Core (with some added comments):
> >     -- Unpack the "Ord" dictionary to extract just the required "<="
> >     -- function and call the "$wruns" worker ("ww3" is "<=", and "ds"
> >     -- is the list to be transformed:
> >     --
> >     runs :: forall a. Ord a => [a] -> [[a]]
> >     runs
> >       = \ (@a) ($dOrd :: Ord a) (ds :: [a]) ->
> >           case $dOrd of { C:Ord ww ww1 ww2 ww3 ww4 ww5 ww6 ww7 ->
> >           $wruns ww3 ds
> >           }
> >
> >     Rec {
> >     $wruns :: forall {a}. (a -> a -> Bool) -> [a] -> [[a]]
> >     $wruns
> >       = \ (@a) (ww :: a -> a -> Bool) (ds :: [a]) ->
> >           case ds of {
> >             [] -> [];           -- runs [] = []
> >             : x xs ->           -- runs (x:xs) = let (ys, zs) = run x xs in (x:ys) : runs zs
> >               let {
> >                 ds1 :: ([a], [a])  -- A lazily evaluated thunk for (run x xs)
> >                 ds1
> >                   = letrec {
> >                       -- Internal recursion in "run" returns strict unboxed pairs
> >                       -- (on the stack) avoiding heap or thunk allocation for the tuple.
> >                       $wrun :: a -> [a] -> (# [a], [a] #)
> >                       $wrun
> >                         = \ (x1 :: a) (ds2 :: [a]) ->
> >                             case ds2 of wild1 {         -- (y:ys) is "wild1"
> >                               [] -> (# [], [] #);       -- run x [] = ([], [])
> >                               : y ys ->
> >                                 case ww x1 y of {       -- x <= y ?
> >                                   False -> (# [], wild1 #);  -- else ([], y:ys)
> >                                   True ->                    -- then let (us, vs) = run y ys in (y:us, vs)
> >                                     let {
> >                                       ds3 :: ([a], [a])      -- A "thunk" for (run y ys) evaluated lazily
> >
> 
> Why doesn't ds3 have an explicitly unboxed pair type, and does that have
> any performance implications? For example, ...

Precisely because "ds3" must be evaluated lazily, it can't be an unboxed
pair (which are always strictly evaluated).

> >                                       ds3 = case $wrun y ys of { (# ww1, ww2 #) -> (ww1, ww2) } } in
> >                                     (# : y (case ds3 of { (us, vs) -> us }),
> >                                        case ds3 of { (us, vs) -> vs } #)

> Granted I'm not that familiar with Core, but It sure looks like this code
> breaks apart pairs (with the equivalent of fst and snd) and rebuilds them

The inner (recursive) invocation of "run" must also be lazily evaluated,
so yes, its output needs to be boxed as a pair.


> > When we do want the successor of the first element, we look no futher
> > than necessary:
> >
> >     λ> head $ runs $ 42 : 0 : undefined
> >     [42]
> >
> >     λ> take 2 $ head $ runs $ 42 : 43 : undefined
> >     [42,43]
> >
> > Does this help?
> 
> Yes, it does, thanks, although I was aware of this aspect of the laziness
> of my code from the beginning and was concerned more with how the output
> lists were built.

As with all lists, they are built via the (:) constructor from a head
element and a tail.  GHC reuses any full list or tail it can reuse, and
constructs new cons cells that are not already in hand.

Because these are pure functions working with immutable data, to
construct an initial segment of a list we must build a new list, we
can't truncate the original original in place, it is immutable.

Therefore, the original list will be picked apart and reassembled.

With "linear Haskell" there are in some cases opportunities to mutate
certain objects in place, because they are sure to not have any other
references.  But that isn't the case here.

So even `runs [0..10]` has to pick apart and reassemble the list.  I
hope I understood correctly what you're getting at with the concern
about building and rebuilding.

It looks to me like the Core code does exactly as much building and
re-building as required by laziness, and the result can be consumed in a
single pass in constant space (multi-pass use naturally memoises the
result).

-- 
    Viktor.

From david.feuer at gmail.com  Mon Mar 27 00:19:26 2023
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 26 Mar 2023 20:19:26 -0400
Subject: [Haskell-cafe] Basic list exercise
In-Reply-To: <ZCDcogSZffG92SZz@straasha.imrryr.org>
References: <CA+-99oK7GtOL9KRPR3ni=SKPPX4F6vN7XsU7r_JYJfkm6rmXxw@mail.gmail.com>
 <CA+-99oJkcv_is9FGRtqPLXJbgqZgkaM0CaHuvWEEr8aj2zq=hA@mail.gmail.com>
 <ZCCX16+jsvlfhDER@straasha.imrryr.org>
 <CA+-99oLVfTJtce4piNNOsScgGt32-4AsAAb_uzzcXytY+wZKhA@mail.gmail.com>
 <ZCDcogSZffG92SZz@straasha.imrryr.org>
Message-ID: <CAMgWh9vr2_xswoKMdULx5+Eg5H+8SFHpTbwB7okZ8+cGHhZ5zg@mail.gmail.com>

Linear Haskell helps control in-place mutation, but that's still only in
mutable references and arrays. As I understand it, data built from regular
constructors is more fundamentally immutable because of the way GHC garbage
collection works.

On Sun, Mar 26, 2023, 8:00 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Sun, Mar 26, 2023 at 04:24:09PM -0700, Todd Wilson wrote:
>
> > >   Core (with some added comments):
> > >     -- Unpack the "Ord" dictionary to extract just the required "<="
> > >     -- function and call the "$wruns" worker ("ww3" is "<=", and "ds"
> > >     -- is the list to be transformed:
> > >     --
> > >     runs :: forall a. Ord a => [a] -> [[a]]
> > >     runs
> > >       = \ (@a) ($dOrd :: Ord a) (ds :: [a]) ->
> > >           case $dOrd of { C:Ord ww ww1 ww2 ww3 ww4 ww5 ww6 ww7 ->
> > >           $wruns ww3 ds
> > >           }
> > >
> > >     Rec {
> > >     $wruns :: forall {a}. (a -> a -> Bool) -> [a] -> [[a]]
> > >     $wruns
> > >       = \ (@a) (ww :: a -> a -> Bool) (ds :: [a]) ->
> > >           case ds of {
> > >             [] -> [];           -- runs [] = []
> > >             : x xs ->           -- runs (x:xs) = let (ys, zs) = run x
> xs in (x:ys) : runs zs
> > >               let {
> > >                 ds1 :: ([a], [a])  -- A lazily evaluated thunk for
> (run x xs)
> > >                 ds1
> > >                   = letrec {
> > >                       -- Internal recursion in "run" returns strict
> unboxed pairs
> > >                       -- (on the stack) avoiding heap or thunk
> allocation for the tuple.
> > >                       $wrun :: a -> [a] -> (# [a], [a] #)
> > >                       $wrun
> > >                         = \ (x1 :: a) (ds2 :: [a]) ->
> > >                             case ds2 of wild1 {         -- (y:ys) is
> "wild1"
> > >                               [] -> (# [], [] #);       -- run x [] =
> ([], [])
> > >                               : y ys ->
> > >                                 case ww x1 y of {       -- x <= y ?
> > >                                   False -> (# [], wild1 #);  -- else
> ([], y:ys)
> > >                                   True ->                    -- then
> let (us, vs) = run y ys in (y:us, vs)
> > >                                     let {
> > >                                       ds3 :: ([a], [a])      -- A
> "thunk" for (run y ys) evaluated lazily
> > >
> >
> > Why doesn't ds3 have an explicitly unboxed pair type, and does that have
> > any performance implications? For example, ...
>
> Precisely because "ds3" must be evaluated lazily, it can't be an unboxed
> pair (which are always strictly evaluated).
>
> > >                                       ds3 = case $wrun y ys of { (#
> ww1, ww2 #) -> (ww1, ww2) } } in
> > >                                     (# : y (case ds3 of { (us, vs) ->
> us }),
> > >                                        case ds3 of { (us, vs) -> vs }
> #)
>
> > Granted I'm not that familiar with Core, but It sure looks like this code
> > breaks apart pairs (with the equivalent of fst and snd) and rebuilds them
>
> The inner (recursive) invocation of "run" must also be lazily evaluated,
> so yes, its output needs to be boxed as a pair.
>
>
> > > When we do want the successor of the first element, we look no futher
> > > than necessary:
> > >
> > >     λ> head $ runs $ 42 : 0 : undefined
> > >     [42]
> > >
> > >     λ> take 2 $ head $ runs $ 42 : 43 : undefined
> > >     [42,43]
> > >
> > > Does this help?
> >
> > Yes, it does, thanks, although I was aware of this aspect of the laziness
> > of my code from the beginning and was concerned more with how the output
> > lists were built.
>
> As with all lists, they are built via the (:) constructor from a head
> element and a tail.  GHC reuses any full list or tail it can reuse, and
> constructs new cons cells that are not already in hand.
>
> Because these are pure functions working with immutable data, to
> construct an initial segment of a list we must build a new list, we
> can't truncate the original original in place, it is immutable.
>
> Therefore, the original list will be picked apart and reassembled.
>
> With "linear Haskell" there are in some cases opportunities to mutate
> certain objects in place, because they are sure to not have any other
> references.  But that isn't the case here.
>
> So even `runs [0..10]` has to pick apart and reassemble the list.  I
> hope I understood correctly what you're getting at with the concern
> about building and rebuilding.
>
> It looks to me like the Core code does exactly as much building and
> re-building as required by laziness, and the result can be consumed in a
> single pass in constant space (multi-pass use naturally memoises the
> result).
>
> --
>     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/20230326/62e8ff88/attachment-0001.html>

From tom.schrijvers at kuleuven.be  Mon Mar 27 08:59:54 2023
From: tom.schrijvers at kuleuven.be (Tom Schrijvers)
Date: Mon, 27 Mar 2023 08:59:54 +0000
Subject: [Haskell-cafe] PhD Position at KU Leuven
Message-ID: <B9654ABA-CF08-4F92-80C5-14BE7430641A@kuleuven.be>

Dear Haskell Cafe,

Are you a highly motivated individual with a passion for programming languages and theory? Do you hold a master's degree in computer science or a related field and have a proven academic track record? If so, we invite you to apply for the PhD Position in Programming Languages at KU Leuven. In this position, you will join the team of Professor Tom Schrijvers, which has a strong reputation in programming language research, covering topics such as functional programming, domain-specific languages, and equational reasoning. Your research will focus on multi-stage programming and computational effects, with the aim of developing a formal calculus for multi-staging with support for algebraic effects and handlers. You will benefit from a competitive monthly stipend, an exciting interdisciplinary research environment, and the opportunity to attend international conferences and collaborate with international partners. Apply now and advance the state-of-the-art in programming language research.

For more information and applications, see:
https://www.kuleuven.be/personeel/jobsite/jobs/60203785?hl=en&lang=en

Best,

Tom Schrijvers


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

From leah at vuxu.org  Mon Mar 27 10:24:52 2023
From: leah at vuxu.org (Leah Neukirchen)
Date: Mon, 27 Mar 2023 12:24:52 +0200
Subject: [Haskell-cafe] Munich Haskell Meeting, 2023-03-29 @ 19:30
Message-ID: <875yamtrt7.fsf@vuxu.org>

Dear all,

This week, our monthly Munich Haskell Meeting will take place again on
Wednesday, March 29 at Augustiner-Gaststätte Rumpler at 19h30.
For details see here:

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

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

https://nuudel.digitalcourage.de/21as1kuu1eUg8qTt

Everybody is welcome!

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

From mmcconnell17704 at yahoo.com  Mon Mar 27 21:34:38 2023
From: mmcconnell17704 at yahoo.com (Mark McConnell)
Date: Mon, 27 Mar 2023 21:34:38 +0000 (UTC)
Subject: [Haskell-cafe] Munich Haskell Meeting, 2023-03-29 @ 19:30
In-Reply-To: <875yamtrt7.fsf@vuxu.org>
References: <875yamtrt7.fsf@vuxu.org>
Message-ID: <657094966.841762.1679952878683@mail.yahoo.com>

 Ach, wir weinen, those of us who can't be there in Munich for good beer and Haskell discussion.  Have a great meeting!
    On Monday, March 27, 2023 at 06:25:34 AM EDT, Leah Neukirchen <leah at vuxu.org> wrote:  
 
 Dear all,

This week, our monthly Munich Haskell Meeting will take place again on
Wednesday, March 29 at Augustiner-Gaststätte Rumpler at 19h30.
For details see here:

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

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

https://nuudel.digitalcourage.de/21as1kuu1eUg8qTt

Everybody is welcome!

cu,
-- 
Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view 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/20230327/de075bb4/attachment.html>

From zubin at well-typed.com  Fri Mar 31 05:42:22 2023
From: zubin at well-typed.com (Zubin Duggal)
Date: Fri, 31 Mar 2023 11:12:22 +0530
Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] Haskell Language Server
	1.10.0.0 released
Message-ID: <6kkhoow2k76y7e6jhwtqjqcbwk7kbfshvrzgq7btyp5hcm2rt6@zilog2k47fqh>

Binaries for this release are available at https://downloads.haskell.org/~hls/haskell-language-server-1.10.0.0/. 

These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/) or version [2.0.0 and above](https://github.com/haskell/vscode-haskell/releases) of the VSCode extension. Older versions of the VSCode extension will not attempt to download this version.

# Changelog

- Support for GHC 9.6
- Binaries for GHC 9.2.7 and GHC 9.6.1
- Eval plugin support for GHC 9.4+ (#3391)
- Don't show lenses for TH generated instances when using hls-class-plugin (#3531)

For the full release notes, see https://github.com/haskell/haskell-language-server/releases/tag/1.10.0.0

Happy editing!
- Zubin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/b1592b26/attachment.sig>

From djsamperi at gmail.com  Fri Mar 31 14:33:26 2023
From: djsamperi at gmail.com (Dominick Samperi)
Date: Fri, 31 Mar 2023 10:33:26 -0400
Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] Haskell Language Server
 1.10.0.0 released
In-Reply-To: <6kkhoow2k76y7e6jhwtqjqcbwk7kbfshvrzgq7btyp5hcm2rt6@zilog2k47fqh>
References: <6kkhoow2k76y7e6jhwtqjqcbwk7kbfshvrzgq7btyp5hcm2rt6@zilog2k47fqh>
Message-ID: <CADUbQ5jEXigH8+2OgXwAb2N17dJ-2MUmWMW1onJHzR1H9kU2iQ@mail.gmail.com>

There are several GHC extensions in VScode, which one? I have installed
ghcup under Ubuntu.

On Fri, Mar 31, 2023 at 1:42 AM Zubin Duggal <zubin at well-typed.com> wrote:

> Binaries for this release are available at
> https://downloads.haskell.org/~hls/haskell-language-server-1.10.0.0/.
>
> These binaries can be installed using [GHCup](
> https://www.haskell.org/ghcup/) or version [2.0.0 and above](
> https://github.com/haskell/vscode-haskell/releases) of the VSCode
> extension. Older versions of the VSCode extension will not attempt to
> download this version.
>
> # Changelog
>
> - Support for GHC 9.6
> - Binaries for GHC 9.2.7 and GHC 9.6.1
> - Eval plugin support for GHC 9.4+ (#3391)
> - Don't show lenses for TH generated instances when using hls-class-plugin
> (#3531)
>
> For the full release notes, see
> https://github.com/haskell/haskell-language-server/releases/tag/1.10.0.0
>
> Happy editing!
> - Zubin
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230331/3fc46809/attachment.html>

From guthrie at miu.edu  Fri Mar 31 20:02:49 2023
From: guthrie at miu.edu (Gregory Guthrie)
Date: Fri, 31 Mar 2023 20:02:49 +0000
Subject: [Haskell-cafe] GPT & Haskell
Message-ID: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>

>From a colleague:
  GPT Pretty smart(?!).
But this is of course simple, and searchable.

Still...
--------------------------------------------------------------------------------------------------
GPT-4 when prompted:
Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states.

gives the following response:
-- Binary search in Haskell
-- Precondition: the list is sorted in ascending order
-- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
-- Invariant: the search space is always within the bounds of the list
-- Variant: the search space decreases by half at each recursive call
-- Internal state: the lower and upper bounds of the search space

binarySearch :: Ord a => [a] -> a -> Maybe Int
binarySearch xs x = go xs x 0 (length xs - 1)
  where
    go xs x lo hi
      | lo > hi = Nothing -- base case: search space is empty
      | x == midElem = Just mid -- base case: target element is found
      | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
      | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
      where
        mid = (lo + hi) `div` 2 -- calculate the middle index
        midElem = xs !! mid -- get the middle element

-- Print results using putStrLn
main :: IO ()
main = do
  let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
  let x = 5 -- a target element to search for
  let result = binarySearch xs x -- call the binary search function
  case result of -- pattern match on the result
    Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
    Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned

The above code runs:
https://onecompiler.com/cpp/3z48yt2pp


[cid:image001.png at 01D963E1.B0EB6AB0]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/184369a8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39081 bytes
Desc: image001.png
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/184369a8/attachment.png>

From jeffbrown.the at gmail.com  Fri Mar 31 20:33:31 2023
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Fri, 31 Mar 2023 15:33:31 -0500
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
Message-ID: <CAEc4Ma2BDbRCg2ymv5MzLjKvLJvfLkLjZnQ4DpzOWDwmAJijhQ@mail.gmail.com>

For toy problems they can impress, but getting an LLM to understand a
realistic codebase well enough to generate useful changes seems impossible.

On Fri, Mar 31, 2023 at 3:04 PM Gregory Guthrie <guthrie at miu.edu> wrote:

> From a colleague:
>
>   GPT Pretty smart(?!).
>
> But this is of course simple, and searchable.
>
>
>
> Still…
>
>
> --------------------------------------------------------------------------------------------------
>
> GPT-4 when prompted:
>
> *Write binary search in Haskel. Print results using putStrLn. Ensure
> bug-free code by specifying preconditions, postconditions, invariants,
> variants, internal states.*
>
>
>
> gives the following response:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *-- Binary search in Haskell -- Precondition: the list is sorted in
> ascending order -- Postcondition: the function returns the index of the
> target element if found, or Nothing otherwise -- Invariant: the search
> space is always within the bounds of the list -- Variant: the search space
> decreases by half at each recursive call -- Internal state: the lower and
> upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe
> Int binarySearch xs x = go xs x 0 (length xs - 1)   where     go xs x lo hi
>       | lo > hi = Nothing -- base case: search space is empty       | x ==
> midElem = Just mid -- base case: target element is found       | x <
> midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
>     | otherwise = go xs x (mid + 1) hi -- recursive case: search in the
> right half       where         mid = (lo + hi) `div` 2 -- calculate the
> middle index         midElem = xs !! mid -- get the middle element -- Print
> results using putStrLn main :: IO () main = do   let xs = [1, 3, 5, 7, 9]
> -- a sorted list of integers   let x = 5 -- a target element to search for
>   let result = binarySearch xs x -- call the binary search function   case
> result of -- pattern match on the result     Nothing -> putStrLn "Element
> not found" -- print a message if Nothing is returned     Just i -> putStrLn
> $ "Element found at index " ++ show i -- print a message with the index if
> Just i is returned*
>
>
>
> The above code runs:
>
> *https://onecompiler.com/cpp/3z48yt2pp
> <https://onecompiler.com/cpp/3z48yt2pp>*
>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>


-- 
Jeff Brown | Jeffrey Benjamin Brown
LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>   |   Github
<https://github.com/jeffreybenjaminbrown>   |   Twitter
<https://twitter.com/carelogic>  |  Facebook
<https://www.facebook.com/mejeff.younotjeff>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/0e004f68/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39081 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/0e004f68/attachment-0001.png>

From allbery.b at gmail.com  Fri Mar 31 20:40:25 2023
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 31 Mar 2023 16:40:25 -0400
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAEc4Ma2BDbRCg2ymv5MzLjKvLJvfLkLjZnQ4DpzOWDwmAJijhQ@mail.gmail.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
 <CAEc4Ma2BDbRCg2ymv5MzLjKvLJvfLkLjZnQ4DpzOWDwmAJijhQ@mail.gmail.com>
Message-ID: <CAKFCL4Vk+K-0s_w0CxJfXfC-au5F7aW9N5QWYPW9823KQA75iA@mail.gmail.com>

We tried to get it to rewrite XMonad.Layout.PerScreen to properly work per
screen instead of the `ifWidth` hack. (It can use the passed-in screen
rectangle to do this.) It didn't even understand the question.

On Fri, Mar 31, 2023 at 4:34 PM Jeffrey Brown <jeffbrown.the at gmail.com>
wrote:

> For toy problems they can impress, but getting an LLM to understand a
> realistic codebase well enough to generate useful changes seems impossible.
>
> On Fri, Mar 31, 2023 at 3:04 PM Gregory Guthrie <guthrie at miu.edu> wrote:
>
>> From a colleague:
>>
>>   GPT Pretty smart(?!).
>>
>> But this is of course simple, and searchable.
>>
>>
>>
>> Still…
>>
>>
>> --------------------------------------------------------------------------------------------------
>>
>> GPT-4 when prompted:
>>
>> *Write binary search in Haskel. Print results using putStrLn. Ensure
>> bug-free code by specifying preconditions, postconditions, invariants,
>> variants, internal states.*
>>
>>
>>
>> gives the following response:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *-- Binary search in Haskell -- Precondition: the list is sorted in
>> ascending order -- Postcondition: the function returns the index of the
>> target element if found, or Nothing otherwise -- Invariant: the search
>> space is always within the bounds of the list -- Variant: the search space
>> decreases by half at each recursive call -- Internal state: the lower and
>> upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe
>> Int binarySearch xs x = go xs x 0 (length xs - 1)   where     go xs x lo hi
>>       | lo > hi = Nothing -- base case: search space is empty       | x ==
>> midElem = Just mid -- base case: target element is found       | x <
>> midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
>>     | otherwise = go xs x (mid + 1) hi -- recursive case: search in the
>> right half       where         mid = (lo + hi) `div` 2 -- calculate the
>> middle index         midElem = xs !! mid -- get the middle element -- Print
>> results using putStrLn main :: IO () main = do   let xs = [1, 3, 5, 7, 9]
>> -- a sorted list of integers   let x = 5 -- a target element to search for
>>   let result = binarySearch xs x -- call the binary search function   case
>> result of -- pattern match on the result     Nothing -> putStrLn "Element
>> not found" -- print a message if Nothing is returned     Just i -> putStrLn
>> $ "Element found at index " ++ show i -- print a message with the index if
>> Just i is returned*
>>
>>
>>
>> The above code runs:
>>
>> *https://onecompiler.com/cpp/3z48yt2pp
>> <https://onecompiler.com/cpp/3z48yt2pp>*
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>
>
> --
> Jeff Brown | Jeffrey Benjamin Brown
> LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>   |   Github
> <https://github.com/jeffreybenjaminbrown>   |   Twitter
> <https://twitter.com/carelogic>  |  Facebook
> <https://www.facebook.com/mejeff.younotjeff>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230331/a3310bd3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39081 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/a3310bd3/attachment.png>

From guthrie at miu.edu  Fri Mar 31 21:15:58 2023
From: guthrie at miu.edu (Gregory Guthrie)
Date: Fri, 31 Mar 2023 21:15:58 +0000
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAEc4Ma2BDbRCg2ymv5MzLjKvLJvfLkLjZnQ4DpzOWDwmAJijhQ@mail.gmail.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
 <CAEc4Ma2BDbRCg2ymv5MzLjKvLJvfLkLjZnQ4DpzOWDwmAJijhQ@mail.gmail.com>
Message-ID: <CH2PR03MB5224FFFCA7E994557E7540C3A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>

Yep! Programmers still have jobs.

Designers even more.

Dr. Gregory Guthrie

From: Jeffrey Brown <jeffbrown.the at gmail.com>
Sent: Friday, March 31, 2023 3:34 PM
To: Gregory Guthrie <guthrie at miu.edu>
Cc: haskell-cafe at haskell.org; Nenad Končar <nlpresearcher at gmail.com>; Haskell Community <replies+f6607596e3ee63f105e2b0327b86f062 at discourse.haskell.org>
Subject: Re: [Haskell-cafe] GPT & Haskell

For toy problems they can impress, but getting an LLM to understand a realistic codebase well enough to generate useful changes seems impossible.

On Fri, Mar 31, 2023 at 3:04 PM Gregory Guthrie <guthrie at miu.edu<mailto:guthrie at miu.edu>> wrote:
From a colleague:
  GPT Pretty smart(?!).
But this is of course simple, and searchable.

Still…
--------------------------------------------------------------------------------------------------
GPT-4 when prompted:
Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states.

gives the following response:
-- Binary search in Haskell
-- Precondition: the list is sorted in ascending order
-- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
-- Invariant: the search space is always within the bounds of the list
-- Variant: the search space decreases by half at each recursive call
-- Internal state: the lower and upper bounds of the search space

binarySearch :: Ord a => [a] -> a -> Maybe Int
binarySearch xs x = go xs x 0 (length xs - 1)
  where
    go xs x lo hi
      | lo > hi = Nothing -- base case: search space is empty
      | x == midElem = Just mid -- base case: target element is found
      | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
      | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
      where
        mid = (lo + hi) `div` 2 -- calculate the middle index
        midElem = xs !! mid -- get the middle element

-- Print results using putStrLn
main :: IO ()
main = do
  let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
  let x = 5 -- a target element to search for
  let result = binarySearch xs x -- call the binary search function
  case result of -- pattern match on the result
    Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
    Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned

The above code runs:
https://onecompiler.com/cpp/3z48yt2pp


[cid:image001.png at 01D963E7.7BCC1DB0]

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


--
Jeff Brown | Jeffrey Benjamin Brown
LinkedIn<https://www.linkedin.com/in/jeffreybenjaminbrown>   |   Github<https://github.com/jeffreybenjaminbrown>   |   Twitter<https://twitter.com/carelogic>  |  Facebook<https://www.facebook.com/mejeff.younotjeff>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/fa515885/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39081 bytes
Desc: image001.png
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/fa515885/attachment-0001.png>

From will.yager at gmail.com  Fri Mar 31 21:17:13 2023
From: will.yager at gmail.com (William Yager)
Date: Fri, 31 Mar 2023 17:17:13 -0400
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAKFCL4Vk+K-0s_w0CxJfXfC-au5F7aW9N5QWYPW9823KQA75iA@mail.gmail.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
 <CAEc4Ma2BDbRCg2ymv5MzLjKvLJvfLkLjZnQ4DpzOWDwmAJijhQ@mail.gmail.com>
 <CAKFCL4Vk+K-0s_w0CxJfXfC-au5F7aW9N5QWYPW9823KQA75iA@mail.gmail.com>
Message-ID: <CAG8oi1O4_05z0SVwgj44HGp_=3xDJC_g6JveG=xNoEBALaaxdg@mail.gmail.com>

I found it to be quite good at questions without too large of a
question-specific context. E.g. it can easily solve questions like "Write a
`Functor` instance for `data Foo a = Bar a | Baz a a` and prove it obeys
the functor laws.".

No doubt the models will get better at handling larger problems as they are
scaled up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/d1a3426a/attachment.html>

From erkokl at gmail.com  Fri Mar 31 21:24:13 2023
From: erkokl at gmail.com (Levent Erkok)
Date: Fri, 31 Mar 2023 14:24:13 -0700
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
Message-ID: <57707B72-65B5-4D58-B49D-9759B3A98A84@gmail.com>

This code is buggy when lo + hi overflows your integer type. Classic (extremely) corner  case bug: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html

> On Mar 31, 2023, at 1:02 PM, Gregory Guthrie <guthrie at miu.edu> wrote:
> 
> From a colleague:
>   GPT Pretty smart(?!).
> But this is of course simple, and searchable.
>  
> Still…
> --------------------------------------------------------------------------------------------------
> GPT-4 when prompted:
> 
> Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states.
>  
> gives the following response:
> 
> -- Binary search in Haskell
> -- Precondition: the list is sorted in ascending order
> -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
> -- Invariant: the search space is always within the bounds of the list
> -- Variant: the search space decreases by half at each recursive call
> -- Internal state: the lower and upper bounds of the search space
> 
> binarySearch :: Ord a => [a] -> a -> Maybe Int
> binarySearch xs x = go xs x 0 (length xs - 1)
>   where
>     go xs x lo hi
>       | lo > hi = Nothing -- base case: search space is empty
>       | x == midElem = Just mid -- base case: target element is found
>       | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
>       | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
>       where
>         mid = (lo + hi) `div` 2 -- calculate the middle index
>         midElem = xs !! mid -- get the middle element
> 
> -- Print results using putStrLn
> main :: IO ()
> main = do
>   let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
>   let x = 5 -- a target element to search for
>   let result = binarySearch xs x -- call the binary search function
>   case result of -- pattern match on the result
>     Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
>     Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned
>  
> The above code runs:
> 
> https://onecompiler.com/cpp/3z48yt2pp
>  
>  
> <image001.png>
>  
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230331/a97f6caa/attachment.html>

From david.feuer at gmail.com  Fri Mar 31 21:29:38 2023
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 31 Mar 2023 17:29:38 -0400
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
Message-ID: <CAMgWh9thM=pEnoA2NQ4bnXVS-UAojufPczEHBFagHFpd=p-JWg@mail.gmail.com>

How does it do with explaining how purely functional catenable deques work?

On Fri, Mar 31, 2023, 4:03 PM Gregory Guthrie <guthrie at miu.edu> wrote:

> From a colleague:
>
>   GPT Pretty smart(?!).
>
> But this is of course simple, and searchable.
>
>
>
> Still…
>
>
> --------------------------------------------------------------------------------------------------
>
> GPT-4 when prompted:
>
> *Write binary search in Haskel. Print results using putStrLn. Ensure
> bug-free code by specifying preconditions, postconditions, invariants,
> variants, internal states.*
>
>
>
> gives the following response:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *-- Binary search in Haskell -- Precondition: the list is sorted in
> ascending order -- Postcondition: the function returns the index of the
> target element if found, or Nothing otherwise -- Invariant: the search
> space is always within the bounds of the list -- Variant: the search space
> decreases by half at each recursive call -- Internal state: the lower and
> upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe
> Int binarySearch xs x = go xs x 0 (length xs - 1)   where     go xs x lo hi
>       | lo > hi = Nothing -- base case: search space is empty       | x ==
> midElem = Just mid -- base case: target element is found       | x <
> midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
>     | otherwise = go xs x (mid + 1) hi -- recursive case: search in the
> right half       where         mid = (lo + hi) `div` 2 -- calculate the
> middle index         midElem = xs !! mid -- get the middle element -- Print
> results using putStrLn main :: IO () main = do   let xs = [1, 3, 5, 7, 9]
> -- a sorted list of integers   let x = 5 -- a target element to search for
>   let result = binarySearch xs x -- call the binary search function   case
> result of -- pattern match on the result     Nothing -> putStrLn "Element
> not found" -- print a message if Nothing is returned     Just i -> putStrLn
> $ "Element found at index " ++ show i -- print a message with the index if
> Just i is returned*
>
>
>
> The above code runs:
>
> *https://onecompiler.com/cpp/3z48yt2pp
> <https://onecompiler.com/cpp/3z48yt2pp>*
>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230331/fda0d4f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39081 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/fda0d4f5/attachment.png>

From yasu at yasuaki.com  Fri Mar 31 21:37:59 2023
From: yasu at yasuaki.com (Yasuaki Kudo)
Date: Sat, 1 Apr 2023 06:37:59 +0900
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <57707B72-65B5-4D58-B49D-9759B3A98A84@gmail.com>
References: <57707B72-65B5-4D58-B49D-9759B3A98A84@gmail.com>
Message-ID: <1B7B8480-E66E-4EF2-96EF-17E30826E2A7@yasuaki.com>

I am really curious - is it possible to create a programming language designed from the ground up to be used by GPT and similar tools?

- Easy to specify the desired outcome
- Easy to verify results

I tried GPT4 to produce COQ proofs of Yoneda Lemma but it could not even complete the interfaces (without implementation) - they failed to compile, by being tripped up by implicit parameters etc.

But GPT4 gets much closer to completion compared to GPT3.5

I wonder what "GPT-native" programming language might look like😄

-Yasu



> On Apr 1, 2023, at 06:24, Levent Erkok <erkokl at gmail.com> wrote:
> 
> This code is buggy when lo + hi overflows your integer type. Classic (extremely) corner  case bug: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
> 
>> On Mar 31, 2023, at 1:02 PM, Gregory Guthrie <guthrie at miu.edu> wrote:
>> 
>> From a colleague:
>>   GPT Pretty smart(?!).
>> But this is of course simple, and searchable.
>>  
>> Still…
>> --------------------------------------------------------------------------------------------------
>> GPT-4 when prompted:
>> 
>> Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states.
>>  
>> gives the following response:
>> 
>> -- Binary search in Haskell
>> -- Precondition: the list is sorted in ascending order
>> -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
>> -- Invariant: the search space is always within the bounds of the list
>> -- Variant: the search space decreases by half at each recursive call
>> -- Internal state: the lower and upper bounds of the search space
>> 
>> binarySearch :: Ord a => [a] -> a -> Maybe Int
>> binarySearch xs x = go xs x 0 (length xs - 1)
>>   where
>>     go xs x lo hi
>>       | lo > hi = Nothing -- base case: search space is empty
>>       | x == midElem = Just mid -- base case: target element is found
>>       | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
>>       | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
>>       where
>>         mid = (lo + hi) `div` 2 -- calculate the middle index
>>         midElem = xs !! mid -- get the middle element
>> 
>> -- Print results using putStrLn
>> main :: IO ()
>> main = do
>>   let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
>>   let x = 5 -- a target element to search for
>>   let result = binarySearch xs x -- call the binary search function
>>   case result of -- pattern match on the result
>>     Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
>>     Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned
>>  
>> The above code runs:
>> 
>> https://onecompiler.com/cpp/3z48yt2pp
>>  
>>  
>> <image001.png>
>>  
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view 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/20230401/04557e03/attachment-0001.html>

From branimir.maksimovic at gmail.com  Fri Mar 31 21:42:35 2023
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Fri, 31 Mar 2023 23:42:35 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <1B7B8480-E66E-4EF2-96EF-17E30826E2A7@yasuaki.com>
References: <57707B72-65B5-4D58-B49D-9759B3A98A84@gmail.com>
 <1B7B8480-E66E-4EF2-96EF-17E30826E2A7@yasuaki.com>
Message-ID: <8F2A4090-CF73-4888-A064-7078019D5E6A@gmail.com>

I was thoughtt from my mathematic logic proffesor in 1987 that algorithm for making algorithms
doesn’t exist. He proved that there is no algorihm for provin hieor order logic formulas…

Greets, Branmir.

> On 31. 3. 2023., at 23:37, Yasuaki Kudo <yasu at yasuaki.com> wrote:
> 
> I am really curious - is it possible to create a programming language designed from the ground up to be used by GPT and similar tools?
> 
> - Easy to specify the desired outcome
> - Easy to verify results
> 
> I tried GPT4 to produce COQ proofs of Yoneda Lemma but it could not even complete the interfaces (without implementation) - they failed to compile, by being tripped up by implicit parameters etc.
> 
> But GPT4 gets much closer to completion compared to GPT3.5
> 
> I wonder what "GPT-native" programming language might look like😄
> 
> -Yasu
> 
> 
> 
>> On Apr 1, 2023, at 06:24, Levent Erkok <erkokl at gmail.com> wrote:
>> 
>> This code is buggy when lo + hi overflows your integer type. Classic (extremely) corner  case bug: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
>> 
>>> On Mar 31, 2023, at 1:02 PM, Gregory Guthrie <guthrie at miu.edu> wrote:
>>> 
>>> From a colleague:
>>>   GPT Pretty smart(?!).
>>> But this is of course simple, and searchable.
>>>  
>>> Still…
>>> --------------------------------------------------------------------------------------------------
>>> GPT-4 when prompted:
>>> 
>>> Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states.
>>>  
>>> gives the following response:
>>> 
>>> -- Binary search in Haskell
>>> -- Precondition: the list is sorted in ascending order
>>> -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
>>> -- Invariant: the search space is always within the bounds of the list
>>> -- Variant: the search space decreases by half at each recursive call
>>> -- Internal state: the lower and upper bounds of the search space
>>> 
>>> binarySearch :: Ord a => [a] -> a -> Maybe Int
>>> binarySearch xs x = go xs x 0 (length xs - 1)
>>>   where
>>>     go xs x lo hi
>>>       | lo > hi = Nothing -- base case: search space is empty
>>>       | x == midElem = Just mid -- base case: target element is found
>>>       | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
>>>       | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
>>>       where
>>>         mid = (lo + hi) `div` 2 -- calculate the middle index
>>>         midElem = xs !! mid -- get the middle element
>>> 
>>> -- Print results using putStrLn
>>> main :: IO ()
>>> main = do
>>>   let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
>>>   let x = 5 -- a target element to search for
>>>   let result = binarySearch xs x -- call the binary search function
>>>   case result of -- pattern match on the result
>>>     Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
>>>     Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned
>>>  
>>> The above code runs:
>>> 
>>> https://onecompiler.com/cpp/3z48yt2pp
>>>  
>>>  
>>> <image001.png>
>>>  
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view 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/20230331/9b65dd68/attachment.html>

From guthrie at miu.edu  Fri Mar 31 22:07:03 2023
From: guthrie at miu.edu (Gregory Guthrie)
Date: Fri, 31 Mar 2023 22:07:03 +0000
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CANePX3OJs6r+cxiP5chV6ZA4GHeyhmyUX8kAaC0D=R4d6MbCew@mail.gmail.com>
References: <mailman.34085.1680298749.2543.haskell-cafe@haskell.org>
 <CANePX3OJs6r+cxiP5chV6ZA4GHeyhmyUX8kAaC0D=R4d6MbCew@mail.gmail.com>
Message-ID: <CH2PR03MB5224B2FA2880627476446039A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>

---------- Forwarded message ----------
From: "Nenad Končar" <nlpresearcher at gmail.com<mailto:nlpresearcher at gmail.com>>
To: Levent Erkok <erkokl at gmail.com<mailto:erkokl at gmail.com>>
Cc: Gregory Guthrie <guthrie at miu.edu<mailto:guthrie at miu.edu>>, "haskell-cafe at haskell.org<mailto:haskell-cafe at haskell.org>" <haskell-cafe at haskell.org<mailto:haskell-cafe at haskell.org>>, Haskell Community <replies+f6607596e3ee63f105e2b0327b86f062 at discourse.haskell.org<mailto:replies%2Bf6607596e3ee63f105e2b0327b86f062 at discourse.haskell.org>>
Bcc:
Date: Sat, 1 Apr 2023 00:00:09 +0200
Subject: Re: [Haskell-cafe] GPT & Haskell
On Fri, 31 Mar 2023 at 23:24, Levent Erkok <erkokl at gmail.com<mailto:erkokl at gmail.com>> wrote:
This code is buggy when lo + hi overflows your integer type. Classic (extremely) corner  case bug: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html

Thank you kindly for pointing this out. GPT-4, when prompted, is able to detect and correct the overflow mistake as follows:


After I introduced a purposeful mistake in the Haskel code, I prompted GPT-4 as follows:
If the following Haskel code contains any logical mistakes then correct the code for me:


-- Binary search in Haskell
-- Precondition: the list is sorted in ascending order
-- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
-- Invariant: the search space is always within the bounds of the list
-- Variant: the search space decreases by half at each recursive call
-- Internal state: the lower and upper bounds of the search space

binarySearch :: Ord a => [a] -> a -> Maybe Int
binarySearch xs x = go xs x 0 (length xs - 1)
  where
    go xs x lo hi
      | lo > hi = Nothing -- base case: search space is empty
      | x == midElem = Just mid -- base case: target element is found
      | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
      | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
      where
        mid = (lo - hi) `div` 2 -- calculate the middle index
        midElem = xs !! mid -- get the middle element

-- Print results using putStrLn
main :: IO ()
main = do
  let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
  let x = 5 -- a target element to search for
  let result = binarySearch xs x -- call the binary search function
  case result of -- pattern match on the result
    Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
    Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned


and then GPT-4 replied:
Hello,

Thank you for sending me your Haskell code for binary search. I appreciate your interest in learning this functional programming language. I have reviewed your code and found a few logical mistakes that need to be corrected. Here is the revised code with some comments explaining the changes:


-- Binary search in Haskell
-- Precondition: the list is sorted in ascending order
-- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
-- Invariant: the search space is always within the bounds of the list
-- Variant: the search space decreases by half at each recursive call
-- Internal state: the lower and upper bounds of the search space

binarySearch :: Ord a => [a] -> a -> Maybe Int
binarySearch xs x = go xs x 0 (length xs - 1)
  where
    go xs x lo hi
      | lo > hi = Nothing -- base case: search space is empty
      | x == midElem = Just mid -- base case: target element is found
      | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
      | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
      where
        mid = lo + (hi - lo) `div` 2 -- calculate the middle index using a safer formula to avoid overflow
        midElem = xs !! mid -- get the middle element

-- Print results using putStrLn
main :: IO ()
main = do
  let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
  let x = 5 -- a target element to search for
  let result = binarySearch xs x -- call the binary search function
  case result of -- pattern match on the result
    Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
    Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned


The main mistake in your code was in the calculation of the middle index. You used `(lo - hi) `div` 2`, which is incorrect because it will always give a negative value. The correct formula is `lo + (hi - lo) `div` 2`, which ensures that the middle index is always within the bounds of the list. This formula also avoids overflow issues that might occur if you use `(lo + hi) `div` 2`.

I hope this helps you understand binary search better and improve your Haskell skills. Please let me know if you have any questions or feedback. I would love to hear from you and help you further.

Happy coding!



The improved code runs:
https://onecompiler.com/haskell/3z4avpx6n


On Mar 31, 2023, at 1:02 PM, Gregory Guthrie <guthrie at miu.edu<mailto:guthrie at miu.edu>> wrote:

From a colleague:
  GPT Pretty smart(?!).
But this is of course simple, and searchable.

Still…
--------------------------------------------------------------------------------------------------
GPT-4 when prompted:
Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states.

gives the following response:
-- Binary search in Haskell
-- Precondition: the list is sorted in ascending order
-- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
-- Invariant: the search space is always within the bounds of the list
-- Variant: the search space decreases by half at each recursive call
-- Internal state: the lower and upper bounds of the search space

binarySearch :: Ord a => [a] -> a -> Maybe Int
binarySearch xs x = go xs x 0 (length xs - 1)
  where
    go xs x lo hi
      | lo > hi = Nothing -- base case: search space is empty
      | x == midElem = Just mid -- base case: target element is found
      | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
      | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
      where
        mid = (lo + hi) `div` 2 -- calculate the middle index
        midElem = xs !! mid -- get the middle element

-- Print results using putStrLn
main :: IO ()
main = do
  let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
  let x = 5 -- a target element to search for
  let result = binarySearch xs x -- call the binary search function
  case result of -- pattern match on the result
    Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
    Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned

The above code runs:
https://onecompiler.com/cpp/3z48yt2pp


<image001.png>

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view 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/20230331/b09ba7b9/attachment.html>

From vagarenko at gmail.com  Fri Mar 31 23:01:46 2023
From: vagarenko at gmail.com (Alexey Vagarenko)
Date: Sat, 1 Apr 2023 05:01:46 +0600
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <8F2A4090-CF73-4888-A064-7078019D5E6A@gmail.com>
References: <57707B72-65B5-4D58-B49D-9759B3A98A84@gmail.com>
 <1B7B8480-E66E-4EF2-96EF-17E30826E2A7@yasuaki.com>
 <8F2A4090-CF73-4888-A064-7078019D5E6A@gmail.com>
Message-ID: <CAGzSZM4=9ssCM-4Za7_LXrap4GabWB2ZEA3v-DBOtZhPwhW2qA@mail.gmail.com>

Isn’t binary search useless for lists? It performs worse than full list
traversal.

Сб, 1 апр. 2023 г. в 03:43, Branimir Maksimovic <
branimir.maksimovic at gmail.com>:

> I was thoughtt from my mathematic logic proffesor in 1987 that algorithm
> for making algorithms
> doesn’t exist. He proved that there is no algorihm for provin hieor order
> logic formulas…
>
> Greets, Branmir.
>
>
> On 31. 3. 2023., at 23:37, Yasuaki Kudo <yasu at yasuaki.com> wrote:
>
> I am really curious - is it possible to create a programming language
> designed from the ground up to be used by GPT and similar tools?
>
> - Easy to specify the desired outcome
> - Easy to verify results
>
> I tried GPT4 to produce COQ proofs of Yoneda Lemma but it could not even
> complete the interfaces (without implementation) - they failed to compile,
> by being tripped up by implicit parameters etc.
>
> But GPT4 gets much closer to completion compared to GPT3.5
>
> I wonder what "GPT-native" programming language might look like😄
>
> -Yasu
>
>
>
> On Apr 1, 2023, at 06:24, Levent Erkok <erkokl at gmail.com> wrote:
>
> This code is buggy when lo + hi overflows your integer type. Classic
> (extremely) corner  case bug:
> https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
>
> On Mar 31, 2023, at 1:02 PM, Gregory Guthrie <guthrie at miu.edu> wrote:
>
> From a colleague:
>   GPT Pretty smart(?!).
> But this is of course simple, and searchable.
>
> Still…
>
> --------------------------------------------------------------------------------------------------
>
> GPT-4 when prompted:
> *Write binary search in Haskel. Print results using putStrLn. Ensure
> bug-free code by specifying preconditions, postconditions, invariants,
> variants, internal states.*
>
>
> gives the following response:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *-- Binary search in Haskell-- Precondition: the list is sorted in
> ascending order-- Postcondition: the function returns the index of the
> target element if found, or Nothing otherwise-- Invariant: the search space
> is always within the bounds of the list-- Variant: the search space
> decreases by half at each recursive call-- Internal state: the lower and
> upper bounds of the search spacebinarySearch :: Ord a => [a] -> a -> Maybe
> IntbinarySearch xs x = go xs x 0 (length xs - 1)  where    go xs x lo hi
>   | lo > hi = Nothing -- base case: search space is empty      | x ==
> midElem = Just mid -- base case: target element is found      | x < midElem
> = go xs x lo (mid - 1) -- recursive case: search in the left half      |
> otherwise = go xs x (mid + 1) hi -- recursive case: search in the right
> half      where        mid = (lo + hi) `div` 2 -- calculate the middle
> index        midElem = xs !! mid -- get the middle element-- Print results
> using putStrLnmain :: IO ()main = do  let xs = [1, 3, 5, 7, 9] -- a sorted
> list of integers  let x = 5 -- a target element to search for  let result =
> binarySearch xs x -- call the binary search function  case result of --
> pattern match on the result    Nothing -> putStrLn "Element not found" --
> print a message if Nothing is returned    Just i -> putStrLn $ "Element
> found at index " ++ show i -- print a message with the index if Just i is
> returned*
>
>
> The above code runs:
> *https://onecompiler.com/cpp/3z48yt2pp
> <https://onecompiler.com/cpp/3z48yt2pp>*
>
>
> <image001.png>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230401/b9b3fb86/attachment.html>

From branimir.maksimovic at gmail.com  Fri Mar 31 23:07:21 2023
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Sat, 1 Apr 2023 01:07:21 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAGzSZM4=9ssCM-4Za7_LXrap4GabWB2ZEA3v-DBOtZhPwhW2qA@mail.gmail.com>
References: <57707B72-65B5-4D58-B49D-9759B3A98A84@gmail.com>
 <1B7B8480-E66E-4EF2-96EF-17E30826E2A7@yasuaki.com>
 <8F2A4090-CF73-4888-A064-7078019D5E6A@gmail.com>
 <CAGzSZM4=9ssCM-4Za7_LXrap4GabWB2ZEA3v-DBOtZhPwhW2qA@mail.gmail.com>
Message-ID: <85C3FC5A-B8E2-4D3D-AFC0-C767949AB0F6@gmail.com>

Of course it’ useless. GPT should be tested with something that can’t be found
on internet :P

I tried with problem euler 512, it can’t find optimal solution, but can perform
microoptimisations of existing solution, which is still impressive :P

Greets, Branimir.
 

> On 1. 4. 2023., at 01:01, Alexey Vagarenko <vagarenko at gmail.com> wrote:
> 
> Isn’t binary search useless for lists? It performs worse than full list traversal.
> 
> Сб, 1 апр. 2023 г. в 03:43, Branimir Maksimovic <branimir.maksimovic at gmail.com <mailto:branimir.maksimovic at gmail.com>>:
>> I was thoughtt from my mathematic logic proffesor in 1987 that algorithm for making algorithms
>> doesn’t exist. He proved that there is no algorihm for provin hieor order logic formulas…
>> 
>> Greets, Branmir.
>> 
>> 
>>> On 31. 3. 2023., at 23:37, Yasuaki Kudo <yasu at yasuaki.com <mailto:yasu at yasuaki.com>> wrote:
>>> 
>>> I am really curious - is it possible to create a programming language designed from the ground up to be used by GPT and similar tools?
>>> 
>>> - Easy to specify the desired outcome
>>> - Easy to verify results
>>> 
>>> I tried GPT4 to produce COQ proofs of Yoneda Lemma but it could not even complete the interfaces (without implementation) - they failed to compile, by being tripped up by implicit parameters etc.
>>> 
>>> But GPT4 gets much closer to completion compared to GPT3.5
>>> 
>>> I wonder what "GPT-native" programming language might look like😄
>>> 
>>> -Yasu
>>> 
>>> 
>>> 
>>>> On Apr 1, 2023, at 06:24, Levent Erkok <erkokl at gmail.com <mailto:erkokl at gmail.com>> wrote:
>>>> 
>>>> This code is buggy when lo + hi overflows your integer type. Classic (extremely) corner  case bug: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
>>>> 
>>>>> On Mar 31, 2023, at 1:02 PM, Gregory Guthrie <guthrie at miu.edu <mailto:guthrie at miu.edu>> wrote:
>>>>> 
>>>>> From a colleague:
>>>>>   GPT Pretty smart(?!).
>>>>> But this is of course simple, and searchable.
>>>>>  
>>>>> Still…
>>>>> --------------------------------------------------------------------------------------------------
>>>>> GPT-4 when prompted:
>>>>> 
>>>>> Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states.
>>>>>  
>>>>> gives the following response:
>>>>> 
>>>>> -- Binary search in Haskell
>>>>> -- Precondition: the list is sorted in ascending order
>>>>> -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise
>>>>> -- Invariant: the search space is always within the bounds of the list
>>>>> -- Variant: the search space decreases by half at each recursive call
>>>>> -- Internal state: the lower and upper bounds of the search space
>>>>> 
>>>>> binarySearch :: Ord a => [a] -> a -> Maybe Int
>>>>> binarySearch xs x = go xs x 0 (length xs - 1)
>>>>>   where
>>>>>     go xs x lo hi
>>>>>       | lo > hi = Nothing -- base case: search space is empty
>>>>>       | x == midElem = Just mid -- base case: target element is found
>>>>>       | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half
>>>>>       | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half
>>>>>       where
>>>>>         mid = (lo + hi) `div` 2 -- calculate the middle index
>>>>>         midElem = xs !! mid -- get the middle element
>>>>> 
>>>>> -- Print results using putStrLn
>>>>> main :: IO ()
>>>>> main = do
>>>>>   let xs = [1, 3, 5, 7, 9] -- a sorted list of integers
>>>>>   let x = 5 -- a target element to search for
>>>>>   let result = binarySearch xs x -- call the binary search function
>>>>>   case result of -- pattern match on the result
>>>>>     Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned
>>>>>     Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned
>>>>>  
>>>>> The above code runs:
>>>>> 
>>>>> https://onecompiler.com/cpp/3z48yt2pp
>>>>>  
>>>>>  
>>>>> <image001.png>
>>>>>  
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> To (un)subscribe, modify options or view archives go to:
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>> Only members subscribed via the mailman list are allowed to post.
>>>> 
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

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

From yasu at yasuaki.com  Fri Mar 31 23:24:06 2023
From: yasu at yasuaki.com (Yasuaki Kudo)
Date: Sat, 1 Apr 2023 08:24:06 +0900
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <85C3FC5A-B8E2-4D3D-AFC0-C767949AB0F6@gmail.com>
References: <85C3FC5A-B8E2-4D3D-AFC0-C767949AB0F6@gmail.com>
Message-ID: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>

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

From migmit at gmail.com  Fri Mar 31 23:27:19 2023
From: migmit at gmail.com (Mig Mit)
Date: Sat, 1 Apr 2023 01:27:19 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
Message-ID: <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>

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

From jclites at mac.com  Fri Mar 31 23:56:11 2023
From: jclites at mac.com (Jeff Clites)
Date: Fri, 31 Mar 2023 16:56:11 -0700
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
References: <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
Message-ID: <F0F6B6FA-CDC9-4D0B-B931-966C790B185C@mac.com>

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