From migmit at gmail.com  Sat Apr  1 00:08:23 2023
From: migmit at gmail.com (MigMit)
Date: Sat, 1 Apr 2023 02:08:23 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <F0F6B6FA-CDC9-4D0B-B931-966C790B185C@mac.com>
References: <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <F0F6B6FA-CDC9-4D0B-B931-966C790B185C@mac.com>
Message-ID: <38787D7C-E9CD-4CF7-B44E-CA3F6FE5226C@gmail.com>

That's true.

But I feel like a lot of progress in programming was made in attempt to make "non-technical people" communicate with a computer without a programmer in between. So far, despite all that was done, those attempts did not really succeed. I'm sceptical regarding AI chances, honestly. I mean, just imagine a business person suddenly finding out they can't improve the computer system by yelling at the programmer.

> On 1 Apr 2023, at 01:56, Jeff Clites <jclites at mac.com> wrote:
> 
> Yes, if you’re a programmer. A lot of real-world business scenarios are basically a non-technical person using English to give a (flawed, incomplete) specification, and a programmer using their expertise not only to implement but also to fill in the incomplete parts of the specification and also to determine what missing parts of the specification can’t be interpolated and have to be asked about. That sort of filling in missing parts based on precedent is the exact sort of thing these AI are good at.
> 
> Jeff
> 
>> On Mar 31, 2023, at 4:27 PM, Mig Mit <migmit at gmail.com> wrote:
>> 
>> How is it going to benefit anyone though? English, like all natural languages, is terrible for describing algorithms. It is way easier to just code the damn thing.
>> 
>> Sent from my iPad
>> 
>>> On 2023. Apr 1., at 1:24, Yasuaki Kudo <yasu at yasuaki.com> wrote:
>>> 
>>> There is TTS (text to speech) and STT (speech to text)  Former is easier, latter is harder.
>>> 
>>> Similarly, is it possible that we generate a huge variations of English explanation of correct compiled programs (like TTS - easy-ish, because we can program English explanations algorithmically ) and the get GPT-like-things to learn from that huge sample so it can convert human instructions to accurate programs? (like STT - hard),
>>> 
>>> 
>>>> On Apr 1, 2023, at 08:08, Branimir Maksimovic <branimir.maksimovic at gmail.com> wrote:
>>>> 
>>>> 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>:
>>>>> 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.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> To (un)subscribe, modify options or view 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.



From will.yager at gmail.com  Sat Apr  1 03:36:37 2023
From: will.yager at gmail.com (William Yager)
Date: Fri, 31 Mar 2023 23:36:37 -0400
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
Message-ID: <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>

On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:

> How is it going to benefit anyone though? English, like all natural
> languages, is terrible for describing algorithms.
>


The other day, I asked ChatGPT to solve a boring but non-trivial
programming problem I had:

> I have a png file which contains a bunch of 5x7 bitmap font characters.
Write a python program which reads in the png, and then for each character
in the png, extracts the 35 bits of each character and assembles them into
an integer.  The final output should be a list of integers, each integer
containing a binary representation of each character in the font.

It did this basically perfectly.  It wasn't precisely matched to my format,
but only because I was ambiguous in the problem statement. I gave it a
little more context about the image format and it did it exactly right on
the second try.

I also asked it to write an inverse function of this, which it did
perfectly in Python, and did pretty well in Rust, although with a small and
understandable bug.

Very useful!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230331/fef9c720/attachment.html>

From alois.cochard at gmail.com  Sat Apr  1 06:18:08 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sat, 1 Apr 2023 08:18:08 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
Message-ID: <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>

How can this be useful when you have to anyway review everything is doing
as he might to just randomly insert a bug or a security flaw???
I prefer to read poems by my human friends.

I highly recommend starting reading this paper at page 128 instead of
wasting your time on that prompt:
https://arxiv.org/pdf/2303.12712.pdf

Be ready for a good laugh

Sincerely yours


On Sat, 1 Apr 2023 at 05:36, William Yager <will.yager at gmail.com> wrote:

> On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:
>
>> How is it going to benefit anyone though? English, like all natural
>> languages, is terrible for describing algorithms.
>>
>
>
> The other day, I asked ChatGPT to solve a boring but non-trivial
> programming problem I had:
>
> > I have a png file which contains a bunch of 5x7 bitmap font characters.
> Write a python program which reads in the png, and then for each character
> in the png, extracts the 35 bits of each character and assembles them into
> an integer.  The final output should be a list of integers, each integer
> containing a binary representation of each character in the font.
>
> It did this basically perfectly.  It wasn't precisely matched to my
> format, but only because I was ambiguous in the problem statement. I gave
> it a little more context about the image format and it did it exactly right
> on the second try.
>
> I also asked it to write an inverse function of this, which it did
> perfectly in Python, and did pretty well in Rust, although with a small and
> understandable bug.
>
> Very useful!
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/3ab82470/attachment.html>

From dominik.schrempf at gmail.com  Sat Apr  1 09:44:13 2023
From: dominik.schrempf at gmail.com (Dominik Schrempf)
Date: Sat, 01 Apr 2023 11:44:13 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
Message-ID: <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>

Well, it seems like GPT4 gets most of the questions right. This was more of a scary read than a funny one to me!

Dominik

On April 1, 2023 8:18:08 AM GMT+02:00, "Aloïs Cochard" <alois.cochard at gmail.com> wrote:
>How can this be useful when you have to anyway review everything is doing
>as he might to just randomly insert a bug or a security flaw???
>I prefer to read poems by my human friends.
>
>I highly recommend starting reading this paper at page 128 instead of
>wasting your time on that prompt:
>https://arxiv.org/pdf/2303.12712.pdf
>
>Be ready for a good laugh
>
>Sincerely yours
>
>
>On Sat, 1 Apr 2023 at 05:36, William Yager <will.yager at gmail.com> wrote:
>
>> On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:
>>
>>> How is it going to benefit anyone though? English, like all natural
>>> languages, is terrible for describing algorithms.
>>>
>>
>>
>> The other day, I asked ChatGPT to solve a boring but non-trivial
>> programming problem I had:
>>
>> > I have a png file which contains a bunch of 5x7 bitmap font characters.
>> Write a python program which reads in the png, and then for each character
>> in the png, extracts the 35 bits of each character and assembles them into
>> an integer.  The final output should be a list of integers, each integer
>> containing a binary representation of each character in the font.
>>
>> It did this basically perfectly.  It wasn't precisely matched to my
>> format, but only because I was ambiguous in the problem statement. I gave
>> it a little more context about the image format and it did it exactly right
>> on the second try.
>>
>> I also asked it to write an inverse function of this, which it did
>> perfectly in Python, and did pretty well in Rust, although with a small and
>> understandable bug.
>>
>> Very useful!
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
>-- 
>*Λ\oïs*
>http://twitter.com/aloiscochard
>http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/4c187bb9/attachment.html>

From alois.cochard at gmail.com  Sat Apr  1 11:36:05 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sat, 1 Apr 2023 13:36:05 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>
Message-ID: <CAJHA+wqCf-rDQ-qW-Gbh16J4N8nVDCWJTY+1gk=qAEuD7vjoXw@mail.gmail.com>

I don't know, personally I could not stop laughing at the answer from
version 3.5... it's so freaking stupid!

But if like Dominik you are scared after reading that part you might be
interested to look into:
https://futureoflife.org/open-letter/pause-giant-ai-experiments/

On Sat, 1 Apr 2023 at 11:44, Dominik Schrempf <dominik.schrempf at gmail.com>
wrote:

> Well, it seems like GPT4 gets most of the questions right. This was more
> of a scary read than a funny one to me!
>
> Dominik
>
> On April 1, 2023 8:18:08 AM GMT+02:00, "Aloïs Cochard" <
> alois.cochard at gmail.com> wrote:
>>
>> How can this be useful when you have to anyway review everything is doing
>> as he might to just randomly insert a bug or a security flaw???
>> I prefer to read poems by my human friends.
>>
>> I highly recommend starting reading this paper at page 128 instead of
>> wasting your time on that prompt:
>> https://arxiv.org/pdf/2303.12712.pdf
>>
>> Be ready for a good laugh
>>
>> Sincerely yours
>>
>>
>> On Sat, 1 Apr 2023 at 05:36, William Yager <will.yager at gmail.com> wrote:
>>
>>> On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:
>>>
>>>> How is it going to benefit anyone though? English, like all natural
>>>> languages, is terrible for describing algorithms.
>>>>
>>>
>>>
>>> The other day, I asked ChatGPT to solve a boring but non-trivial
>>> programming problem I had:
>>>
>>> > I have a png file which contains a bunch of 5x7 bitmap font
>>> characters. Write a python program which reads in the png, and then for
>>> each character in the png, extracts the 35 bits of each character and
>>> assembles them into an integer.  The final output should be a list of
>>> integers, each integer containing a binary representation of each character
>>> in the font.
>>>
>>> It did this basically perfectly.  It wasn't precisely matched to my
>>> format, but only because I was ambiguous in the problem statement. I gave
>>> it a little more context about the image format and it did it exactly right
>>> on the second try.
>>>
>>> I also asked it to write an inverse function of this, which it did
>>> perfectly in Python, and did pretty well in Rust, although with a small and
>>> understandable bug.
>>>
>>> Very useful!
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>

-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/e2da182a/attachment-0001.html>

From migmit at gmail.com  Sat Apr  1 11:51:54 2023
From: migmit at gmail.com (MigMit)
Date: Sat, 1 Apr 2023 13:51:54 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAJHA+wqCf-rDQ-qW-Gbh16J4N8nVDCWJTY+1gk=qAEuD7vjoXw@mail.gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>
 <CAJHA+wqCf-rDQ-qW-Gbh16J4N8nVDCWJTY+1gk=qAEuD7vjoXw@mail.gmail.com>
Message-ID: <122466AE-B16B-4015-A110-E6199706577F@gmail.com>

Or this: https://time.com/6266923/ai-eliezer-yudkowsky-open-letter-not-enough/

(to which somebody said "I work in a datacenter. So far no AI threatened violence on me; Yudkowsky just did")

> On 1 Apr 2023, at 13:36, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> 
> I don't know, personally I could not stop laughing at the answer from version 3.5... it's so freaking stupid!
> 
> But if like Dominik you are scared after reading that part you might be interested to look into:
> https://futureoflife.org/open-letter/pause-giant-ai-experiments/
> 
> On Sat, 1 Apr 2023 at 11:44, Dominik Schrempf <dominik.schrempf at gmail.com> wrote:
> Well, it seems like GPT4 gets most of the questions right. This was more of a scary read than a funny one to me!
> 
> Dominik
> 
> On April 1, 2023 8:18:08 AM GMT+02:00, "Aloïs Cochard" <alois.cochard at gmail.com> wrote: How can this be useful when you have to anyway review everything is doing as he might to just randomly insert a bug or a security flaw???
> I prefer to read poems by my human friends.
> 
> I highly recommend starting reading this paper at page 128 instead of wasting your time on that prompt:
> https://arxiv.org/pdf/2303.12712.pdf
> 
> Be ready for a good laugh
> 
> Sincerely yours
> 
> 
> On Sat, 1 Apr 2023 at 05:36, William Yager <will.yager at gmail.com> wrote:
> On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:
> How is it going to benefit anyone though? English, like all natural languages, is terrible for describing algorithms. 
> 
> 
> The other day, I asked ChatGPT to solve a boring but non-trivial programming problem I had:
> 
> > I have a png file which contains a bunch of 5x7 bitmap font characters. Write a python program which reads in the png, and then for each character in the png, extracts the 35 bits of each character and assembles them into an integer.  The final output should be a list of integers, each integer containing a binary representation of each character in the font.
> 
> It did this basically perfectly.  It wasn't precisely matched to my format, but only because I was ambiguous in the problem statement. I gave it a little more context about the image format and it did it exactly right on the second try.
> 
> I also asked it to write an inverse function of this, which it did perfectly in Python, and did pretty well in Rust, although with a small and understandable bug.
> 
> Very useful! 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
> 
> 
> 
> -- 
> Λ\oïs
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sat Apr  1 12:24:56 2023
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 1 Apr 2023 13:24:56 +0100
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <122466AE-B16B-4015-A110-E6199706577F@gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>
 <CAJHA+wqCf-rDQ-qW-Gbh16J4N8nVDCWJTY+1gk=qAEuD7vjoXw@mail.gmail.com>
 <122466AE-B16B-4015-A110-E6199706577F@gmail.com>
Message-ID: <ZCgimPtBuS/Q+YLt@cloudinit-builder>

I never thought I would see Time publish an article advocating that
"allied nuclear countries [should be] willing to run some risk of
nuclear exchange if that’s what it takes to reduce the risk of large
AI training runs", written by a man who didn't go to high school.

Tom



On Sat, Apr 01, 2023 at 01:51:54PM +0200, MigMit wrote:
> Or this: https://time.com/6266923/ai-eliezer-yudkowsky-open-letter-not-enough/
> 
> (to which somebody said "I work in a datacenter. So far no AI threatened violence on me; Yudkowsky just did")
> 
> > On 1 Apr 2023, at 13:36, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> > 
> > I don't know, personally I could not stop laughing at the answer from version 3.5... it's so freaking stupid!
> > 
> > But if like Dominik you are scared after reading that part you might be interested to look into:
> > https://futureoflife.org/open-letter/pause-giant-ai-experiments/
> > 
> > On Sat, 1 Apr 2023 at 11:44, Dominik Schrempf <dominik.schrempf at gmail.com> wrote:
> > Well, it seems like GPT4 gets most of the questions right. This was more of a scary read than a funny one to me!
> > 
> > Dominik
> > 
> > On April 1, 2023 8:18:08 AM GMT+02:00, "Aloïs Cochard" <alois.cochard at gmail.com> wrote:
> >How can this be useful when you have to anyway review everything is doing as he might to just randomly insert a bug or a security flaw???
> > I prefer to read poems by my human friends.
> > 
> > I highly recommend starting reading this paper at page 128 instead of wasting your time on that prompt:
> > https://arxiv.org/pdf/2303.12712.pdf
> > 
> > Be ready for a good laugh

From alois.cochard at gmail.com  Sat Apr  1 12:51:49 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sat, 1 Apr 2023 14:51:49 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <122466AE-B16B-4015-A110-E6199706577F@gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>
 <CAJHA+wqCf-rDQ-qW-Gbh16J4N8nVDCWJTY+1gk=qAEuD7vjoXw@mail.gmail.com>
 <122466AE-B16B-4015-A110-E6199706577F@gmail.com>
Message-ID: <CAJHA+woWXjU7e7iZ7QHG63ei401-Hxcrzz-1u_2E6pJ4hLd1Zw@mail.gmail.com>

Very interesting, thanks for sharing.

This is a very radical viewpoint, I think there is tons of research that
can be done on alignment and for this reason I don't think we should shut
it all down.

Obviously it's not a good idea to give access to such a system to everyone,
I hope that at least we all start to understand this.

On Sat, 1 Apr 2023 at 13:52, MigMit <migmit at gmail.com> wrote:

> Or this:
> https://time.com/6266923/ai-eliezer-yudkowsky-open-letter-not-enough/
>
> (to which somebody said "I work in a datacenter. So far no AI threatened
> violence on me; Yudkowsky just did")
>
> > On 1 Apr 2023, at 13:36, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> >
> > I don't know, personally I could not stop laughing at the answer from
> version 3.5... it's so freaking stupid!
> >
> > But if like Dominik you are scared after reading that part you might be
> interested to look into:
> > https://futureoflife.org/open-letter/pause-giant-ai-experiments/
> >
> > On Sat, 1 Apr 2023 at 11:44, Dominik Schrempf <
> dominik.schrempf at gmail.com> wrote:
> > Well, it seems like GPT4 gets most of the questions right. This was more
> of a scary read than a funny one to me!
> >
> > Dominik
> >
> > On April 1, 2023 8:18:08 AM GMT+02:00, "Aloïs Cochard" <
> alois.cochard at gmail.com> wrote: How can this be useful when you have to
> anyway review everything is doing as he might to just randomly insert a bug
> or a security flaw???
> > I prefer to read poems by my human friends.
> >
> > I highly recommend starting reading this paper at page 128 instead of
> wasting your time on that prompt:
> > https://arxiv.org/pdf/2303.12712.pdf
> >
> > Be ready for a good laugh
> >
> > Sincerely yours
> >
> >
> > On Sat, 1 Apr 2023 at 05:36, William Yager <will.yager at gmail.com> wrote:
> > On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:
> > How is it going to benefit anyone though? English, like all natural
> languages, is terrible for describing algorithms.
> >
> >
> > The other day, I asked ChatGPT to solve a boring but non-trivial
> programming problem I had:
> >
> > > I have a png file which contains a bunch of 5x7 bitmap font
> characters. Write a python program which reads in the png, and then for
> each character in the png, extracts the 35 bits of each character and
> assembles them into an integer.  The final output should be a list of
> integers, each integer containing a binary representation of each character
> in the font.
> >
> > It did this basically perfectly.  It wasn't precisely matched to my
> format, but only because I was ambiguous in the problem statement. I gave
> it a little more context about the image format and it did it exactly right
> on the second try.
> >
> > I also asked it to write an inverse function of this, which it did
> perfectly in Python, and did pretty well in Rust, although with a small and
> understandable bug.
> >
> > Very useful!
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> >
> >
> >
> > --
> > Λ\oïs
> > http://twitter.com/aloiscochard
> > http://github.com/aloiscochard
>
>

-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/def49829/attachment.html>

From migmit at gmail.com  Sat Apr  1 12:57:09 2023
From: migmit at gmail.com (MigMit)
Date: Sat, 1 Apr 2023 14:57:09 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAJHA+woWXjU7e7iZ7QHG63ei401-Hxcrzz-1u_2E6pJ4hLd1Zw@mail.gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>
 <CAJHA+wqCf-rDQ-qW-Gbh16J4N8nVDCWJTY+1gk=qAEuD7vjoXw@mail.gmail.com>
 <122466AE-B16B-4015-A110-E6199706577F@gmail.com>
 <CAJHA+woWXjU7e7iZ7QHG63ei401-Hxcrzz-1u_2E6pJ4hLd1Zw@mail.gmail.com>
Message-ID: <06603FA6-3ED5-4E81-85E2-7F9238C0B6C4@gmail.com>

Why is it obvious?

> On 1 Apr 2023, at 14:51, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> 
> Very interesting, thanks for sharing.
> 
> This is a very radical viewpoint, I think there is tons of research that can be done on alignment and for this reason I don't think we should shut it all down.
> 
> Obviously it's not a good idea to give access to such a system to everyone, I hope that at least we all start to understand this.
> 
> On Sat, 1 Apr 2023 at 13:52, MigMit <migmit at gmail.com> wrote:
> Or this: https://time.com/6266923/ai-eliezer-yudkowsky-open-letter-not-enough/
> 
> (to which somebody said "I work in a datacenter. So far no AI threatened violence on me; Yudkowsky just did")
> 
> > On 1 Apr 2023, at 13:36, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> > 
> > I don't know, personally I could not stop laughing at the answer from version 3.5... it's so freaking stupid!
> > 
> > But if like Dominik you are scared after reading that part you might be interested to look into:
> > https://futureoflife.org/open-letter/pause-giant-ai-experiments/
> > 
> > On Sat, 1 Apr 2023 at 11:44, Dominik Schrempf <dominik.schrempf at gmail.com> wrote:
> > Well, it seems like GPT4 gets most of the questions right. This was more of a scary read than a funny one to me!
> > 
> > Dominik
> > 
> > On April 1, 2023 8:18:08 AM GMT+02:00, "Aloïs Cochard" <alois.cochard at gmail.com> wrote: How can this be useful when you have to anyway review everything is doing as he might to just randomly insert a bug or a security flaw???
> > I prefer to read poems by my human friends.
> > 
> > I highly recommend starting reading this paper at page 128 instead of wasting your time on that prompt:
> > https://arxiv.org/pdf/2303.12712.pdf
> > 
> > Be ready for a good laugh
> > 
> > Sincerely yours
> > 
> > 
> > On Sat, 1 Apr 2023 at 05:36, William Yager <will.yager at gmail.com> wrote:
> > On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:
> > How is it going to benefit anyone though? English, like all natural languages, is terrible for describing algorithms. 
> > 
> > 
> > The other day, I asked ChatGPT to solve a boring but non-trivial programming problem I had:
> > 
> > > I have a png file which contains a bunch of 5x7 bitmap font characters. Write a python program which reads in the png, and then for each character in the png, extracts the 35 bits of each character and assembles them into an integer.  The final output should be a list of integers, each integer containing a binary representation of each character in the font.
> > 
> > It did this basically perfectly.  It wasn't precisely matched to my format, but only because I was ambiguous in the problem statement. I gave it a little more context about the image format and it did it exactly right on the second try.
> > 
> > I also asked it to write an inverse function of this, which it did perfectly in Python, and did pretty well in Rust, although with a small and understandable bug.
> > 
> > Very useful! 
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> > 
> > 
> > 
> > -- 
> > Λ\oïs
> > http://twitter.com/aloiscochard
> > http://github.com/aloiscochard
> 
> 
> 
> -- 
> Λ\oïs
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard


From alois.cochard at gmail.com  Sat Apr  1 13:08:06 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sat, 1 Apr 2023 15:08:06 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <06603FA6-3ED5-4E81-85E2-7F9238C0B6C4@gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>
 <CAJHA+wqCf-rDQ-qW-Gbh16J4N8nVDCWJTY+1gk=qAEuD7vjoXw@mail.gmail.com>
 <122466AE-B16B-4015-A110-E6199706577F@gmail.com>
 <CAJHA+woWXjU7e7iZ7QHG63ei401-Hxcrzz-1u_2E6pJ4hLd1Zw@mail.gmail.com>
 <06603FA6-3ED5-4E81-85E2-7F9238C0B6C4@gmail.com>
Message-ID: <CAJHA+wpd9xWWDoU_5CMPi6vVEVdYpVeDop3vm5Gs8hfRVe6zpg@mail.gmail.com>

>From a theoretical point of view, this can be observed in
https://arxiv.org/pdf/2303.12712.pdf from page 126 to the end of the paper.

More concretely the scale at which such a system can be used to synthesis
information or "predict" stock market is alarming, those are just some
random examples.


On Sat, 1 Apr 2023 at 14:57, MigMit <migmit at gmail.com> wrote:

> Why is it obvious?
>
> > On 1 Apr 2023, at 14:51, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> >
> > Very interesting, thanks for sharing.
> >
> > This is a very radical viewpoint, I think there is tons of research that
> can be done on alignment and for this reason I don't think we should shut
> it all down.
> >
> > Obviously it's not a good idea to give access to such a system to
> everyone, I hope that at least we all start to understand this.
> >
> > On Sat, 1 Apr 2023 at 13:52, MigMit <migmit at gmail.com> wrote:
> > Or this:
> https://time.com/6266923/ai-eliezer-yudkowsky-open-letter-not-enough/
> >
> > (to which somebody said "I work in a datacenter. So far no AI threatened
> violence on me; Yudkowsky just did")
> >
> > > On 1 Apr 2023, at 13:36, Aloïs Cochard <alois.cochard at gmail.com>
> wrote:
> > >
> > > I don't know, personally I could not stop laughing at the answer from
> version 3.5... it's so freaking stupid!
> > >
> > > But if like Dominik you are scared after reading that part you might
> be interested to look into:
> > > https://futureoflife.org/open-letter/pause-giant-ai-experiments/
> > >
> > > On Sat, 1 Apr 2023 at 11:44, Dominik Schrempf <
> dominik.schrempf at gmail.com> wrote:
> > > Well, it seems like GPT4 gets most of the questions right. This was
> more of a scary read than a funny one to me!
> > >
> > > Dominik
> > >
> > > On April 1, 2023 8:18:08 AM GMT+02:00, "Aloïs Cochard" <
> alois.cochard at gmail.com> wrote: How can this be useful when you have to
> anyway review everything is doing as he might to just randomly insert a bug
> or a security flaw???
> > > I prefer to read poems by my human friends.
> > >
> > > I highly recommend starting reading this paper at page 128 instead of
> wasting your time on that prompt:
> > > https://arxiv.org/pdf/2303.12712.pdf
> > >
> > > Be ready for a good laugh
> > >
> > > Sincerely yours
> > >
> > >
> > > On Sat, 1 Apr 2023 at 05:36, William Yager <will.yager at gmail.com>
> wrote:
> > > On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:
> > > How is it going to benefit anyone though? English, like all natural
> languages, is terrible for describing algorithms.
> > >
> > >
> > > The other day, I asked ChatGPT to solve a boring but non-trivial
> programming problem I had:
> > >
> > > > I have a png file which contains a bunch of 5x7 bitmap font
> characters. Write a python program which reads in the png, and then for
> each character in the png, extracts the 35 bits of each character and
> assembles them into an integer.  The final output should be a list of
> integers, each integer containing a binary representation of each character
> in the font.
> > >
> > > It did this basically perfectly.  It wasn't precisely matched to my
> format, but only because I was ambiguous in the problem statement. I gave
> it a little more context about the image format and it did it exactly right
> on the second try.
> > >
> > > I also asked it to write an inverse function of this, which it did
> perfectly in Python, and did pretty well in Rust, although with a small and
> understandable bug.
> > >
> > > Very useful!
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > To (un)subscribe, modify options or view archives go to:
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > Only members subscribed via the mailman list are allowed to post.
> > >
> > >
> > >
> > > --
> > > Λ\oïs
> > > http://twitter.com/aloiscochard
> > > http://github.com/aloiscochard
> >
> >
> >
> > --
> > Λ\oïs
> > http://twitter.com/aloiscochard
> > http://github.com/aloiscochard
>
>

-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/673a9d28/attachment.html>

From alois.cochard at gmail.com  Sat Apr  1 13:22:58 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sat, 1 Apr 2023 15:22:58 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
Message-ID: <CAJHA+wo4jccaduJxCEJVeO1HtS0yAvC8tpBw5hU-bCarnt1TBg@mail.gmail.com>

Dear Gregory,

Can you please fix your onecompiler vanity link? It points to the C++
runtime implementation.

Thanks

On Fri, 31 Mar 2023 at 22:04, 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.
>


-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/f4c31869/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/20230401/f4c31869/attachment-0001.png>

From migmit at gmail.com  Sat Apr  1 13:32:13 2023
From: migmit at gmail.com (MigMit)
Date: Sat, 1 Apr 2023 15:32:13 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAJHA+wpd9xWWDoU_5CMPi6vVEVdYpVeDop3vm5Gs8hfRVe6zpg@mail.gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <519EF216-2BEB-424C-8544-62F7482BAC52@gmail.com>
 <CAJHA+wqCf-rDQ-qW-Gbh16J4N8nVDCWJTY+1gk=qAEuD7vjoXw@mail.gmail.com>
 <122466AE-B16B-4015-A110-E6199706577F@gmail.com>
 <CAJHA+woWXjU7e7iZ7QHG63ei401-Hxcrzz-1u_2E6pJ4hLd1Zw@mail.gmail.com>
 <06603FA6-3ED5-4E81-85E2-7F9238C0B6C4@gmail.com>
 <CAJHA+wpd9xWWDoU_5CMPi6vVEVdYpVeDop3vm5Gs8hfRVe6zpg@mail.gmail.com>
Message-ID: <33EF0925-D7F7-415C-A1F4-DE1A62889E13@gmail.com>

Um, I see someone who can do some math. No disrespect, but I think I can do better. Should I also be under this "restricted access" policy?

And using software to predict stock market is done constantly; software does it better than any human (and probably better than any AI), so, what's the problem here?

> On 1 Apr 2023, at 15:08, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> 
> From a theoretical point of view, this can be observed in https://arxiv.org/pdf/2303.12712.pdf from page 126 to the end of the paper.
> 
> More concretely the scale at which such a system can be used to synthesis information or "predict" stock market is alarming, those are just some random examples.
>  
> 
> On Sat, 1 Apr 2023 at 14:57, MigMit <migmit at gmail.com> wrote:
> Why is it obvious?
> 
> > On 1 Apr 2023, at 14:51, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> > 
> > Very interesting, thanks for sharing.
> > 
> > This is a very radical viewpoint, I think there is tons of research that can be done on alignment and for this reason I don't think we should shut it all down.
> > 
> > Obviously it's not a good idea to give access to such a system to everyone, I hope that at least we all start to understand this.
> > 
> > On Sat, 1 Apr 2023 at 13:52, MigMit <migmit at gmail.com> wrote:
> > Or this: https://time.com/6266923/ai-eliezer-yudkowsky-open-letter-not-enough/
> > 
> > (to which somebody said "I work in a datacenter. So far no AI threatened violence on me; Yudkowsky just did")
> > 
> > > On 1 Apr 2023, at 13:36, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> > > 
> > > I don't know, personally I could not stop laughing at the answer from version 3.5... it's so freaking stupid!
> > > 
> > > But if like Dominik you are scared after reading that part you might be interested to look into:
> > > https://futureoflife.org/open-letter/pause-giant-ai-experiments/
> > > 
> > > On Sat, 1 Apr 2023 at 11:44, Dominik Schrempf <dominik.schrempf at gmail.com> wrote:
> > > Well, it seems like GPT4 gets most of the questions right. This was more of a scary read than a funny one to me!
> > > 
> > > Dominik
> > > 
> > > On April 1, 2023 8:18:08 AM GMT+02:00, "Aloïs Cochard" <alois.cochard at gmail.com> wrote: How can this be useful when you have to anyway review everything is doing as he might to just randomly insert a bug or a security flaw???
> > > I prefer to read poems by my human friends.
> > > 
> > > I highly recommend starting reading this paper at page 128 instead of wasting your time on that prompt:
> > > https://arxiv.org/pdf/2303.12712.pdf
> > > 
> > > Be ready for a good laugh
> > > 
> > > Sincerely yours
> > > 
> > > 
> > > On Sat, 1 Apr 2023 at 05:36, William Yager <will.yager at gmail.com> wrote:
> > > On Fri, Mar 31, 2023 at 7:27 PM Mig Mit <migmit at gmail.com> wrote:
> > > How is it going to benefit anyone though? English, like all natural languages, is terrible for describing algorithms. 
> > > 
> > > 
> > > The other day, I asked ChatGPT to solve a boring but non-trivial programming problem I had:
> > > 
> > > > I have a png file which contains a bunch of 5x7 bitmap font characters. Write a python program which reads in the png, and then for each character in the png, extracts the 35 bits of each character and assembles them into an integer.  The final output should be a list of integers, each integer containing a binary representation of each character in the font.
> > > 
> > > It did this basically perfectly.  It wasn't precisely matched to my format, but only because I was ambiguous in the problem statement. I gave it a little more context about the image format and it did it exactly right on the second try.
> > > 
> > > I also asked it to write an inverse function of this, which it did perfectly in Python, and did pretty well in Rust, although with a small and understandable bug.
> > > 
> > > Very useful! 
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > To (un)subscribe, modify options or view archives go to:
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > Only members subscribed via the mailman list are allowed to post.
> > > 
> > > 
> > > 
> > > -- 
> > > Λ\oïs
> > > http://twitter.com/aloiscochard
> > > http://github.com/aloiscochard
> > 
> > 
> > 
> > -- 
> > Λ\oïs
> > http://twitter.com/aloiscochard
> > http://github.com/aloiscochard
> 
> 
> 
> -- 
> Λ\oïs
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard


From guthrie at miu.edu  Sat Apr  1 13:42:10 2023
From: guthrie at miu.edu (Gregory Guthrie)
Date: Sat, 1 Apr 2023 13:42:10 +0000
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAJHA+wo4jccaduJxCEJVeO1HtS0yAvC8tpBw5hU-bCarnt1TBg@mail.gmail.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
 <CAJHA+wo4jccaduJxCEJVeO1HtS0yAvC8tpBw5hU-bCarnt1TBg@mail.gmail.com>
Message-ID: <CH2PR03MB5224612BA773C5532308E1F6A18C9@CH2PR03MB5224.namprd03.prod.outlook.com>

Yes, will check on it.

That is because the reason that a simple program was used was because the example was to ask GPT to solve it is a range of languages, one of which was Haskell and there were links to solutions in all of them..

“Write binary search in xxxx.  Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states.”

  { HTML, CSS and JavaScript, C++, Haskell, JavaScript, Python, CommonLisp, C, C#, PHP, Java, Go, Erlang, Alloy, TLA+, X-Machine, PVS Verifier, SPIN model checker, Guarded Command Language, Hoare triples, Gries & Owicki concurrent code}

It was an interesting exercise from Dr. Nenad Koncar, a successful NL researcher and developer. I’ll ask him for a corrected link to the Haskell version.

Dr. Gregory Guthrie

From: Aloïs Cochard <alois.cochard at gmail.com>
Sent: Saturday, April 1, 2023 8:23 AM
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

Dear Gregory,

Can you please fix your onecompiler vanity link? It points to the C++ runtime implementation.

Thanks

On Fri, 31 Mar 2023 at 22:04, 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
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


--
Λ\oïs
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/ced528c0/attachment.html>

From will.yager at gmail.com  Sat Apr  1 13:48:03 2023
From: will.yager at gmail.com (Will Yager)
Date: Sat, 1 Apr 2023 09:48:03 -0400
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
References: <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
Message-ID: <FD5CB3CE-7265-430C-806D-18374BAF145F@gmail.com>



> On Apr 1, 2023, at 02:18, Aloïs Cochard <alois.cochard at gmail.com> wrote:
> 
> 
> How can this be useful when you have to anyway review everything is doing as he might to just randomly insert a bug or a security flaw???

The same question applies to hiring human programmers. 

> 
> I highly recommend starting reading this paper at page 128 instead of wasting your time on that prompt:

I'm not sure why you classify successfully getting practical tasks done faster as "wasting time". 

Best,
Will

From migmit at gmail.com  Sat Apr  1 13:57:15 2023
From: migmit at gmail.com (MigMit)
Date: Sat, 1 Apr 2023 15:57:15 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <FD5CB3CE-7265-430C-806D-18374BAF145F@gmail.com>
References: <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <FD5CB3CE-7265-430C-806D-18374BAF145F@gmail.com>
Message-ID: <DFA082F1-3E61-43D9-BA06-B437299BB0AA@gmail.com>

Well, human programmers can be shamed, yelled at, fired (which would actually hurt them), or, in extreme cases, prosecuted. They have every insentive to do their job right.

It's not a huge difference, but still.

> On 1 Apr 2023, at 15:48, Will Yager <will.yager at gmail.com> wrote:
> 
> 
> 
>> On Apr 1, 2023, at 02:18, Aloïs Cochard <alois.cochard at gmail.com> wrote:
>> 
>> 
>> How can this be useful when you have to anyway review everything is doing as he might to just randomly insert a bug or a security flaw???
> 
> The same question applies to hiring human programmers. 
> 
>> 
>> I highly recommend starting reading this paper at page 128 instead of wasting your time on that prompt:
> 
> I'm not sure why you classify successfully getting practical tasks done faster as "wasting time". 
> 
> Best,
> Will


From will.yager at gmail.com  Sat Apr  1 14:09:18 2023
From: will.yager at gmail.com (Will Yager)
Date: Sat, 1 Apr 2023 10:09:18 -0400
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <DFA082F1-3E61-43D9-BA06-B437299BB0AA@gmail.com>
References: <DFA082F1-3E61-43D9-BA06-B437299BB0AA@gmail.com>
Message-ID: <46E5DB49-A8D8-4F99-8E1C-617BE9743338@gmail.com>


> On Apr 1, 2023, at 09:57, MigMit <migmit at gmail.com> wrote:
> 
> Well, human programmers can be shamed, yelled at, fired (which would actually hurt them), or, in extreme cases, prosecuted. They have every insentive to do their job right.


ChatGPT has RLHF. It has incentives to do its job right as well. 

From migmit at gmail.com  Sat Apr  1 14:16:46 2023
From: migmit at gmail.com (MigMit)
Date: Sat, 1 Apr 2023 16:16:46 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <46E5DB49-A8D8-4F99-8E1C-617BE9743338@gmail.com>
References: <DFA082F1-3E61-43D9-BA06-B437299BB0AA@gmail.com>
 <46E5DB49-A8D8-4F99-8E1C-617BE9743338@gmail.com>
Message-ID: <4FA5CCEB-DF8F-4475-96EC-8B55144B0A14@gmail.com>

Depends. In the current arrangement, people who do RLHF (by the way, that's the first time I've seen this abbreviation, I'm sure) aren't likely to know it did a bad job.

If it's something under your control, yes, I would agree. Although we now headed straight into the AI rights territory (a programmer who is being yelled at a little too much can just quit).

> On 1 Apr 2023, at 16:09, Will Yager <will.yager at gmail.com> wrote:
> 
> 
>> On Apr 1, 2023, at 09:57, MigMit <migmit at gmail.com> wrote:
>> 
>> Well, human programmers can be shamed, yelled at, fired (which would actually hurt them), or, in extreme cases, prosecuted. They have every insentive to do their job right.
> 
> 
> ChatGPT has RLHF. It has incentives to do its job right as well.



From migmit at gmail.com  Sat Apr  1 14:16:46 2023
From: migmit at gmail.com (MigMit)
Date: Sat, 1 Apr 2023 16:16:46 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <46E5DB49-A8D8-4F99-8E1C-617BE9743338@gmail.com>
References: <DFA082F1-3E61-43D9-BA06-B437299BB0AA@gmail.com>
 <46E5DB49-A8D8-4F99-8E1C-617BE9743338@gmail.com>
Message-ID: <4FA5CCEB-DF8F-4475-96EC-8B55144B0A14@gmail.com>

Depends. In the current arrangement, people who do RLHF (by the way, that's the first time I've seen this abbreviation, I'm sure) aren't likely to know it did a bad job.

If it's something under your control, yes, I would agree. Although we now headed straight into the AI rights territory (a programmer who is being yelled at a little too much can just quit).

> On 1 Apr 2023, at 16:09, Will Yager <will.yager at gmail.com> wrote:
> 
> 
>> On Apr 1, 2023, at 09:57, MigMit <migmit at gmail.com> wrote:
>> 
>> Well, human programmers can be shamed, yelled at, fired (which would actually hurt them), or, in extreme cases, prosecuted. They have every insentive to do their job right.
> 
> 
> ChatGPT has RLHF. It has incentives to do its job right as well.



From sergueyz at gmail.com  Sat Apr  1 14:36:02 2023
From: sergueyz at gmail.com (Serguey Zefirov)
Date: Sat, 1 Apr 2023 17:36:02 +0300
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <46E5DB49-A8D8-4F99-8E1C-617BE9743338@gmail.com>
References: <DFA082F1-3E61-43D9-BA06-B437299BB0AA@gmail.com>
 <46E5DB49-A8D8-4F99-8E1C-617BE9743338@gmail.com>
Message-ID: <CABFQQ=AXq21DYvhoBd9Ee-c5AAN=hBxDr-aSNU-CQZwxCWaYmw@mail.gmail.com>

What does reinforcement learning from human behavior reinforces
exactly? The goal can be an engagement, which is the opposite of good
behavior of a professional programmer.

But my main concern with the code *produced* with ChatGPT is that the
code is *produced*. The model is generative, not transformative.

An anecdote: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt

I've yet to see an example of ChatGPT reducing the size of code. If
there are some, do their prompts still have directions to do so?

The code is a liability - it has to be supported, maintained, kept,
etc. I take a pride when I my changeset has more deletions than
insertions, a rare occasion.

2023-04-01 17:09 GMT+03:00, Will Yager <will.yager at gmail.com>:
>
>> On Apr 1, 2023, at 09:57, MigMit <migmit at gmail.com> wrote:
>>
>> Well, human programmers can be shamed, yelled at, fired (which would
>> actually hurt them), or, in extreme cases, prosecuted. They have every
>> insentive to do their job right.
>
>
> ChatGPT has RLHF. It has incentives to do its job right as well.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 ivanperezdominguez at gmail.com  Sat Apr  1 15:37:13 2023
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Sat, 1 Apr 2023 08:37:13 -0700
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CABFQQ=AXq21DYvhoBd9Ee-c5AAN=hBxDr-aSNU-CQZwxCWaYmw@mail.gmail.com>
References: <DFA082F1-3E61-43D9-BA06-B437299BB0AA@gmail.com>
 <46E5DB49-A8D8-4F99-8E1C-617BE9743338@gmail.com>
 <CABFQQ=AXq21DYvhoBd9Ee-c5AAN=hBxDr-aSNU-CQZwxCWaYmw@mail.gmail.com>
Message-ID: <CACZKWELQ-zXL5q07y1o-2xXsxZ6iArmFFgRdTQx-jjJOao7ysg@mail.gmail.com>

My two cents:

- ChatGPT knows not just Haskell, but also specific libraries like Copilot (
https://github.com/Copilot-Language/copilot/) and the FRP library Yampa (
https://github.com/ivanperez-keera/yampa). Here's an example:
https://www.facebook.com/photo?fbid=10161505593168357&set=a.427589328356

- At NASA we have systems (https://github.com/nasa/ogma) that help us
transform structured natural language into Copilot. ChatGPT may help us go
from unstructured NL to Copilot. We've tried it with properties like the
ones we use in actual work and it produces something that is 95% of the way
there. With the compiler for type checking, plus simulators and other tools
for debugging, this could really accelerate the process. Obviously we'd
need to check the result, etc. (which we already do regardless of who
writes it). We are studying this direction atm.

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

From ietf-dane at dukhovni.org  Sat Apr  1 16:52:50 2023
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 1 Apr 2023 12:52:50 -0400
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
Message-ID: <ZChhYiYqpsbNsref@straasha.imrryr.org>

On Sat, Apr 01, 2023 at 08:18:08AM +0200, Aloïs Cochard wrote:

> How can this be useful when you have to anyway review everything is doing
> as he might to just randomly insert a bug or a security flaw???
> I prefer to read poems by my human friends.
> 
> I highly recommend starting reading this paper at page 128 instead of
> wasting your time on that prompt:
> https://arxiv.org/pdf/2303.12712.pdf
> 
> Be ready for a good laugh

Part of the good laugh is on page 136:

    Let P be a point on the hyperbola

        x^2 + 3xy + 4x − 5y = −9y^2 − 133.

    Find the shortest possible distance from the origin to P.

The authors of the paper say that "GPT-4 produces a sound argument",
I beg to differ.

    Let u = 3y, then

        x^2 + xu + u^2 + 4x − (5/3)u = − 133.

    The degree-two part of which is positive-definite.  The linear terms
    just shift the origin. So the equation is actually:

        r^2 + rs + s^2 = RHS

    For a straight-forward to compute choice of r = x - a, s = u - b.

There are then two issues (just the first one is enough) with the prompt:

    * The equation can't represent a hyperbola, it would be an ellipse.
    * The ellipse doesn't exist, because the RHS constant is actually negative. 

THe authors are just as prone to autopilot nonsense reasoning as GPT-4.

This rather reminds me of:

    https://math.stackexchange.com/questions/1594740/v-i-arnold-says-russian-students-cant-solve-this-problem-but-american-student

-- 
    Viktor.

From alois.cochard at gmail.com  Sat Apr  1 17:16:38 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sat, 1 Apr 2023 19:16:38 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <ZChhYiYqpsbNsref@straasha.imrryr.org>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <ZChhYiYqpsbNsref@straasha.imrryr.org>
Message-ID: <CAJHA+wr-NwSF-CofBQWG9525J+33R=ukdeRdVBNv00n76WcSig@mail.gmail.com>

Thanks for that Viktor,

While I was holding my Giga Beer and looking at your delicious equations, I
started solving them using Japanese Multiplication:
https://www.youtube.com/watch?v=gngvWShRgX4

また会いましょう、そしてすべての魚に感謝します


On Sat, 1 Apr 2023 at 18:53, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:

> On Sat, Apr 01, 2023 at 08:18:08AM +0200, Aloïs Cochard wrote:
>
> > How can this be useful when you have to anyway review everything is doing
> > as he might to just randomly insert a bug or a security flaw???
> > I prefer to read poems by my human friends.
> >
> > I highly recommend starting reading this paper at page 128 instead of
> > wasting your time on that prompt:
> > https://arxiv.org/pdf/2303.12712.pdf
> >
> > Be ready for a good laugh
>
> Part of the good laugh is on page 136:
>
>     Let P be a point on the hyperbola
>
>         x^2 + 3xy + 4x − 5y = −9y^2 − 133.
>
>     Find the shortest possible distance from the origin to P.
>
> The authors of the paper say that "GPT-4 produces a sound argument",
> I beg to differ.
>
>     Let u = 3y, then
>
>         x^2 + xu + u^2 + 4x − (5/3)u = − 133.
>
>     The degree-two part of which is positive-definite.  The linear terms
>     just shift the origin. So the equation is actually:
>
>         r^2 + rs + s^2 = RHS
>
>     For a straight-forward to compute choice of r = x - a, s = u - b.
>
> There are then two issues (just the first one is enough) with the prompt:
>
>     * The equation can't represent a hyperbola, it would be an ellipse.
>     * The ellipse doesn't exist, because the RHS constant is actually
> negative.
>
> THe authors are just as prone to autopilot nonsense reasoning as GPT-4.
>
> This rather reminds me of:
>
>
> https://math.stackexchange.com/questions/1594740/v-i-arnold-says-russian-students-cant-solve-this-problem-but-american-student
>
> --
>     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.



-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/71ddcd1f/attachment.html>

From alois.cochard at gmail.com  Sat Apr  1 17:43:21 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sat, 1 Apr 2023 19:43:21 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CANePX3P6kn_FPcCJ1wosVUG9Ybf_JT6n0rPPbNB4mCMXeh-+zQ@mail.gmail.com>
References: <CH2PR03MB5224E32662DA939889E58F36A18F9@CH2PR03MB5224.namprd03.prod.outlook.com>
 <CAJHA+wo4jccaduJxCEJVeO1HtS0yAvC8tpBw5hU-bCarnt1TBg@mail.gmail.com>
 <CH2PR03MB5224612BA773C5532308E1F6A18C9@CH2PR03MB5224.namprd03.prod.outlook.com>
 <CANePX3PMubUA4+zr4T8q5tVnEBjKzDwn5SJf7RSYxn2uX7S-BA@mail.gmail.com>
 <CANePX3P6kn_FPcCJ1wosVUG9Ybf_JT6n0rPPbNB4mCMXeh-+zQ@mail.gmail.com>
Message-ID: <CAJHA+wpoeX+Sz4P376UhY83N=8wAsLhpknJcP+mUDZ6qDELCoQ@mail.gmail.com>

Thanks for fixing the link Nenad,

I leave you with an excerpt from Oleg's last paper which contains that
beautiful quote:

``This make me think that the authors are under the impression that
compilers can magically transform bad code into efficient high-quality code
by clever enough optimizations. As a compiler writer, I consider this a
complete myth that many students and non-compiler-developers hope is a
truth. I agree that compilers should aim to improve the efficiency of the
code given as input, but one cannot expect the compiler to recognize
algorithms and swap them for ones with better asymptotic complexity or *make
other major code transformations that really should be the job of the
programmer*. [emphasis mine]''

Magnus Myreen.

On Sat, 1 Apr 2023 at 18:06, Nenad Končar <nlpresearcher at gmail.com> wrote:

> GPT-4 when prompted with an improved prompt:
>
> *Write binary search in Haskel. Print results using putStrLn. Ensure
> bug-free code by specifying preconditions, postconditions, invariants,
> variants and internal states. Calculate the middle index using a safer
> formula to avoid intermediate overflow.*
>
>
>
> gives the following response:
>
> *-- Binary search is a recursive algorithm that finds an element in a
> sorted list by*
>
> *-- repeatedly dividing the list into two halves and comparing the element
> with the middle value.*
>
> *-- It returns the index of the element if found, or Nothing otherwise.*
>
>
>
> *-- Precondition: The input list must be sorted in ascending order.*
>
> *-- Postcondition: The output index must be within the bounds of the list
> and point to the element, or be Nothing.*
>
> *-- Invariant: The element, if present, must be in the current sublist.*
>
> *-- Variant: The length of the current sublist decreases by half at each
> recursive call.*
>
> *-- Internal state: The current sublist is defined by two indices: low and
> high.*
>
>
>
> *binarySearch :: Ord a => [a] -> a -> Maybe Int*
>
> *binarySearch xs x = go xs x 0 (length xs - 1)*
>
> *  where*
>
> *    -- The go function performs the recursive search on the sublist
> [low..high].*
>
> *    go :: Ord a => [a] -> a -> Int -> Int -> Maybe Int*
>
> *    go xs x low high*
>
> *      -- Base case 1: The sublist is empty, so the element is not found.*
>
> *      | low > high = Nothing*
>
> *      -- Base case 2: The middle value is equal to the element, so the
> index is found.*
>
> *      | xs !! mid == x = Just mid*
>
> *      -- Recursive case 1: The element is smaller than the middle value,
> so search in the left half.*
>
> *      | x < xs !! mid = go xs x low (mid - 1)*
>
> *      -- Recursive case 2: The element is larger than the middle value,
> so search in the right half.*
>
> *      | otherwise = go xs x (mid + 1) high*
>
> *      where*
>
> *        -- Calculate the middle index using a safer formula to avoid
> overflow.*
>
> *        mid = low + (high - low) `div` 2*
>
>
>
> *-- A sample list to test the binary search function.*
>
> *sampleList :: [Int]*
>
> *sampleList = [1, 3, 5, 7, 9, 11, 13, 15]*
>
>
>
> *-- A sample element to search for in the list.*
>
> *sampleElement :: Int*
>
> *sampleElement = 9*
>
>
>
> *-- Print the result of the binary search using putStrLn.*
>
> *main :: IO ()*
>
> *main = do*
>
> *  let result = binarySearch sampleList sampleElement*
>
> *  case result of*
>
> *    Nothing -> putStrLn "Element not found."*
> *    Just i -> putStrLn $ "Element found at index " ++ show i ++ "."*
>
> The above code runs:
> *https://onecompiler.com/haskell/3z4c7f5dt
> <https://onecompiler.com/haskell/3z4c7f5dt>*
>
>
> Furthermore, GPT-4 when prompted:
>
> *For the binary search algorithm, list all possible preconditions,
> postconditions, invariants, variants, internal states, underflows,
> overflows, divisions by zero, mistakes, errors, bugs, run-time exceptions,
> faults, defects and pitfalls.*
>
> and then prompting GPT-4 again with:
>
> *Summarize the following:*
>
> *<result from the previous prompt given to * *GPT-4*
> *>*
>
> gives the following response:
>
> *Hi there,*
>
> *I hope this email finds you well. I am writing to summarize the
> following:*
>
>
>
>
>
>
>
>
>
>
> *- The algorithm searches for a target value in a sorted array using
> binary search. - The algorithm returns the index of the target value in the
> array or -1 if the target value is not found. - The algorithm does not
> modify the input array. - The algorithm assumes that the input array is
> sorted in ascending or descending order, the target value is comparable
> with the elements of the array, and the lower and upper bounds of the
> search range are valid indices of the array. - The algorithm maintains the
> invariant that the target value is always within the search range or does
> not exist in the array. - The algorithm reduces the size of the search
> range by at least one after each iteration. - The algorithm handles edge
> cases such as empty array, single element array, target value at the first
> or last position of the array, lower and upper bounds being equal, negative
> or large positive integers, and division by zero when calculating the
> middle index. - The algorithm avoids integer underflow or overflow when
> calculating the middle index by using bitwise operations instead of
> arithmetic operations. - The algorithm has been tested with various test
> cases to ensure its correctness and efficiency. - The algorithm has been
> verified using formal methods to prove its preconditions, postconditions,
> invariants and variants.*
> *Please let me know if you have any questions or feedback about the
> algorithm. I appreciate your time and attention.*
>
>
> The following web pages provide some credence to GPT-4's claim of
> avoiding overflows/underflows by using bitwise operations instead of
> arithmetic operations:
>
> https://stackoverflow.com/questions/10078778/bitwise-overflow-checking-in-c
>
> https://www.opensourceforu.com/2009/03/joy-of-programming-how-to-detect-integer-overflow/
>
> The truth is that bitwise operations can recognise if an overflow is about
> to happen prior to it happening. I do not see how bitwise operations can
> *avoid* overflow and therefore GPT-4's claim in this case, in my humble
> view, should be classified as it having a *vivid imagination*.
>
>
>
>
>
>
> On Sat, 1 Apr 2023 at 16:11, Nenad Končar <nlpresearcher at gmail.com> wrote:
>
>> Here is the correct link to Haskel code:
>>
>> https://onecompiler.com/haskell/3z4c7f5dt
>>
>> On Sat, 1 Apr 2023 at 15:42, Gregory Guthrie <guthrie at miu.edu> wrote:
>>
>>> Yes, will check on it.
>>>
>>>
>>>
>>> That is because the reason that a simple program was used was because
>>> the example was to ask GPT to solve it is a range of languages, one of
>>> which was Haskell and there were links to solutions in all of them..
>>>
>>>
>>>
>>> “*Write binary search in xxxx.  Ensure bug-free code by specifying
>>> preconditions, postconditions, invariants, variants, internal states.”*
>>>
>>>
>>>
>>>   { HTML, CSS and JavaScript, C++, Haskell, JavaScript, Python,
>>> CommonLisp, C, C#, PHP, Java, Go, Erlang, Alloy, TLA+, X-Machine, PVS
>>> Verifier, SPIN model checker, Guarded Command Language, Hoare triples,
>>> Gries & Owicki concurrent code}
>>>
>>>
>>>
>>> It was an interesting exercise from Dr. Nenad Koncar, a successful NL
>>> researcher and developer. I’ll ask him for a corrected link to the Haskell
>>> version.
>>>
>>>
>>>
>>> Dr. Gregory Guthrie
>>>
>>>
>>>
>>> *From:* Aloïs Cochard <alois.cochard at gmail.com>
>>> *Sent:* Saturday, April 1, 2023 8:23 AM
>>> *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
>>>
>>>
>>>
>>> Dear Gregory,
>>>
>>>
>>>
>>> Can you please fix your onecompiler vanity link? It points to the C++
>>> runtime implementation.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> On Fri, 31 Mar 2023 at 22:04, 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.
>>>
>>>
>>>
>>> --
>>>
>>> *Λ\oïs*
>>>
>>> http://twitter.com/aloiscochard
>>>
>>> http://github.com/aloiscochard
>>>
>>

-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/ca94a1b2/attachment-0001.html>

From branimir.maksimovic at gmail.com  Sat Apr  1 21:26:21 2023
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Sat, 1 Apr 2023 23:26:21 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <ZChhYiYqpsbNsref@straasha.imrryr.org>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <ZChhYiYqpsbNsref@straasha.imrryr.org>
Message-ID: <3670F175-7D6D-41C9-AF33-050A2AED7D83@gmail.com>

Give it to solve this bellow one minute in Haskell:
https://projecteuler.net/problem=512I have shown it solution, but anyway really doubt it is programmed
to remember anything :P

Greets, Branimir.

> On 1. 4. 2023., at 18:52, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> On Sat, Apr 01, 2023 at 08:18:08AM +0200, Aloïs Cochard wrote:
> 
>> How can this be useful when you have to anyway review everything is doing
>> as he might to just randomly insert a bug or a security flaw???
>> I prefer to read poems by my human friends.
>> 
>> I highly recommend starting reading this paper at page 128 instead of
>> wasting your time on that prompt:
>> https://arxiv.org/pdf/2303.12712.pdf
>> 
>> Be ready for a good laughhi
> 
> Part of the good laugh is on page 136:
> 
>    Let P be a point on the hyperbola
> 
>        x^2 + 3xy + 4x − 5y = −9y^2 − 133.
> 
>    Find the shortest possible distance from the origin to P.
> 
> The authors of the paper say that "GPT-4 produces a sound argument",
> I beg to differ.
> 
>    Let u = 3y, then
> 
>        x^2 + xu + u^2 + 4x − (5/3)u = − 133.
> 
>    The degree-two part of which is positive-definite.  The linear terms
>    just shift the origin. So the equation is actually:
> 
>        r^2 + rs + s^2 = RHS
> 
>    For a straight-forward to compute choice of r = x - a, s = u - b.
> 
> There are then two issues (just the first one is enough) with the prompt:
> 
>    * The equation can't represent a hyperbola, it would be an ellipse.
>    * The ellipse doesn't exist, because the RHS constant is actually negative. 
> 
> THe authors are just as prone to autopilot nonsense reasoning as GPT-4.
> 
> This rather reminds me of:
> 
>    https://math.stackexchange.com/questions/1594740/v-i-arnold-says-russian-students-cant-solve-this-problem-but-american-student
> 
> -- 
>    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/20230401/1172584e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apple-touch-icon.png
Type: image/png
Size: 4501 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/1172584e/attachment.png>

From alois.cochard at gmail.com  Sat Apr  1 22:38:10 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sun, 2 Apr 2023 00:38:10 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <3670F175-7D6D-41C9-AF33-050A2AED7D83@gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <ZChhYiYqpsbNsref@straasha.imrryr.org>
 <3670F175-7D6D-41C9-AF33-050A2AED7D83@gmail.com>
Message-ID: <CAJHA+wpmWSudNO2JiTiUD9k0dvzRwSmG4uW53aeRaY3GgAOuHg@mail.gmail.com>

I'm sorry, I'm too busy adding constraints to the next version of Chat j'ai
peter.

On Sat, 1 Apr 2023 at 23:26, Branimir Maksimovic <
branimir.maksimovic at gmail.com> wrote:

> Give it to solve this bellow one minute in Haskell:
> #512 Sums of totients of powers <https://projecteuler.net/problem=512>
> projecteuler.net <https://projecteuler.net/problem=512>
> [image: apple-touch-icon.png] <https://projecteuler.net/problem=512>
> <https://projecteuler.net/problem=512>
> I have shown it solution, but anyway really doubt it is programmed
> to remember anything :P
>
> Greets, Branimir.
>
> On 1. 4. 2023., at 18:52, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>
> On Sat, Apr 01, 2023 at 08:18:08AM +0200, Aloïs Cochard wrote:
>
> How can this be useful when you have to anyway review everything is doing
> as he might to just randomly insert a bug or a security flaw???
> I prefer to read poems by my human friends.
>
> I highly recommend starting reading this paper at page 128 instead of
> wasting your time on that prompt:
> https://arxiv.org/pdf/2303.12712.pdf
>
> Be ready for a good laughhi
>
>
> Part of the good laugh is on page 136:
>
>    Let P be a point on the hyperbola
>
>        x^2 + 3xy + 4x − 5y = −9y^2 − 133.
>
>    Find the shortest possible distance from the origin to P.
>
> The authors of the paper say that "GPT-4 produces a sound argument",
> I beg to differ.
>
>    Let u = 3y, then
>
>        x^2 + xu + u^2 + 4x − (5/3)u = − 133.
>
>    The degree-two part of which is positive-definite.  The linear terms
>    just shift the origin. So the equation is actually:
>
>        r^2 + rs + s^2 = RHS
>
>    For a straight-forward to compute choice of r = x - a, s = u - b.
>
> There are then two issues (just the first one is enough) with the prompt:
>
>    * The equation can't represent a hyperbola, it would be an ellipse.
>    * The ellipse doesn't exist, because the RHS constant is actually
> negative.
>
> THe authors are just as prone to autopilot nonsense reasoning as GPT-4.
>
> This rather reminds me of:
>
>
> https://math.stackexchange.com/questions/1594740/v-i-arnold-says-russian-students-cant-solve-this-problem-but-american-student
>
> --
>    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.



-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230402/71d29366/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apple-touch-icon.png
Type: image/png
Size: 4501 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230402/71d29366/attachment.png>

From mihai.maruseac at gmail.com  Sat Apr  1 23:38:55 2023
From: mihai.maruseac at gmail.com (Mihai Maruseac)
Date: Sat, 1 Apr 2023 16:38:55 -0700
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAJHA+wpmWSudNO2JiTiUD9k0dvzRwSmG4uW53aeRaY3GgAOuHg@mail.gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <ZChhYiYqpsbNsref@straasha.imrryr.org>
 <3670F175-7D6D-41C9-AF33-050A2AED7D83@gmail.com>
 <CAJHA+wpmWSudNO2JiTiUD9k0dvzRwSmG4uW53aeRaY3GgAOuHg@mail.gmail.com>
Message-ID: <CAOMsUML9Dkr7sbdTpBCyXhkXd+kOfz=mo+eSKimts6UCDig2dg@mail.gmail.com>

At the risk of touting my own horn, I have been running experiments with
chatGPT a while ago and both math (https://mihai.page/chatgpt/) and Haskell
(https://mihai.page/chatgpt-2/) were still not there.

I need to repeat these experiments though for the new version, these were
run when GPT-3 was top of the line.

On Sat, Apr 1, 2023 at 3:38 PM Aloïs Cochard <alois.cochard at gmail.com>
wrote:

> I'm sorry, I'm too busy adding constraints to the next version of Chat
> j'ai peter.
>
> On Sat, 1 Apr 2023 at 23:26, Branimir Maksimovic <
> branimir.maksimovic at gmail.com> wrote:
>
>> Give it to solve this bellow one minute in Haskell:
>> #512 Sums of totients of powers <https://projecteuler.net/problem=512>
>> projecteuler.net <https://projecteuler.net/problem=512>
>> [image: apple-touch-icon.png] <https://projecteuler.net/problem=512>
>> <https://projecteuler.net/problem=512>
>> I have shown it solution, but anyway really doubt it is programmed
>> to remember anything :P
>>
>> Greets, Branimir.
>>
>> On 1. 4. 2023., at 18:52, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>>
>> On Sat, Apr 01, 2023 at 08:18:08AM +0200, Aloïs Cochard wrote:
>>
>> How can this be useful when you have to anyway review everything is doing
>> as he might to just randomly insert a bug or a security flaw???
>> I prefer to read poems by my human friends.
>>
>> I highly recommend starting reading this paper at page 128 instead of
>> wasting your time on that prompt:
>> https://arxiv.org/pdf/2303.12712.pdf
>>
>> Be ready for a good laughhi
>>
>>
>> Part of the good laugh is on page 136:
>>
>>    Let P be a point on the hyperbola
>>
>>        x^2 + 3xy + 4x − 5y = −9y^2 − 133.
>>
>>    Find the shortest possible distance from the origin to P.
>>
>> The authors of the paper say that "GPT-4 produces a sound argument",
>> I beg to differ.
>>
>>    Let u = 3y, then
>>
>>        x^2 + xu + u^2 + 4x − (5/3)u = − 133.
>>
>>    The degree-two part of which is positive-definite.  The linear terms
>>    just shift the origin. So the equation is actually:
>>
>>        r^2 + rs + s^2 = RHS
>>
>>    For a straight-forward to compute choice of r = x - a, s = u - b.
>>
>> There are then two issues (just the first one is enough) with the prompt:
>>
>>    * The equation can't represent a hyperbola, it would be an ellipse.
>>    * The ellipse doesn't exist, because the RHS constant is actually
>> negative.
>>
>> THe authors are just as prone to autopilot nonsense reasoning as GPT-4.
>>
>> This rather reminds me of:
>>
>>
>> https://math.stackexchange.com/questions/1594740/v-i-arnold-says-russian-students-cant-solve-this-problem-but-american-student
>>
>> --
>>    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.
>
>
>
> --
> *Λ\oïs*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Mihai Maruseac (MM)
"If you can't solve a problem, then there's an easier problem you can
solve: find it." -- George Polya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/4da46da9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apple-touch-icon.png
Type: image/png
Size: 4501 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230401/4da46da9/attachment.png>

From alois.cochard at gmail.com  Sun Apr  2 06:12:18 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sun, 2 Apr 2023 08:12:18 +0200
Subject: [Haskell-cafe] GPT & Haskell
In-Reply-To: <CAOMsUML9Dkr7sbdTpBCyXhkXd+kOfz=mo+eSKimts6UCDig2dg@mail.gmail.com>
References: <37B8FCD1-29B7-42D2-A223-33FD3598B4ED@yasuaki.com>
 <1322B6CC-52B7-43D2-B2D4-9FD000D447BC@gmail.com>
 <CAG8oi1PzmeATj3prquft8fi0uod=F-Tym2mqpQJ=U3e5ay342A@mail.gmail.com>
 <CAJHA+wqsPAV11C0cDr6Ze-yaBHo4a6r5QFWEAUzDH+zehnGAOQ@mail.gmail.com>
 <ZChhYiYqpsbNsref@straasha.imrryr.org>
 <3670F175-7D6D-41C9-AF33-050A2AED7D83@gmail.com>
 <CAJHA+wpmWSudNO2JiTiUD9k0dvzRwSmG4uW53aeRaY3GgAOuHg@mail.gmail.com>
 <CAOMsUML9Dkr7sbdTpBCyXhkXd+kOfz=mo+eSKimts6UCDig2dg@mail.gmail.com>
Message-ID: <CAJHA+wrOs6mEf3rdTdYx8DEcS78Sphwv2GtTn81K670vW-CVPA@mail.gmail.com>

Absolutely no idea if there is an improvement, but this will should
eventually help for such mathematical shenanigans:
https://thenewstack.io/wolfram-chatgpt-plugin-blends-symbolic-ai-with-generative-ai/

Anyway, I hope everyone had a good April Fool's Day.
<https://en.wikipedia.org/wiki/April_Fools%27_Day>

On Sun, 2 Apr 2023 at 01:39, Mihai Maruseac <mihai.maruseac at gmail.com>
wrote:

> At the risk of touting my own horn, I have been running experiments with
> chatGPT a while ago and both math (https://mihai.page/chatgpt/) and
> Haskell (https://mihai.page/chatgpt-2/) were still not there.
>
> I need to repeat these experiments though for the new version, these were
> run when GPT-3 was top of the line.
>
> On Sat, Apr 1, 2023 at 3:38 PM Aloïs Cochard <alois.cochard at gmail.com>
> wrote:
>
>> I'm sorry, I'm too busy adding constraints to the next version of Chat
>> j'ai peter.
>>
>> On Sat, 1 Apr 2023 at 23:26, Branimir Maksimovic <
>> branimir.maksimovic at gmail.com> wrote:
>>
>>> Give it to solve this bellow one minute in Haskell:
>>> #512 Sums of totients of powers <https://projecteuler.net/problem=512>
>>> projecteuler.net <https://projecteuler.net/problem=512>
>>> [image: apple-touch-icon.png] <https://projecteuler.net/problem=512>
>>> <https://projecteuler.net/problem=512>
>>> I have shown it solution, but anyway really doubt it is programmed
>>> to remember anything :P
>>>
>>> Greets, Branimir.
>>>
>>> On 1. 4. 2023., at 18:52, Viktor Dukhovni <ietf-dane at dukhovni.org>
>>> wrote:
>>>
>>> On Sat, Apr 01, 2023 at 08:18:08AM +0200, Aloïs Cochard wrote:
>>>
>>> How can this be useful when you have to anyway review everything is doing
>>> as he might to just randomly insert a bug or a security flaw???
>>> I prefer to read poems by my human friends.
>>>
>>> I highly recommend starting reading this paper at page 128 instead of
>>> wasting your time on that prompt:
>>> https://arxiv.org/pdf/2303.12712.pdf
>>>
>>> Be ready for a good laughhi
>>>
>>>
>>> Part of the good laugh is on page 136:
>>>
>>>    Let P be a point on the hyperbola
>>>
>>>        x^2 + 3xy + 4x − 5y = −9y^2 − 133.
>>>
>>>    Find the shortest possible distance from the origin to P.
>>>
>>> The authors of the paper say that "GPT-4 produces a sound argument",
>>> I beg to differ.
>>>
>>>    Let u = 3y, then
>>>
>>>        x^2 + xu + u^2 + 4x − (5/3)u = − 133.
>>>
>>>    The degree-two part of which is positive-definite.  The linear terms
>>>    just shift the origin. So the equation is actually:
>>>
>>>        r^2 + rs + s^2 = RHS
>>>
>>>    For a straight-forward to compute choice of r = x - a, s = u - b.
>>>
>>> There are then two issues (just the first one is enough) with the prompt:
>>>
>>>    * The equation can't represent a hyperbola, it would be an ellipse.
>>>    * The ellipse doesn't exist, because the RHS constant is actually
>>> negative.
>>>
>>> THe authors are just as prone to autopilot nonsense reasoning as GPT-4.
>>>
>>> This rather reminds me of:
>>>
>>>
>>> https://math.stackexchange.com/questions/1594740/v-i-arnold-says-russian-students-cant-solve-this-problem-but-american-student
>>>
>>> --
>>>    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.
>>
>>
>>
>> --
>> *Λ\oïs*
>> http://twitter.com/aloiscochard
>> http://github.com/aloiscochard
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> Mihai Maruseac (MM)
> "If you can't solve a problem, then there's an easier problem you can
> solve: find it." -- George Polya
>


-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230402/621547ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apple-touch-icon.png
Type: image/png
Size: 4501 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230402/621547ae/attachment.png>

From ifl21.publicity at gmail.com  Mon Apr  3 09:55:40 2023
From: ifl21.publicity at gmail.com (Pieter Koopman)
Date: Mon, 3 Apr 2023 02:55:40 -0700
Subject: [Haskell-cafe] IFL23 first CFP
Message-ID: <CAGtcRvD1w2fETi6EQUS1qez_tCdWVNsAb9_EELcpPvuBmHkwZg@mail.gmail.com>

*Call for papers*

The 35th Symposium on Implementation and Application of Functional
Languages (IFL 2023)

Braga, Portugal, August 29th-August 31st, 2023
*Important dates*

Draft paper submission:      July   31st, 2023
Draft paper notification:    August  1st, 2023
Early registration deadline: August 11th, 2023
Late registration deadline:  August 23rd, 2023
Symposium:                   August 29th - August 31st (3 days)
*Scope*

The goal of the IFL symposia is to bring together researchers actively
engaged in the implementation and application of functional and
function-based programming languages. IFL 2022 will be a venue for
researchers to present and discuss new ideas and concepts, work in
progress, and publication-ripe results related to the implementation
and application of functional languages and function-based
programming.

Topics of interest to IFL include, but are not limited to:

* language concepts
* type systems, type checking, type inferencing
* compilation techniques
* staged compilation
* run-time function specialization
* run-time code generation
* partial evaluation
* abstract interpretation
* metaprogramming
* generic programming
* automatic program generation
* array processing
* concurrent/parallel programming
* concurrent/parallel program execution
* embedded systems
* web applications
* embedded domain specific languages
* security
* novel memory management techniques
* run-time profiling performance measurements
* debugging and tracing
* virtual/abstract machine architectures
* validation, verification of functional programs
* tools and programming techniques
* industrial applications
*Submissions and peer-review
*
Following IFL tradition, IFL 2023 will use a post-symposium review
process to produce the formal proceedings.

Before the symposium authors submit draft papers. These draft papers
will be screened by the program chair to make sure that they are
within the scope of IFL. The draft papers will be made available to
all participants at the symposium. Each draft paper is presented by
one of the authors at the symposium. Notice that it is a requirement
that accepted draft papers are presented physically at the symposium.

After the symposium, a formal review process will take place,
conducted by the program committee.  Reviewing is single blind. There
will be at least 3 reviews per paper. The reviewers have 6 weeks to
write their reviews. For the camera-ready version the authors can make
minor revisions which are accepted without further reviewing.

Contributions submitted for the draft paper deadline must be between
two and twelve pages long. For submission details, please consult the
IFL 2023 website at https://ifl23.github.io/
<https://ifl21-publicity-dot-yamm-track.appspot.com/2FXkDEWOUAQ2Tbyu5BN0P9ImiDAdgC8zBHnfVFxVTHg8jKotGhwEabn22eAY6oIeusuoKMFC9HwArxPQXyuk8WonH6C-SsBR0jHHiiZJijsEY8OrPP84ehGRc3y22oSuCX7VLGx27ndFMUdR43LFJTfpPvOeDJRI0H1yEie16q5rz2LqGYYw-Vgk>
.
*Where
*
IFL 2023 will be held physically in Braga, Portugal, arranged by
University of Minho.

See the IFL 2023 website at https://ifl23.github.io/
<https://ifl21-publicity-dot-yamm-track.appspot.com/2vSkCLOx6DJpj_Yo1M1_gXPfX0STbOHMkL9c5pIoi7dolKotGhwE5MiqIZyFRHGYbqORW1-MYfwHjba8sK7NZPtl7kMYUaz6XD8zzqt6ir6r-jNkcIVaLxoR2eA6JFpYweMHlH7LwvElfs1vq0fq0VCaCfy1PeGG2Y9FRIMQg3zsOwdQ2VrQmVsw>
for more
information.

[image: beacon]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230403/c738b8cf/attachment.html>

From scm at iis.sinica.edu.tw  Tue Apr  4 04:04:55 2023
From: scm at iis.sinica.edu.tw (Shin-Cheng Mu)
Date: Tue, 4 Apr 2023 12:04:55 +0800
Subject: [Haskell-cafe] APLAS 2023 first Call for Papers
Message-ID: <E9838135-8182-4C08-82B7-7D4557FC344E@iis.sinica.edu.tw>


======================================================================
CALL FOR PAPERS

21st Asian Symposium on Programming Languages and Systems (APLAS 2023)
Taipei, Taiwan, Sun 26 – Wed 29 November 2023

https://conf.researchr.org/home/aplas-2023
======================================================================


IMPORTANT DATES
-------------------------------------
Submission deadline: Thu 15 Jun 2023 AoE
Author response: Mon 31 Jul 12:00 - Wed 2 Aug 12:00 2023 AoE
Author notification: Mon 14 Aug 2023 AoE
Final paper deadline: Wed 6 Sep 2023 AoE
Conference: Sun 26 – Wed 29 Nov 2023


SCOPE
-------------------------------------
We solicit submissions in the form of regular research papers
describing original scientific research results, including system
development and case studies. Among others, solicited topics include:

- ** programming paradigms and styles ** : 
  
  functional programming; object-oriented programming; probabilistic 
  programming; logic
  programming; constraint programming; extensible programming
  languages; programming languages for systems code; novel programming
  paradigms;

- ** methods and tools to specify and reason about programs and
  languages ** : 

  programming techniques; meta-programming; domain-specific
  languages; proof assistants; type systems; dependent types; program
  logics, static and dynamic program analysis; language-based
  security; model checking; testing;

- ** programming language foundations ** : 

  formal semantics; type theory; logical foundations; category 
  theory; automata; effects; monads and comonads; recursion and 
  corecursion; continuations and effect handlers; program 
  verification; memory models; abstract interpretation;

- ** methods and tools for implementation ** : 

  compilers; program transformations; rewriting systems; 
  partial evaluation; virtual machines; refactoring; intermediate 
  languages; run-time environments; garbage collection and memory 
  management; tracing; profiling; build systems; program synthesis;

- ** concurrency and distribution ** : 

  process algebras; concurrency theory; session types; parallel 
  programming; service-oriented computing; distributed and mobile 
  computing; actor-based languages; verification and testing of 
  concurrent and distributed systems;

- ** applications and emerging topics ** : 

  programming languages and PL methods in education, security, 
  privacy, database systems, computational biology, signal 
  processing, graphics, human-computer interaction, computer-aided 
  design, artificial intelligence and machine learning; case 
  studies in program analysis and verification.


GENERAL INFORMATION 
-------------------------------------
Submissions should not exceed 17 pages, excluding bibliography in the
Springer LNCS format. LaTeX template is available at:

  https://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines

The accepted papers will be allowed to use one extra page for the
content to accommodate feedback from the reviews in the final paper
versions.

Papers should be submitted via HotCRP:

  https://aplas2023.hotcrp.com/

The review process of APLAS 2023 is double-anonymous, with a rebuttal
phase. In your submission, please, omit your names and institutions;
refer to your prior work in the third person, just as you refer to
prior work by others; do not include acknowledgments that might
identify you.

Additional material intended for reviewers but not for publication in
the final version - for example, details of proofs - may be placed in
a clearly marked appendix that is not included in the page limit.
Reviewers are at liberty to ignore appendices and papers must be
understandable without them.

Submitted papers must be unpublished and not submitted for publication
elsewhere. Papers must be written in English. The proceedings will be
published as a volume in Springer’s LNCS series. Accepted papers must
be presented at the conference.


POSTERS and STUDENT RESEARCH COMPETITION
----------------------------------------

APLAS 2023 includes a Posters session and a Student Research 
Competition. For more details, please see the website.

 https://conf.researchr.org/track/aplas-2023/posters-and-src


ORGANIZERS
-------------------------------------

General Chair:

  Shin-Cheng Mu, Academia Sinica, Taiwan

Program Chair:

  Chung-Kil Hur, Seoul National University, Korea

Publicity Chair:

  Ryosuke Sato, University of Tokyo, Japan

Program Committee:

  Soham Chakraborty, TU Delft, Netherlands
  Yu-Fang Chen, Academia Sinica, Taiwan
  Ronghui Gu, Columbia University, USA
  Ichiro Hasuo, National Institute of Informatics, Japan
  Ralf Jung, ETH Zurich, Switzerland
  Ohad Kammar, University of Edinburgh, UK
  Jeehoon Kang, KAIST, Korea
  Jieung Kim, Inha University, Korea
  Robbert Krebbers, Radboud University Nijmegen, Netherlands
  Ori Lahav, Tel Aviv University, Israel
  Doug Lea, State University of New York at Oswego, USA
  Woosuk Lee, Hanyang University, Korea
  Hongjin Liang, Nanjing University, China
  Nuno P. Lopes, University of Lisbon, Portugal
  Chandrakana Nandi, Certora and UW, USA
  Liam O'Connor, The University of Edinburgh, UK
  Bruno C. d. S. Oliveira, The University of Hong Kong, Hong Kong
  Jihyeok Park, Korea University, Korea
  Clément Pit-Claudel, EPFL, Switzerland
  Matthieu Sozeau, Inria, France
  Kohei Suenaga, Kyoto University, Japan
  Tarmo Uustalu, Reykjavik University, Iceland
  John Wickerson, Imperial College London, UK
  Danfeng Zhang, Penn State University, USA

From benjamin.redelings at gmail.com  Tue Apr  4 15:22:04 2023
From: benjamin.redelings at gmail.com (Benjamin Redelings)
Date: Tue, 4 Apr 2023 11:22:04 -0400
Subject: [Haskell-cafe] log, exp, (**), and non-negative real numbers
Message-ID: <6b15315d-b723-3c21-3185-18b698e986cc@gmail.com>

Hi,

I'm working with some classes that handle probabilities in terms of 
their log or log-odds.  Such classes only handle non-negative real 
numbers.  For example, from Numeric.Log:

     newtype Log a = Exp { ln :: a }

Since the log of a positive number can be negative, we don't want to use 
the same type to hold the number and its logarithm. Standard functions 
exp, log, and (**) are awkward because they all assume that numbers and 
their powers have the same type:

    log,exp :: a -> a
    (**) :: a -> a -> a

In comparison the ln function from Numeric.Log has a different signature 
that allows a number and its logarithm to have different types:

    ln :: Log a -> a
    Exp :: a -> Log a

In order to address this, I have tried defining a type class Pow:

    class Fractional a => Pow a where
       pow :: a -> Double -> a
       ln  :: a -> Double
       expTo :: Double -> a

Probably I should replace "Double" here by a type variable b, but I have 
not done so yet.  I'm mostly interested in abstracting over the type of 
non-negative number, because I have another type Prob that is designed 
to handle numbers like 1e - 100000, and 1.0 - 1e-100000.

     data Prob = Zero | Odds Double | One | IOdds Double | Infinity  -- 
store probability in terms of log odds = log (p/(1-p))

Q1. Does anybody know of an existing Haskell module that implements 
something like the Pow class above?

Also, it would be nice (notationally) if I could use log, exp, and (**) 
instead of ln, expTo, and pow.  In theory we could factor out log, exp, 
(**), sqrt, and logBase from Floating into a new superclass of Floating, 
so that Floating only contains trig and hyper-trig functions.

But I suspect this will not work because the methods in class Pow are 
more ambiguous. For example, if (x :: Double) then you can do (expTo x 
:: Prob) and (expTo x :: Log Double) and they will yield different types.

Q2. Does anybody have a suggestion for a nicer design?

Thanks!

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

From will.yager at gmail.com  Tue Apr  4 15:50:41 2023
From: will.yager at gmail.com (Will Yager)
Date: Tue, 4 Apr 2023 05:50:41 -1000
Subject: [Haskell-cafe] log, exp, (**), and non-negative real numbers
In-Reply-To: <6b15315d-b723-3c21-3185-18b698e986cc@gmail.com>
References: <6b15315d-b723-3c21-3185-18b698e986cc@gmail.com>
Message-ID: <5522CAB5-74DD-4EFC-AD06-FA59CABB1217@gmail.com>

If you end up coming up with a nice library design, you may want to generalize these operations from Double-valued logarithms to conversions between a Lie group and its corresponding Lie algebra. 

Exp/ln on all/positive real numbers is a special case of exp/ln on a lie algebra/group. 

Maybe worth checking if there already exists a package for working with lie groups in a nicely-typed way. If there's not a haskell one, I bet one of the theorem prover languages (coq, agda, idris) has one. 

Best,
Will

From ietf-dane at dukhovni.org  Tue Apr  4 16:26:43 2023
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 4 Apr 2023 12:26:43 -0400
Subject: [Haskell-cafe] log, exp, (**), and non-negative real numbers
In-Reply-To: <5522CAB5-74DD-4EFC-AD06-FA59CABB1217@gmail.com>
References: <6b15315d-b723-3c21-3185-18b698e986cc@gmail.com>
 <5522CAB5-74DD-4EFC-AD06-FA59CABB1217@gmail.com>
Message-ID: <ZCxPw1R47mGS8x0C@straasha.imrryr.org>

On Tue, Apr 04, 2023 at 05:50:41AM -1000, Will Yager wrote:

> If you end up coming up with a nice library design, you may want to
> generalize these operations from Double-valued logarithms to
> conversions between a Lie group and its corresponding Lie algebra. 

Abstracting from the positive reals to (possibly non-abelian, complex?)
Lie groups is a rather steep generalisation.  Is there no useful
intermediate step?

Or is it the case here that the most general form is also the simplest
(does away with inessential details that distract from the core
concepts)?

I do recall that for me at one point Calculus in Banach spaces was
easier to understand than Calculus in R^3.  The generalisation was
cleaner.

-- 
    Viktor.

From mmcconnell17704 at yahoo.com  Tue Apr  4 17:47:09 2023
From: mmcconnell17704 at yahoo.com (Mark McConnell)
Date: Tue, 4 Apr 2023 17:47:09 +0000 (UTC)
Subject: [Haskell-cafe] log, exp, (**), and non-negative real numbers
In-Reply-To: <5522CAB5-74DD-4EFC-AD06-FA59CABB1217@gmail.com>
References: <6b15315d-b723-3c21-3185-18b698e986cc@gmail.com>
 <5522CAB5-74DD-4EFC-AD06-FA59CABB1217@gmail.com>
Message-ID: <58359534.2884926.1680630429132@mail.yahoo.com>

 I like the Lie algebra suggestion, but I doubt that, out of the box, it would support the tiny probabilities like 1e-100000 that Benjamin supports.
    On Tuesday, April 4, 2023 at 11:51:11 AM EDT, Will Yager <will.yager at gmail.com> wrote:  
 
 If you end up coming up with a nice library design, you may want to generalize these operations from Double-valued logarithms to conversions between a Lie group and its corresponding Lie algebra. 

Exp/ln on all/positive real numbers is a special case of exp/ln on a lie algebra/group. 

Maybe worth checking if there already exists a package for working with lie groups in a nicely-typed way. If there's not a haskell one, I bet one of the theorem prover languages (coq, agda, idris) has one. 

Best,
Will
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view 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/20230404/33332c97/attachment.html>

From ivanperezdominguez at gmail.com  Sat Apr  8 23:49:57 2023
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Sat, 8 Apr 2023 16:49:57 -0700
Subject: [Haskell-cafe] [ANN] Yampa 0.14.2, yampa-gloss 0.2.1,
	haskanoid 0.1.6, and more
Message-ID: <CACZKWEK6qVXkpw2p77PKuSWKGGZPeJfi8sbQ70_OMx_tNxQScg@mail.gmail.com>

Hello everyone,

I'm super excited to announce the release of Yampa 0.14.2! This release
also comes with accompanying releases of many related projects:
yampa-test (0.14.2), simple-affine-space (0.2.1), yampa-gloss (0.2.1),
Space Invaders (0.14.2), and Haskanoid (0.1.6).

Yampa is a fast, elegant Functional Reactive Programming
implementation. Yampa prides itself in being a long-standing community
project. It has now been around for 20 years!!! See
https://github.com/ivanperez-keera/yampa#features for details on
Yampa's features.

This release has address mainly styling issues. All library code now
conforms to the main rules of the style guide we follow (which is
publicly documented).  We've also addressed other minor maintenance
issues, like compatibility with new versions of GHC and some
dependencies, installation and CI issues, fixes to the README, and
pointers to related community projects. In total, there have been more
than 400 commits!

Special thanks go to Miao ZhiCheng (@hellwolf) for a generous donation
towards this release, and to @johannes-riecken for a regular
contribution to support the Yampa project.

All the projects listed above have been released in sync. For details,
see:

- https://github.com/ivanperez-keera/Yampa/releases/tag/v0.14.2

- https://github.com/ivanperez-keera/yampa-gloss/releases/tag/v0.2.1

- https://github.com/ivanperez-keera/simple-affine-space/releases/tag/v0.2.1

- https://github.com/ivanperez-keera/SpaceInvaders/releases/tag/v0.14.2

- https://github.com/ivanperez-keera/haskanoid/releases/tag/v0.1.6

You can explore the current versions at:

- https://hackage.haskell.org/package/Yampa

- https://hackage.haskell.org/package/yampa-test

- https://hackage.haskell.org/package/yampa-gloss

- https://hackage.haskell.org/package/simple-affine-space

- https://hackage.haskell.org/package/SpaceInvaders

- https://hackage.haskell.org/package/haskanoid

*Code*

The github repos are located at:

- https://github.com/ivanperez-keera/Yampa/

- https://github.com/ivanperez-keera/yampa-gloss/

- https://github.com/ivanperez-keera/simple-affine-space/

- https://github.com/ivanperez-keera/SpaceInvaders/

- https://github.com/ivanperez-keera/haskanoid/

*What's coming*

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

There are several issues open that you can contribute in each project's
issue tracker:

Following our roadmap, the pending changes remain as follows:

- Removal of unnecessarily exposed elements from the interface (e.g.,
  FRP.Yampa.Arrow.arr3) that are not used and belong in other
  libraries. This topic is open to discussion.

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

- New mailing list: We will in the future lose access to Yale's CS
  department-based mailman list, and are thinking of the best place to
  move the mailing list to.

*Donations*

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

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/20230408/1f581f52/attachment.html>

From ruben.astud at gmail.com  Tue Apr 11 20:32:29 2023
From: ruben.astud at gmail.com (Ruben Astudillo)
Date: Tue, 11 Apr 2023 16:32:29 -0400
Subject: [Haskell-cafe] [ANN] data-forced 0.1.0.0 released!
Message-ID: <c2c6fcbb-d7b5-ba4a-7786-c1c4e23f6db5@gmail.com>

Hello everyone,

I am excited to release the first version of data-forced 0.1.0.0. You can
get it on

    <https://hackage.haskell.org/package/data-forced-0.1.0.0>
    <https://github.com/RubenAstudillo/data-forced>

This is a library to avoid reference leaks (liveness leaks) on long lived
data structures close to main. It does so without using explicit `seq` or
bang patterns, instead using CBV functions, unlifted data type and tagging
evaluated values with a unexported newtype constructor. It is a bang pattern
you cannot forget!

# The big idea

We should not throw the information that a value was forced to WHNF or NF.
We neither should be required to remember to put a `seq` or BangPattern at
the use site to maintain this invariant.

We accomplish this using two newtypes:

- `newtype ForcedWHNF a = ForcedWHNF a`
- `newtype ForcedNF a = ForcedNF a`

that don't have their constructors exported. Only unidirectional patterns
are provided so you can de-structure them.

The *only* way to construct values of these types is via two CBVs
functions:

- strictlyWHNF :: forall a. a -> Strict (ForcedWHNF a)
- strictlyNF :: forall a. NFData a => a -> Strict (ForcedNF a)

The Strict data type is inspired by its analog on the data-elevator
package <https://hackage.haskell.org/package/data-elevator>. It is a
UnliftedDatatype, which means it cannot contain bottoms. The dynamic
semantics of bound values of unlifted data types is that *before being
bound, these are evaluated to WHNF*. It is a BangPattern you cannot forget!

Once you obtain the `Strict (ForcedWHNF a)` value, you de-structurate it to
obtain the *lifted* `ForceWHNF a` and store that. You are guaranteed that
the references necessary to force it to WHNF are now free. Hopefully you
will store it on a data structure that requires values to have been forced
before like

    import Data.Map.Lazy

    type Accum1 = Map Char (ForcedWHNF Int)
    type Accum2 = Map Char (ForcedNF (Maybe Text))

# How to use it

You should tag your long lived data structures with the correct type as in
the previous example. It is less ergonomic than bang patterns, but you
cannot forget to put them at the call site, parse not validate.

    import Data.Map.Lazy as ML -- Spine strict

    -- No references on added leafs even though it is a lazy map.
    basicEvent
      :: ML.Map Char (ForcedWHNF Int)
      -> IO (ML.Map Char (ForcedWHNF Int))
    basicEvent map0 = do
      let val0 :: Strict (ForcedWHNF Int)
          -- val0 = strictlyWHNF (error "argument evaluated") -- would fail
          val0 = strictlyWHNF (2 + 2)
          -- CBV function, 2 + 2 reduced before val0 is bound.
          Strict val1 = val0  -- De-structure
          map1 = ML.insert 'a' val1 map0
      pure map1

    -- Same as before, but not references to values that were deleted and
    -- not forced.
    basicEventPromptDeletion
      :: Strict (ML.Map Char (ForcedNF (Maybe Int)))
      -> IO (Strict (ML.Map Char (ForcedNF (Maybe Int))))
    basicEventPromptDeletion (Strict map0) = do
      -- map0 evaluated before being bound.
      let val0 :: Strict (ForcedNF (Maybe Int))
          val0 = strictlyWHNF ((+1) <$> Just 28)
          Strict val1 = val0  -- De-structure
          map1 :: Strict (ML.Map Char (ForcedNF (Maybe Int)))
          -- forced when bound as map1
          map1 = Strict (ML.insert 'a' val1 map0)
      pure map1

# Acknowledgment

Sebastian Graf (sgraf812) should take all the credit. I was inspired by his
data-elevator package that solves a sightly different problem. He infact
pushed the proposal for unlifted data types and made the work to integrate
them to GHC.

From frederic-emmanuel.picca at synchrotron-soleil.fr  Thu Apr 13 20:36:27 2023
From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel)
Date: Thu, 13 Apr 2023 22:36:27 +0200 (CEST)
Subject: [Haskell-cafe] data familly and `sort of` alternative
Message-ID: <432026674.81831423.1681418187475.JavaMail.zimbra@synchrotron-soleil.fr>

Hello,

I have this class with two data type familly

class DataSource a where
  data DataSourcePath a :: Type
  data DataSourceAcq a :: Type

  withDataSourceP :: (Location l, MonadSafe m) => l -> DataSourcePath a -> (DataSourceAcq a -> m r) -> m r

instance DataSource Double where
  data DataSourcePath Double
    = DataSourcePath'Double (Hdf5Path Z Double)
    | DataSourcePath'Double'Const Double
    deriving (Generic, Show, FromJSON, ToJSON)

  data DataSourceAcq Double
    = DataSourceAcq'Double Dataset
    | DataSourceAcq'Double'Const Double

  withDataSourceP f (DataSourcePath'Double p) g = withHdf5PathP f p $ \ds -> g (DataSourceAcq'Double ds)
  withDataSourceP _ (DataSourcePath'Double'Const a) g = g (DataSourceAcq'Double'Const a)


the purpose of this is to let our users gives  multiple way to extract a value from different sources.
In the previous case, from an hdf5 file or from a constante value. The withHdf5PathP method can fail  and raise an Exception.
So I would like a way to provide a fallback like

(pseudo code)
withDataSourceP f (datapath `or` fallback) g = try datapath and if it fails fallback

My question is howto write this `or` method, it is not clear to me and it seems to me that this method should be usable by all the instance.

I am also not use if this is the right way to design all this.

Thanks for your help.

Frederic

From johannes.waldmann at htwk-leipzig.de  Mon Apr 17 10:50:48 2023
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 17 Apr 2023 12:50:48 +0200
Subject: [Haskell-cafe] pretty-printing with fixed indentation increase per
	sub-structure
Message-ID: <f64ff1e0-6d05-84e0-94d5-26c0768712af@htwk-leipzig.de>

Dear Cafe,

I was looking for a way to pretty-print Haskell literals
(with lists, tuples, records with named and positional notation)
like this example

( Leftist
     { tree = Branch
         { left = Branch { left = Leaf, key = 4, right = Leaf }
         , key = 3
         , right = Leaf
         }
     , refs = listToFM [ ( Ref 13, [ 0 ] ), ( Ref 17, [ ] ) ]
     }
, [ Any, Any ]
)

for each sub-structure, the indentation level
(for the following lines) should increase - by a _fixed_ amount.
in the above example: line break after "tree = Branch".
But (missing from this example), line break _before_
the list starts in "{ foo = [ 42 , ... ] ... }".

I found this impossible to do with wl-pprint
but perhaps I did not try hard enough.


Instead, I "invented" combinators `nest` and `skip`
and made this prototypical implementation
https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/blob/master/todoc/src/Text/PrettyPrint/Dent.hs 
  (it has some explanatory text at the top)
see also https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/issues/960

but certainly this cannot be a new idea.


While I do like the semantics (in the context of my application),
I don't like the performance of my implementation.
What am I doing wrong?
It's just updating indentation level and current position,
this should not take any time at all?

Of course, it would be best if I don't need the implementation at all -
if the effect could be achieved via some combinators in
established libraries (that have optimized implementation).

Any pointers appreciated.


Best regards - J.

From Graham.Hutton at nottingham.ac.uk  Mon Apr 17 12:25:07 2023
From: Graham.Hutton at nottingham.ac.uk (Graham Hutton)
Date: Mon, 17 Apr 2023 12:25:07 +0000
Subject: [Haskell-cafe] Call for Papers: Functional Software Architecture -
	FP in the Large
Message-ID: <E29D0692-0244-455F-B592-3F2A8C5B588F@nottingham.ac.uk>

Dear all,

The first workshop on "Functional Software Architecture - FP in the Large”
will be held in Seattle in Sept 2023, co-located with the ICFP conference.

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

The submission deadline 1st June 2023.

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/FUNARCH-23

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

TIMELINE:

Paper submission	1st June 2023
Author notification	28th June 2023
Camera ready copy	18th July 2023
Workshop		8th Sept 2023

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

PROGRAM CHAIRS:

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

PROGRAM COMMITTEE:

Joachim Breitner	Germany
Manuel Chakravarty	Tweag & 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 jclites at mac.com  Mon Apr 17 16:18:19 2023
From: jclites at mac.com (Jeff Clites)
Date: Mon, 17 Apr 2023 09:18:19 -0700
Subject: [Haskell-cafe] pretty-printing with fixed indentation increase
	per sub-structure
In-Reply-To: <f64ff1e0-6d05-84e0-94d5-26c0768712af@htwk-leipzig.de>
References: <f64ff1e0-6d05-84e0-94d5-26c0768712af@htwk-leipzig.de>
Message-ID: <0A727F8D-3B9C-4A8F-B9DD-52217F337459@mac.com>

Is it possible that your size pre-calculation is inadvertently inducing quadratic behavior? I remember a pretty-printer implementation that generated both a line-broken and single-line version as it went, in order to avoid quadratic behavior due to backtracking. (IIRC, it would discard one as it went, if it determined that the single-line version of a sub-structure wouldn’t fit.) I don’t remember the exact details though so I know that’s a bit vague.

I know you are caching size in order to avoid calculating it multiple times, but I’m wondering if that is still inducing double-traversal (once for size, once to generate the final text), and if that double could turn into a square.

Just a possibility.

Jeff

> On Apr 17, 2023, at 3:51 AM, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> wrote:
> 
> Dear Cafe,
> 
> I was looking for a way to pretty-print Haskell literals
> (with lists, tuples, records with named and positional notation)
> like this example
> 
> ( Leftist
>    { tree = Branch
>        { left = Branch { left = Leaf, key = 4, right = Leaf }
>        , key = 3
>        , right = Leaf
>        }
>    , refs = listToFM [ ( Ref 13, [ 0 ] ), ( Ref 17, [ ] ) ]
>    }
> , [ Any, Any ]
> )
> 
> for each sub-structure, the indentation level
> (for the following lines) should increase - by a _fixed_ amount.
> in the above example: line break after "tree = Branch".
> But (missing from this example), line break _before_
> the list starts in "{ foo = [ 42 , ... ] ... }".
> 
> I found this impossible to do with wl-pprint
> but perhaps I did not try hard enough.
> 
> 
> Instead, I "invented" combinators `nest` and `skip`
> and made this prototypical implementation
> https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/blob/master/todoc/src/Text/PrettyPrint/Dent.hs  (it has some explanatory text at the top)
> see also https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/issues/960
> 
> but certainly this cannot be a new idea.
> 
> 
> While I do like the semantics (in the context of my application),
> I don't like the performance of my implementation.
> What am I doing wrong?
> It's just updating indentation level and current position,
> this should not take any time at all?
> 
> Of course, it would be best if I don't need the implementation at all -
> if the effect could be achieved via some combinators in
> established libraries (that have optimized implementation).
> 
> Any pointers appreciated.
> 
> 
> Best regards - J.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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  Mon Apr 17 17:45:29 2023
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 17 Apr 2023 19:45:29 +0200
Subject: [Haskell-cafe] pretty-printing with fixed indentation increase
 per sub-structure
In-Reply-To: <0A727F8D-3B9C-4A8F-B9DD-52217F337459@mac.com>
References: <f64ff1e0-6d05-84e0-94d5-26c0768712af@htwk-leipzig.de>
 <0A727F8D-3B9C-4A8F-B9DD-52217F337459@mac.com>
Message-ID: <1f5af275-5058-9ea5-2ae8-574f22281073@htwk-leipzig.de>

Dear Jeff,


> Is it possible that your size pre-calculation is inadvertently inducing quadratic behavior? 

Could be, but I don't think so, this looks pretty much linear

ghci> T.length $ L.toStrict $ renderT $ vcat $ replicate 100000 "."
199999
(0.94 secs, 468,241,960 bytes)
ghci> T.length $ L.toStrict $ renderT $ vcat $ replicate 200000 "."
399999
(1.83 secs, 935,759,344 bytes)
ghci> T.length $ L.toStrict $ renderT $ vcat $ replicate 300000 "."
599999
(2.80 secs, 1,403,276,848 bytes)

But that last expression with wl-pprint-text gives

ghci> T.length $ L.toStrict $ displayT $ renderPretty 0.5 80 $ vcat $ replicate 300000 "."
599999
(0.27 secs, 426,008,296 bytes)


Oh, and now I realize - my measurement was all wrong
since ghci interprets my code (bytecode) but has the library compiled.
(the asymptotics is still OK). When I compile my code first, I do get

ghci> T.length $ L.toStrict $ renderT $ vcat $ replicate 300000 "."
599999
(0.27 secs, 459,427,808 bytes)

and that's on par. (as it should be - I am using wl-pprint-text:SimpleDoc in the end.)


So, with that out of the way,
can we go back to discussing semantics please :-)

Have you seen 'nest' (increase indentation level)
and 'skip' (to that level, possibly with line feed) before?
Is this `hang` of the Wadler-Leijen printer, somehow?

The basic idea (p. 2)
https://homepages.inf.ed.ac.uk/wadler/papers/prettier/prettier.pdf
is the same "indentation is added only at an explicit newline,
not at the beginning of a string."
That paper was written before the "dutch layout style"
(separators at start of lines) became popular?
So it is missing the examples that I am after.
The libray https://hackage.haskell.org/package/wl-pprint-text-1.2.0.2/docs/Text-PrettyPrint-Leijen-Text.html
scares me because it mentions "three new primitives" (in extension of the paper).
But it is super fast!


Best regards, J.

From anthony.d.clayden at gmail.com  Tue Apr 18 01:27:23 2023
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Tue, 18 Apr 2023 13:27:23 +1200
Subject: [Haskell-cafe] function decl syntax oddities
Message-ID: <CABU_mxgxqz7kg3fkbo1dP1sC-3RWaan8=R74xdQJzkBZuKJkCQ@mail.gmail.com>

Consider

> let f1 x     = x + 1 in f1 1             -- ==> 2 ok
> let f2 x y   = x + y in (f2 2) 3     -- ==> 5 ok
> let (f2 x) y = x + y in f2 3 4      -- ==> 7 ok
> let (f1 x)   = x + 1 in f1 4

The last gives a syntax error `Parse error in pattern: f1`. This is in line
with the Language Report, but why? Something to do with patterns?

> let ( x )    = 1      in x             -- ==> 1 ok
> let (Just x) = Just 6 in x           -- ==> 6, pattern binding for x ok
> let  Just x  = Just 7 in x           -- ==> 7 ok
> let (CP x y) = (CP 1) 2 in x    -- ==> 1.0 ok
> let (CP x) y = (CP 3) 4 in x      -- `Parse error in pattern: (CP x)`

So the parens are optional for a pattern binding. But if you use them
they must enclose the whole pattern -- unlike partially applying a data
constr on rhs.

OTOH for a function binding, on lhs there must be at least one var (or
pattern) not appearing inside outermost parens.   Why not optional parens
around a whole function binding?

It might be your lhs is declaring an operator. Then that can't be inside
parens, fair enough:

> let (Just x) +? (Just y) = (x +) y in ...   -- ok
> let ((Just x) +?) (Just y) = x + y in ...    -- rejected

Lexically we can tell a function (starts lower case) from a data constr.
Why the extra restriction with the parens?

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

From frederic-emmanuel.picca at synchrotron-soleil.fr  Tue Apr 18 13:03:18 2023
From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel)
Date: Tue, 18 Apr 2023 15:03:18 +0200 (CEST)
Subject: [Haskell-cafe] FFI: how to allocate a const char * from haskell
Message-ID: <685812082.85806255.1681822998156.JavaMail.zimbra@synchrotron-soleil.fr>

Hello, I need to call a c method which take a const char *

something like

void hkl_holder_add_axis(const struct holder *holder, const char *name);

during all the life of this object, the const char* should be accessible.

So from haskell I need to create a CString which will not be affected by the garbage collection.
The memory should be release only when the given object is freed. or when the program stop.

when I use alloca, the memory is releases and the code segfault.

I think that I could use malloc, but in that case I have a memory leak. (this is not that important in my case, since I create less than 10 of these objects).

I would like you advice in order to solve this properly.

thanks for your help.

Frederic


From vamchale at gmail.com  Tue Apr 18 13:41:23 2023
From: vamchale at gmail.com (Vanessa McHale)
Date: Tue, 18 Apr 2023 09:41:23 -0400
Subject: [Haskell-cafe] FFI: how to allocate a const char * from haskell
In-Reply-To: <685812082.85806255.1681822998156.JavaMail.zimbra@synchrotron-soleil.fr>
References: <685812082.85806255.1681822998156.JavaMail.zimbra@synchrotron-soleil.fr>
Message-ID: <E527321A-03EB-4C24-9EF5-5017CB7AA313@gmail.com>

If I had to guess, what is happening is that the structure holder uses name without copying it under the hood, so that name is freed but some later method depends on that field being available.

In this case you probably want malloc, and you can explicitly free name after freeing holder.

> On Apr 18, 2023, at 9:03 AM, PICCA Frederic-Emmanuel <frederic-emmanuel.picca at synchrotron-soleil.fr> wrote:
> 
> Hello, I need to call a c method which take a const char *
> 
> something like
> 
> void hkl_holder_add_axis(const struct holder *holder, const char *name);
> 
> during all the life of this object, the const char* should be accessible.
> 
> So from haskell I need to create a CString which will not be affected by the garbage collection.
> The memory should be release only when the given object is freed. or when the program stop.
> 
> when I use alloca, the memory is releases and the code segfault.
> 
> I think that I could use malloc, but in that case I have a memory leak. (this is not that important in my case, since I create less than 10 of these objects).
> 
> I would like you advice in order to solve this properly.
> 
> thanks for your help.
> 
> Frederic
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 frederic-emmanuel.picca at synchrotron-soleil.fr  Tue Apr 18 13:44:43 2023
From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel)
Date: Tue, 18 Apr 2023 15:44:43 +0200 (CEST)
Subject: [Haskell-cafe] FFI: how to allocate a const char * from haskell
In-Reply-To: <E527321A-03EB-4C24-9EF5-5017CB7AA313@gmail.com>
References: <685812082.85806255.1681822998156.JavaMail.zimbra@synchrotron-soleil.fr>
 <E527321A-03EB-4C24-9EF5-5017CB7AA313@gmail.com>
Message-ID: <1607893601.85883154.1681825483232.JavaMail.zimbra@synchrotron-soleil.fr>

> If I had to guess, what is happening is that the structure holder uses name
> without copying it under the hood, so that name is freed but some later method
> depends on that field being available.

you are right

I just red the doc of mallocByte and it seems that under the hood it use the c malloc method.
So at first I will check that the program does not segfault with a malloced array or char

thanks

Fred

From zubin at well-typed.com  Tue Apr 18 13:56:48 2023
From: zubin at well-typed.com (Zubin Duggal)
Date: Tue, 18 Apr 2023 19:26:48 +0530
Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 9.4.5 released
Message-ID: <uahhxtswzjuqsmdlgizx6n4xhrap5zwumlx32jg3g3ukp4jpmk@ern5qr56pjnx>

The GHC developers are happy to announce the availability of GHC 9.4.5. Binary
distributions, source distributions, and documentation are available at
[downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.5).

Download Page: https://www.haskell.org/ghc/download_ghc_9.4.5.html
Blog Post: https://www.haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html

This release is primarily a bugfix release addressing a few issues
found in 9.4.4. These include:

  * Fixes for a number of bug fixes in the simplifier (#22623, #22718, #22913, 22695,
    #23184, #22998, #22662, #22725).
  * Many bug fixes to the non-moving and parallel GCs (#22264, #22327, #22926,
    #22927, #22929, #22930, #17574, #21840, #22528)
  * A fix a bug with the alignment of RTS data structures that could result in
    segfaults when compiled with high optimisation settings on certain platforms
    (#22975 , #22965).
  * Bumping `gmp-tarballs` to a version which doesn't use the reserved `x18`
    register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618
    (#22497, #22789).
  * A number of improvements to recompilation avoidance with multiple home units
    (#22675, #22677, #22669, #22678, #22679, #22680)
  * Fixes for regressions in the typechecker and constraint solver (#22647,
    #23134, #22516, #22743)
  * Easier installation of binary distribution on MacOS platforms by changing the
    installation Makefile to remove the quarantine attribute when installing.
  * ... and many more. See the [release notes] for a full accounting.

As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and
other anonymous contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years. Finally,
this release would not have been possible without the hundreds of open-source
contributors whose work comprise this release.

As always, do give this release a try and open a [ticket][] if you see
anything amiss.

Happy compiling,

- Zubin

[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
[release notes]: https://downloads.haskell.org/~ghc/9.4.5/docs/html/users_guide/9.4.5-notes.html
-------------- 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/20230418/da64d250/attachment.sig>

From lemming at henning-thielemann.de  Tue Apr 18 16:39:39 2023
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 18 Apr 2023 18:39:39 +0200 (CEST)
Subject: [Haskell-cafe] FFI: how to allocate a const char * from haskell
In-Reply-To: <685812082.85806255.1681822998156.JavaMail.zimbra@synchrotron-soleil.fr>
References: <685812082.85806255.1681822998156.JavaMail.zimbra@synchrotron-soleil.fr>
Message-ID: <a2248a71-dfc6-1781-ca29-819c9f67d523@henning-thielemann.de>


On Tue, 18 Apr 2023, PICCA Frederic-Emmanuel wrote:

> Hello, I need to call a c method which take a const char *
>
> something like
>
> void hkl_holder_add_axis(const struct holder *holder, const char *name);
>
> during all the life of this object, the const char* should be accessible.
>
> So from haskell I need to create a CString which will not be affected by the garbage collection.
> The memory should be release only when the given object is freed. or when the program stop.
>
> when I use alloca, the memory is releases and the code segfault.
>
> I think that I could use malloc, but in that case I have a memory leak. (this is not that important in my case, since I create less than 10 of these objects).

You can use allocaBytes, but have to make sure, that the memory lives as 
long as it is needed. Alternatively you can 
Foreign.ForeignPtr.mallocForeignPtrBytes. But then, you would access the 
pointer inside with withForeignPtr or do a touchForeignPtr after the last 
use of your pointer.

From albert+haskell at zeitkraut.de  Tue Apr 18 16:49:04 2023
From: albert+haskell at zeitkraut.de (Albert Krewinkel)
Date: Tue, 18 Apr 2023 18:49:04 +0200
Subject: [Haskell-cafe] FFI: how to allocate a const char * from haskell
In-Reply-To: <685812082.85806255.1681822998156.JavaMail.zimbra@synchrotron-soleil.fr>
References: <685812082.85806255.1681822998156.JavaMail.zimbra@synchrotron-soleil.fr>
Message-ID: <87a5z5i14i.fsf@zeitkraut.de>


PICCA Frederic-Emmanuel <frederic-emmanuel.picca at synchrotron-soleil.fr> writes:

> Hello, I need to call a c method which take a const char *
>
> something like
>
> void hkl_holder_add_axis(const struct holder *holder, const char *name);
>
> during all the life of this object, the const char* should be accessible.
>
> So from haskell I need to create a CString which will not be affected
> by the garbage collection. The memory should be release only when the
> given object is freed. or when the program stop.
>
> when I use alloca, the memory is releases and the code segfault.
>
> I think that I could use malloc, but in that case I have a memory
> leak. (this is not that important in my case, since I create less than
> 10 of these objects).

Maybe a ForeignPtr can help here: it allows to attach a finalizer, which
you can use to free the CString once the object is GCed in Haskell.

https://hackage.haskell.org/package/base-4.18.0.0/docs/Foreign-ForeignPtr.html


-- 
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124

From adrian at openwork.nz  Tue Apr 18 21:35:48 2023
From: adrian at openwork.nz (Adrian Cochrane)
Date: Wed, 19 Apr 2023 09:35:48 +1200
Subject: [Haskell-cafe] Call for Papers: Functional Software
In-Reply-To: <mailman.3.1681819201.1789.haskell-cafe@haskell.org>
References: <mailman.3.1681819201.1789.haskell-cafe@haskell.org>
Message-ID: <fad57f6f-7fa1-49fb-b407-70867869f6f5@app.fastmail.com>

Would you an experience report regarding building my own (no-JS) browserengine be appreciated?

On Wed, Apr 19, 2023, at 12:00 AM, haskell-cafe-request at haskell.org wrote:
> Dear all,
> 
> The first workshop on "Functional Software Architecture - FP in the Large”
> will be held in Seattle in Sept 2023, co-located with the ICFP conference.
> 
> Please share, and submit your best papers, experience reports, and
> architectural pearls on large-scale functional programming!
> 
> The submission deadline 1st June 2023.
> 
> 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/FUNARCH-23
> 
> ======================================================================
> 
> TIMELINE:
> 
> Paper submission 1st June 2023
> Author notification 28th June 2023
> Camera ready copy 18th July 2023
> Workshop 8th Sept 2023
> 
> 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 papers 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.
> 
> PROGRAM CHAIRS:
> 
> Mike Sperber Active Group, Germany
> Graham Hutton University of Nottingham, UK
> 
> PROGRAM COMMITTEE:
> 
> Joachim Breitner Germany
> Manuel Chakravarty Tweag & 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.
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230419/8cc16233/attachment.html>

From alois.cochard at gmail.com  Wed Apr 19 02:51:14 2023
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Wed, 19 Apr 2023 04:51:14 +0200
Subject: [Haskell-cafe] Call for Papers: Functional Software
In-Reply-To: <fad57f6f-7fa1-49fb-b407-70867869f6f5@app.fastmail.com>
References: <mailman.3.1681819201.1789.haskell-cafe@haskell.org>
 <fad57f6f-7fa1-49fb-b407-70867869f6f5@app.fastmail.com>
Message-ID: <CAJHA+woGA4JuqAXXymCkc=WGP6yF+5z5Px+q0DC1osD7pATiTQ@mail.gmail.com>

Yeah, sure.

That would

On Tue, 18 Apr 2023 at 23:37, Adrian Cochrane <adrian at openwork.nz> wrote:

> Would you an experience report regarding building my own (no-JS)
> browserengine be appreciated?
>
> On Wed, Apr 19, 2023, at 12:00 AM, haskell-cafe-request at haskell.org wrote:
>
> Dear all,
>
> The first workshop on "Functional Software Architecture - FP in the Large”
> will be held in Seattle in Sept 2023, co-located with the ICFP conference.
>
> Please share, and submit your best papers, experience reports, and
> architectural pearls on large-scale functional programming!
>
> The submission deadline 1st June 2023.
>
> 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/FUNARCH-23
>
> ======================================================================
>
> TIMELINE:
>
> Paper submission 1st June 2023
> Author notification 28th June 2023
> Camera ready copy 18th July 2023
> Workshop 8th Sept 2023
>
> 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 papers 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.
>
> PROGRAM CHAIRS:
>
> Mike Sperber Active Group, Germany
> Graham Hutton University of Nottingham, UK
>
> PROGRAM COMMITTEE:
>
> Joachim Breitner Germany
> Manuel Chakravarty Tweag & 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.
>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>


-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230419/68a13f73/attachment.html>

From ida.bzowska at gmail.com  Wed Apr 19 15:36:04 2023
From: ida.bzowska at gmail.com (Ida Bzowska)
Date: Wed, 19 Apr 2023 17:36:04 +0200
Subject: [Haskell-cafe] [Summer of Haskell 2023] Submit your proposal by
	tomorrow!
Message-ID: <CAHjTkBj3UDd_uxs0S=mV7FXmbihCxWvxAySQgBxmxR10RXyQew@mail.gmail.com>

Hi Everyone,

This is the last call to those wanting to participate in the Summer of
Haskell program - project proposals are due by April 20, 2023 (tomorrow!).

Details, including application instructions and a list of suggested
projects and volunteer mentors, can be found at: summer.haskell.org

Additionally, if your company or organization wants to support new
open-source contributors, please email us at summer at haskell.org. Funding a
stipend or two can have a significant positive impact on the Haskell
ecosystem!

Regards,
Ida Bzowska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230419/4371800d/attachment.html>

From andrei.h.popescu at gmail.com  Thu Apr 20 11:26:03 2023
From: andrei.h.popescu at gmail.com (Andrei Popescu)
Date: Thu, 20 Apr 2023 12:26:03 +0100
Subject: [Haskell-cafe] 3-year Research Associate or Research Assistant
 position in formal verification,
 using a proof assistant (preferably Isabelle),
 at the University of Sheffield
Message-ID: <CAACfPHp1uv--SfQQPHHvYMYk-PpAP3x7yzQz4h+Y-s5XQHwzcw@mail.gmail.com>

Dear colleagues,

We have an opening for a 3-year position of either research associate
or research assistant at the University of Sheffield, UK. It is on a
project called "Safe and secure concurrent programming for advanced
hardware architectures" and involves modelling and verification using
a proof assistant, preferably Isabelle. Please share this opportunity
with anyone you think might be interested. The closing date for
applications is

                     *** 23rd May 2023 ***

More details can be found here:

https://www.jobs.ac.uk/job/CYZ645/research-assistant-or-research-associate-in-formal-modelling-and-verification

and here:

https://jobs.shef.ac.uk/sap/bc/webdynpro/sap/hrrcf_a_posting_apply?PARAM=cG9zdF9pbnN0X2d1aWQ9NjQzNTIyNEU0RDhBMUFDM0UxMDAwMDAwQUMxRTg4NzgmY2FuZF90eXBlPUVYVA%3d%3d&sap-client=400&sap-language=EN&sap-accessibility=X&sap-ep-themeroot=%2fSAP%2fPUBLIC%2fBC%2fUR%2fuos#

Best wishes,
Andrei Popescu
https://www.andreipopescu.uk/

From ivanperezdominguez at gmail.com  Fri Apr 21 14:48:49 2023
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Fri, 21 Apr 2023 07:48:49 -0700
Subject: [Haskell-cafe] [ANN] dunai-0.11.0 and bearriver-0.14.2
Message-ID: <CACZKWELgGEaHGu17_Scss6TC9pKJ57vyDVSoPKt0WvS1a1rf-g@mail.gmail.com>

Dear all,

I'm really excited to announce the release of Dunai 0.11.0 and Bearriver
0.14.2!

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 release has addressed mainly styling issues. All library code now
conforms to the main rules of the style guide we follow (which is
publicly documented). We've also addressed other minor maintenance
issues, like removal of unused code and updates to the README. In
total, there have been more than 100 commits.

Special thanks go to Miao ZhiCheng (@hellwolf on github) for a generous
donation towards this release, and to Johannes Riecken
(@johannes-riecken on github) for a regular contribution to support the
dunai and Yampa projects.

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

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

*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 Jun 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:

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

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/20230421/ffd15485/attachment.html>

From qdunkan at gmail.com  Sun Apr 23 01:51:52 2023
From: qdunkan at gmail.com (Evan Laforge)
Date: Sat, 22 Apr 2023 18:51:52 -0700
Subject: [Haskell-cafe] pretty-printing with fixed indentation increase
 per sub-structure
In-Reply-To: <f64ff1e0-6d05-84e0-94d5-26c0768712af@htwk-leipzig.de>
References: <f64ff1e0-6d05-84e0-94d5-26c0768712af@htwk-leipzig.de>
Message-ID: <CACbaDy6SuRZVmTVmgiREOb0ZJadYRQ5GDfzBYdn5n_JJRQp+QA@mail.gmail.com>

Sorry I'm late to the party.  I wanted something like that a long time
ago, and I thought "this should be easy" so I wrote a "simple" library
for it:

https://github.com/elaforge/karya/blob/work/Util/Format.hs
https://github.com/elaforge/karya/blob/work/Util/Pretty.hs

The reason for the scare quotes is that it turned out to be much
harder and more finicky than I thought.  This implementation still has
at least one formatting bug which I did track down at some point, but
I believe it was a missing logical distinction which would be hard to
fix.  But in fact I've been using it for about 9 years and it's worked
well enough.  I haven't done any performance analysis, but I've never
felt the need for it, and I've printed some pretty large things.

So, I don't know if it's hard because it's actually hard, or because I
didn't do a great design, or because I wasn't motivated to put further
work into it after it got to good enough.

On Mon, Apr 17, 2023 at 3:51 AM Johannes Waldmann
<johannes.waldmann at htwk-leipzig.de> wrote:
>
> Dear Cafe,
>
> I was looking for a way to pretty-print Haskell literals
> (with lists, tuples, records with named and positional notation)
> like this example
>
> ( Leftist
>      { tree = Branch
>          { left = Branch { left = Leaf, key = 4, right = Leaf }
>          , key = 3
>          , right = Leaf
>          }
>      , refs = listToFM [ ( Ref 13, [ 0 ] ), ( Ref 17, [ ] ) ]
>      }
> , [ Any, Any ]
> )
>
> for each sub-structure, the indentation level
> (for the following lines) should increase - by a _fixed_ amount.
> in the above example: line break after "tree = Branch".
> But (missing from this example), line break _before_
> the list starts in "{ foo = [ 42 , ... ] ... }".
>
> I found this impossible to do with wl-pprint
> but perhaps I did not try hard enough.
>
>
> Instead, I "invented" combinators `nest` and `skip`
> and made this prototypical implementation
> https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/blob/master/todoc/src/Text/PrettyPrint/Dent.hs
>   (it has some explanatory text at the top)
> see also https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/issues/960
>
> but certainly this cannot be a new idea.
>
>
> While I do like the semantics (in the context of my application),
> I don't like the performance of my implementation.
> What am I doing wrong?
> It's just updating indentation level and current position,
> this should not take any time at all?
>
> Of course, it would be best if I don't need the implementation at all -
> if the effect could be achieved via some combinators in
> established libraries (that have optimized implementation).
>
> Any pointers appreciated.
>
>
> Best regards - J.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 leah at vuxu.org  Mon Apr 24 14:33:51 2023
From: leah at vuxu.org (Leah Neukirchen)
Date: Mon, 24 Apr 2023 16:33:51 +0200
Subject: [Haskell-cafe] Munich Haskell Meeting, 2023-04-27 @ 19:30
Message-ID: <87cz3te4ds.fsf@vuxu.org>

Dear all,

This week, our monthly Munich Haskell Meeting will take place again on
Thursday, April 27 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 nuudel
anonymously or pseudonymously.

https://nuudel.digitalcourage.de/potA6hxva6zSA1zG

Everybody is welcome!

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

From hjgtuyl at chello.nl  Tue Apr 25 17:29:37 2023
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Tue, 25 Apr 2023 19:29:37 +0200
Subject: [Haskell-cafe] Front page Haskell wiki site (
	https://wiki.haskell.org/Haskell )
Message-ID: <op.13yv7sjapz0j5l@alquantor>


L.S.,

The front page of the Haskell wiki site has changed, is a cascading style  
sheet missing?

Regards,
Henk-Jan van Tuyl


-- 
Message from Stanford University:

Folding at home

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

--
http://Van.Tuyl.eu
https://HenkJanvanTuyl.werkaandemuur.nl/
https://sfeeraandemuur.nl/winkel/nekutimo/
https://github.com/HJvT
https://web.archive.org/web/20201109033750/members.chello.nl/hjgtuyl/tourdemonad.html
https://web.archive.org/web/20201111212601/http://members.chello.nl/hjgtuyl/computing/EWD1056.html
Haskell programming
--

From haskellcafe at dandart.co.uk  Tue Apr 25 17:43:38 2023
From: haskellcafe at dandart.co.uk (Dan Dart)
Date: Tue, 25 Apr 2023 18:43:38 +0100
Subject: [Haskell-cafe] Front page Haskell wiki site (
 https://wiki.haskell.org/Haskell )
In-Reply-To: <op.13yv7sjapz0j5l@alquantor>
References: <op.13yv7sjapz0j5l@alquantor>
Message-ID: <CADNJRYHVegm6TWyarY-7mdOAYAH8LGuxUVgj=Rj-r0F41g+=QQ@mail.gmail.com>

> The front page of the Haskell wiki site has changed, is a cascading style sheet missing?

Seems okay to me from here - have you got some plugin or just didn't
load everything due to flaky internet perhaps?

The network tab gave everything a 200 for me...

From allbery.b at gmail.com  Tue Apr 25 17:45:11 2023
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 25 Apr 2023 13:45:11 -0400
Subject: [Haskell-cafe] Front page Haskell wiki site (
 https://wiki.haskell.org/Haskell )
In-Reply-To: <CADNJRYHVegm6TWyarY-7mdOAYAH8LGuxUVgj=Rj-r0F41g+=QQ@mail.gmail.com>
References: <op.13yv7sjapz0j5l@alquantor>
 <CADNJRYHVegm6TWyarY-7mdOAYAH8LGuxUVgj=Rj-r0F41g+=QQ@mail.gmail.com>
Message-ID: <CAKFCL4WYLaKFXBd0Yw_M030YUxAkd8dMpvfsQVMrfrJSE7HMeA@mail.gmail.com>

The wiki was just recently upgraded; it may look different because of that.

On Tue, Apr 25, 2023 at 1:44 PM Dan Dart <haskellcafe at dandart.co.uk> wrote:
>
> > The front page of the Haskell wiki site has changed, is a cascading style sheet missing?
>
> Seems okay to me from here - have you got some plugin or just didn't
> load everything due to flaky internet perhaps?
>
> The network tab gave everything a 200 for me...
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 a.pelenitsyn at gmail.com  Tue Apr 25 17:58:01 2023
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Tue, 25 Apr 2023 13:58:01 -0400
Subject: [Haskell-cafe] Front page Haskell wiki site (
 https://wiki.haskell.org/Haskell )
In-Reply-To: <CAKFCL4WYLaKFXBd0Yw_M030YUxAkd8dMpvfsQVMrfrJSE7HMeA@mail.gmail.com>
References: <op.13yv7sjapz0j5l@alquantor>
 <CADNJRYHVegm6TWyarY-7mdOAYAH8LGuxUVgj=Rj-r0F41g+=QQ@mail.gmail.com>
 <CAKFCL4WYLaKFXBd0Yw_M030YUxAkd8dMpvfsQVMrfrJSE7HMeA@mail.gmail.com>
Message-ID: <CAPKAvQWri7-tiCA7254rPCV7kykJ_jJGp6bttyCAmA10Hepp2A@mail.gmail.com>

Is there a publicly-accessible place (a repo, mailing-list, or, God forbid,
Slack) where I can track
what's happening to the wiki?

https://wiki.haskell.org/HaskellWiki:About says "in October 2006, it [the
wiki] retired from active service."

--
Best, Artem

On Tue, 25 Apr 2023 at 13:45, Brandon Allbery <allbery.b at gmail.com> wrote:

> The wiki was just recently upgraded; it may look different because of that.
>
> On Tue, Apr 25, 2023 at 1:44 PM Dan Dart <haskellcafe at dandart.co.uk>
> wrote:
> >
> > > The front page of the Haskell wiki site has changed, is a cascading
> style sheet missing?
> >
> > Seems okay to me from here - have you got some plugin or just didn't
> > load everything due to flaky internet perhaps?
> >
> > The network tab gave everything a 200 for me...
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230425/3c6ca746/attachment.html>

From allbery.b at gmail.com  Tue Apr 25 17:59:59 2023
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 25 Apr 2023 13:59:59 -0400
Subject: [Haskell-cafe] Front page Haskell wiki site (
 https://wiki.haskell.org/Haskell )
In-Reply-To: <CAPKAvQWri7-tiCA7254rPCV7kykJ_jJGp6bttyCAmA10Hepp2A@mail.gmail.com>
References: <op.13yv7sjapz0j5l@alquantor>
 <CADNJRYHVegm6TWyarY-7mdOAYAH8LGuxUVgj=Rj-r0F41g+=QQ@mail.gmail.com>
 <CAKFCL4WYLaKFXBd0Yw_M030YUxAkd8dMpvfsQVMrfrJSE7HMeA@mail.gmail.com>
 <CAPKAvQWri7-tiCA7254rPCV7kykJ_jJGp6bttyCAmA10Hepp2A@mail.gmail.com>
Message-ID: <CAKFCL4WNdpRdXocC1O3FH3-C8p+O-xm6dZU7Nu89kEM9-Mo6_w@mail.gmail.com>

I think that was the old Haskell wiki, whose contents were copied over
unchanged in a subtree.
The only place I've seen discussion of wiki changes so far is
#haskell-infrastructure.

On Tue, Apr 25, 2023 at 1:58 PM Artem Pelenitsyn <a.pelenitsyn at gmail.com> wrote:
>
> Is there a publicly-accessible place (a repo, mailing-list, or, God forbid, Slack) where I can track
> what's happening to the wiki?
>
> https://wiki.haskell.org/HaskellWiki:About says "in October 2006, it [the wiki] retired from active service."
>
> --
> Best, Artem
>
> On Tue, 25 Apr 2023 at 13:45, Brandon Allbery <allbery.b at gmail.com> wrote:
>>
>> The wiki was just recently upgraded; it may look different because of that.
>>
>> On Tue, Apr 25, 2023 at 1:44 PM Dan Dart <haskellcafe at dandart.co.uk> wrote:
>> >
>> > > The front page of the Haskell wiki site has changed, is a cascading style sheet missing?
>> >
>> > Seems okay to me from here - have you got some plugin or just didn't
>> > load everything due to flaky internet perhaps?
>> >
>> > The network tab gave everything a 200 for me...
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>> --
>> brandon s allbery kf8nh
>> allbery.b at gmail.com
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.



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

From jclites at mac.com  Tue Apr 25 18:41:20 2023
From: jclites at mac.com (Jeff Clites)
Date: Tue, 25 Apr 2023 11:41:20 -0700
Subject: [Haskell-cafe] Front page Haskell wiki site (
	https://wiki.haskell.org/Haskell )
In-Reply-To: <CAPKAvQWri7-tiCA7254rPCV7kykJ_jJGp6bttyCAmA10Hepp2A@mail.gmail.com>
References: <CAPKAvQWri7-tiCA7254rPCV7kykJ_jJGp6bttyCAmA10Hepp2A@mail.gmail.com>
Message-ID: <9C896658-BDF8-4B23-91F7-ECEA6BC8C778@mac.com>

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

From scooter.phd at gmail.com  Tue Apr 25 21:32:24 2023
From: scooter.phd at gmail.com (Scott Michel)
Date: Tue, 25 Apr 2023 14:32:24 -0700
Subject: [Haskell-cafe] "Hey! Monad! Leave my Pure alone!"
Message-ID: <CACwhxctKNCQBsvLi3fQLJu-09WTew7mbs7kLN3tg5GiWPxFtgg@mail.gmail.com>

For a number of years, I've been hacking on a Z80 processor simulator, on
and off. It's generally pure code that resembles and uses State, et. al.
The design issue I've run into is adding devices to the memory system,
unsurprisingly typed as MemorySystem. Devices like to do I/O, which
potentially "pollutes" a design with Monads. So... I'm soliciting
suggestions that allow me to isolate Monadic code in the middle of pure
code (which might be Quixotic, but I'll accept that risk.)

MemorySystem uses interval maps containing memory regions, and a memory
region can be a RAMRegion, ROMRegion or DeviceRegion. The abbreviated data
declarations are:

type MemRegionMap addrType wordType = IM.IntervalMap addrType (MemoryRegion
addrType wordType)

data MemorySystem addrType wordType where
  MSys ::
    { _regions    :: MemRegionMap addrType wordType
    } -> MemorySystem addrType wordType

data MemoryRegion addrType wordType where
  EmptyRegion :: MemoryRegion addrType wordType
  RAMRegion :: {- ... -}
  ROMRegion :: {- ... -}
  DevRegion :: {- ... -}

RAMRegion-s and ROMRegion-s are unboxed vector containers, which makes
reading and writing to them pure State code, i.e., the last two function
arguments to the reading function are "MemorySystem ... -> (Vector
wordType, MemorySystem ...)", viz:

type MemReadN addrType wordType = (Vector wordType, MemorySystem addrType
wordType)
mReadN :: addrType
       -- ^ Starting address
       -> Int
       -- ^ Number of words to read
       -> MemorySystem addrType wordType
       -- ^ The memory system from which to read
       -> MemReadN addrType wordType

Supporting DevRegion-s gets more complicated, because I/O is involved (we
like consoles on our machines, yes, we do.) I'd like to keep the reader
signature without unnecessarily injecting a Monad or Monad Transformer into
MemoryRegion and MemorySystem, thereby keeping the Monad or transformer
isolated in DevRegion. For example, an internal device reader  function
would have a signature similar to "... -> Device m devType -> (Vector
wordType, m devType)" instead of "... -> Device m devType -> m (Vector
WordType, devType)", where "m" is the Monad or transformer.

I know, it's hard to jailbreak things out of a Monad, which may be
answering my own question. However, it seems to me that this kind of
problem occurs in real world Haskell, and I haven't encountered the real
world solution.

Ideas?


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

From godzbanebane at gmail.com  Wed Apr 26 06:49:00 2023
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Wed, 26 Apr 2023 09:49:00 +0300
Subject: [Haskell-cafe] "Hey! Monad! Leave my Pure alone!"
In-Reply-To: <CACwhxctKNCQBsvLi3fQLJu-09WTew7mbs7kLN3tg5GiWPxFtgg@mail.gmail.com>
References: <CACwhxctKNCQBsvLi3fQLJu-09WTew7mbs7kLN3tg5GiWPxFtgg@mail.gmail.com>
Message-ID: <15ce9e32-d954-7356-cc9b-fffbef080630@gmail.com>

Hey Scott

How should the result of `Vector wordType` in the "pure" variant of the 
function you want to implement be produced? Is that expected to come 
from user input?

Cheers,
Georgi

On 4/26/23 00:32, Scott Michel wrote:
> For a number of years, I've been hacking on a Z80 processor simulator, 
> on and off. It's generally pure code that resembles and uses State, 
> et. al. The design issue I've run into is adding devices to the memory 
> system, unsurprisingly typed as MemorySystem. Devices like to do I/O, 
> which potentially "pollutes" a design with Monads. So... I'm 
> soliciting suggestions that allow me to isolate Monadic code in the 
> middle of pure code (which might be Quixotic, but I'll accept that risk.)
>
> MemorySystem uses interval maps containing memory regions, and a 
> memory region can be a RAMRegion, ROMRegion or DeviceRegion. The 
> abbreviated data declarations are:
>
> type MemRegionMap addrType wordType = IM.IntervalMap addrType 
> (MemoryRegion addrType wordType)
> data MemorySystem addrType wordType where
>   MSys ::
>     { _regions    :: MemRegionMap addrType wordType
>   } -> MemorySystem addrType wordType
> data MemoryRegion addrType wordType where
>   EmptyRegion :: MemoryRegion addrType wordType
>   RAMRegion :: {- ... -}
>   ROMRegion :: {- ... -}
>   DevRegion :: {- ... -}
> RAMRegion-s and ROMRegion-s are unboxed vector containers, which makes 
> reading and writing to them pure State code, i.e., the last two 
> function arguments to the reading function are "MemorySystem ... -> 
> (Vector wordType, MemorySystem ...)", viz:
> type MemReadN addrType wordType = (Vector wordType, MemorySystem 
> addrType wordType)
> mReadN :: addrType
>        -- ^ Starting address
>        -> Int
>        -- ^ Number of words to read
>        -> MemorySystem addrType wordType
>        -- ^ The memory system from which to read
>        -> MemReadN addrType wordType
> Supporting DevRegion-s gets more complicated, because I/O is involved 
> (we like consoles on our machines, yes, we do.) I'd like to keep the 
> reader signature without unnecessarily injecting a Monad or Monad 
> Transformer into MemoryRegion and MemorySystem, thereby keeping the 
> Monad or transformer isolated in DevRegion. For example, an internal 
> device reader  function would have a signature similar to "... -> 
> Device m devType -> (Vector wordType, m devType)" instead of "... -> 
> Device m devType -> m (Vector WordType, devType)", where "m" is the 
> Monad or transformer.
> I know, it's hard to jailbreak things out of a Monad, which may be 
> answering my own question. However, it seems to me that this kind of 
> problem occurs in real world Haskell, and I haven't encountered the 
> real world solution.
> Ideas?
> -scooter
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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/20230426/fc0ddb84/attachment.html>