From 8hjkl8 at gmail.com Sun Aug 1 12:49:54 2021
From: 8hjkl8 at gmail.com (Kim Chaegon)
Date: Sun, 1 Aug 2021 21:49:54 +0900
Subject: [Haskell-cafe] I want to read documents about haskell.
Message-ID:
I want read documents about haskell, pure functional language. Rgank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fa-ml at ariis.it Sun Aug 1 13:13:03 2021
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 1 Aug 2021 15:13:03 +0200
Subject: [Haskell-cafe] I want to read documents about haskell.
In-Reply-To:
References:
Message-ID: <20210801131303.GA32240@extensa>
Hello Kim,
Il 01 agosto 2021 alle 21:49 Kim Chaegon ha scritto:
> I want read documents about haskell, pure functional language. Rgank you!
Plenty of docs on https://www.haskell.org/documentation/ , see
if you find something you like!
—F
From spam at scientician.net Sun Aug 1 21:07:13 2021
From: spam at scientician.net (Bardur Arantsson)
Date: Sun, 1 Aug 2021 23:07:13 +0200
Subject: [Haskell-cafe] Sets, typeclasses and functional dependencies
In-Reply-To: <5982b2a2-c5d1-b2ef-8b32-d9d691c1fb75@henning-thielemann.de>
References:
<5982b2a2-c5d1-b2ef-8b32-d9d691c1fb75@henning-thielemann.de>
Message-ID:
On 31/07/2021 11.14, Henning Thielemann wrote:
>
> A more modern approach would use type functions:
>
> class Setish set where
> type Element set
> empty :: set
> singleton :: Element set -> set
>
Just to add: This would be an "extensional" set, i.e one specified
explicitly by its elements. But there are also "intensional" sets which
are defined by some sort of mathematical property that holds for its
elements.
Naturally, the operations that make sense for either of those is *very*
different.
From borgauf at gmail.com Sun Aug 1 22:12:25 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Sun, 1 Aug 2021 17:12:25 -0500
Subject: [Haskell-cafe] Explanation of Data.Set, please
Message-ID:
I'm looking at this
code and wondering, first, about the strategy behind the data type Set
itself
data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip
It says it's a "balanced tree." I found this
talking about
maybe why that is. Will read. But in the meantime, any explanation in plain
English as to why we're doing it as a tree and not some other structure
would be helpful. And why are we bringing Size along, and in general, why
all the strictness !'s? All this might have something to do with why a
balanced tree is better than quick-and-dirty list representation like I see
in beginner tutorials? Next, is this ZFC? I've seen treatments that
supposedly are ZFC-friendly. Finally, I've taken a preliminary look at
Agda, and right from the start there's Set, and no doubt an entirely
alternative, category universe approach to the concept of set theory. Any
contrast and compare between Haskell and Agda's set notions would be
appreciated. Haskell seems to dance in and out of Category Theory, while
Agda seems pretty much just CT....
--
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From migmit at gmail.com Sun Aug 1 22:19:07 2021
From: migmit at gmail.com (MigMit)
Date: Mon, 2 Aug 2021 00:19:07 +0200
Subject: [Haskell-cafe] Explanation of Data.Set, please
In-Reply-To:
References:
Message-ID:
What is called "Set" in Prelude is not "set" in a set-theoretic meaning. It is a finite set. Not sure what you mean by "ZFC-friendly", since it is not a "concept of set theory" at all.
It is represented that way for efficiency; balanced trees generally guarantee O(log n) performance, while a list would give you O(n).
> On 2 Aug 2021, at 00:12, Galaxy Being wrote:
>
> I'm looking at this code and wondering, first, about the strategy behind the data type Set itself
>
> data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip
>
> It says it's a "balanced tree." I found this talking about maybe why that is. Will read. But in the meantime, any explanation in plain English as to why we're doing it as a tree and not some other structure would be helpful. And why are we bringing Size along, and in general, why all the strictness !'s? All this might have something to do with why a balanced tree is better than quick-and-dirty list representation like I see in beginner tutorials? Next, is this ZFC? I've seen treatments that supposedly are ZFC-friendly. Finally, I've taken a preliminary look at Agda, and right from the start there's Set, and no doubt an entirely alternative, category universe approach to the concept of set theory. Any contrast and compare between Haskell and Agda's set notions would be appreciated. Haskell seems to dance in and out of Category Theory, while Agda seems pretty much just CT....
>
> --
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf 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.
From ruben.astud at gmail.com Mon Aug 2 01:20:09 2021
From: ruben.astud at gmail.com (Ruben Astudillo)
Date: Sun, 1 Aug 2021 21:20:09 -0400
Subject: [Haskell-cafe] Explanation of Data.Set, please
In-Reply-To:
References:
Message-ID:
You are asking too much from Data.Set. This module is capturing the notion
of a *finite* collection of elements. It deals with a data structure view of
set, where you want to use have good performance for the following operations.
- lookup
- insertion (no duplicate elements)
- removal
- cardinality
- union / intersection
The needs of the previous function guided the bang patterns/UNPACK on the
definition of the data structure and the use of a balanced tree.
--
-- Rubén. pgp: 4EE9 28F7 932E F4AD
On 01-08-21 18:12, Galaxy Being wrote:
> I'm looking at this
>
> code and wondering, first, about the strategy behind the data type Set
> itself
>
> data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip
>
> It says it's a "balanced tree." I found this
> talking about
> maybe why that is. Will read. But in the meantime, any explanation in plain
> English as to why we're doing it as a tree and not some other structure
> would be helpful. And why are we bringing Size along, and in general, why
> all the strictness !'s? All this might have something to do with why a
> balanced tree is better than quick-and-dirty list representation like I see
> in beginner tutorials? Next, is this ZFC? I've seen treatments that
> supposedly are ZFC-friendly. Finally, I've taken a preliminary look at
> Agda, and right from the start there's Set, and no doubt an entirely
> alternative, category universe approach to the concept of set theory. Any
> contrast and compare between Haskell and Agda's set notions would be
> appreciated. Haskell seems to dance in and out of Category Theory, while
> Agda seems pretty much just CT....
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
From raoknz at gmail.com Mon Aug 2 02:29:11 2021
From: raoknz at gmail.com (Richard O'Keefe)
Date: Mon, 2 Aug 2021 14:29:11 +1200
Subject: [Haskell-cafe] Sets, typeclasses and functional dependencies
In-Reply-To:
References:
<5982b2a2-c5d1-b2ef-8b32-d9d691c1fb75@henning-thielemann.de>
Message-ID:
The thing about powerset is that it is great for reasoning and as a
starting point
for a derivation, but horrible as a data structure. Power sets get
very big very
fast, and even in a lazy language, where you might not store an entire powerset,
traversing one takes a lot of time. So it's seldom included in
practical finite set
implementations.
On Sat, 31 Jul 2021 at 22:15, Stuart Hungerford
wrote:
>
> On Sat, Jul 31, 2021 at 7:14 PM Henning Thielemann
> wrote:
>
> > [...]
> > A more modern approach would use type functions:
> >
> > class Setish set where
> > type Element set
> > empty :: set
> > singleton :: Element set -> set
>
> Thanks for the pointer.
>
> > > My question is how does the functional dependency in Setish interact
> > > with "extra" types needed for richer set operations like finding the
> > > powerset or taking a cartesian product?
> >
> > powerset would need a type like:
> >
> > powerset ::
> > (Powersettish powerset, Element powerset ~ set, Setish set) =>
> > set -> powerset
> >
> > with an extra Powersettish class.
> >
> > However, the type checker could not guess the exact powerset type, it
> > could be, e.g.
> > powerset :: Set a -> Set (Set a)
> > or
> > powerset :: Set a -> [Set a]
>
> Okay, I'm starting to see why the "Set" typeclass examples I could
> find don't include a powerset or cartesian product method.
>
> Thanks again,
>
> Stu
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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 stuart.hungerford at gmail.com Mon Aug 2 08:47:14 2021
From: stuart.hungerford at gmail.com (Stuart Hungerford)
Date: Mon, 2 Aug 2021 18:47:14 +1000
Subject: [Haskell-cafe] Sets, typeclasses and functional dependencies
In-Reply-To:
References:
<5982b2a2-c5d1-b2ef-8b32-d9d691c1fb75@henning-thielemann.de>
Message-ID:
On Mon, Aug 2, 2021 at 12:29 PM Richard O'Keefe wrote:
> The thing about powerset is that it is great for reasoning and as a
> starting point
> for a derivation, but horrible as a data structure. Power sets get
> very big very
> fast, and even in a lazy language, where you might not store an entire powerset,
> traversing one takes a lot of time. So it's seldom included in
> practical finite set
> implementations.
Very true, although there's something neat about being able to
generate 2^{some set}.
I'm mainly interested in doing the exercises in the "Haskell Road to
Logic and Mathematics" with some added exploration, e.g. a Set
typeclass.
Stu
From hecate at glitchbra.in Mon Aug 2 21:52:52 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Mon, 2 Aug 2021 23:52:52 +0200
Subject: [Haskell-cafe] base64-bytestring memory corruption bug
In-Reply-To:
References:
Message-ID:
Hi Fraser, do you have further information about this situation?
Le 25/07/2021 à 07:50, Fraser Tweedale a écrit :
> Hello,
>
> I want to bring to wider attention a memory bug present in
> base64-bytestring[1]. In summary, in some cases too few bytes are
> allocated for the output when performing base64url decoding. This
> can lead to memory corruption (which I have observed[2]), and
> possibly crashes (which I have not observed).
>
> I submitted a pull request[2] that fixes the issue some days ago,
> but did not receive a response from the maintainers yet. I
> understand that maintainers may be busy or unavailable, and that is
> fine. So I am posting here mainly to ensure that USERS are aware of
> the issue.
>
> To maintainers: let me know if I can provider further assistance to
> resolve this issue and release a fix.
>
> [1] https://github.com/haskell/base64-bytestring/issues/44
> [2] https://github.com/frasertweedale/hs-jose/issues/102
> [3] https://github.com/haskell/base64-bytestring/pull/45
>
> Thanks,
> Fraser
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
From frase at frase.id.au Tue Aug 3 03:40:26 2021
From: frase at frase.id.au (Fraser Tweedale)
Date: Tue, 3 Aug 2021 13:40:26 +1000
Subject: [Haskell-cafe] base64-bytestring memory corruption bug
In-Reply-To:
References:
Message-ID:
A new proposed fix is being discussed in
https://github.com/haskell/base64-bytestring/pull/46.
Expect a fix merged and new release sometime in the next few days.
Big thanks to all involved in pinpointing and resolving this issue.
Cheers,
Fraser
On Mon, Aug 02, 2021 at 11:52:52PM +0200, Hécate wrote:
> Hi Fraser, do you have further information about this situation?
>
> Le 25/07/2021 à 07:50, Fraser Tweedale a écrit :
> > Hello,
> >
> > I want to bring to wider attention a memory bug present in
> > base64-bytestring[1]. In summary, in some cases too few bytes are
> > allocated for the output when performing base64url decoding. This
> > can lead to memory corruption (which I have observed[2]), and
> > possibly crashes (which I have not observed).
> >
> > I submitted a pull request[2] that fixes the issue some days ago,
> > but did not receive a response from the maintainers yet. I
> > understand that maintainers may be busy or unavailable, and that is
> > fine. So I am posting here mainly to ensure that USERS are aware of
> > the issue.
> >
> > To maintainers: let me know if I can provider further assistance to
> > resolve this issue and release a fix.
> >
> > [1] https://github.com/haskell/base64-bytestring/issues/44
> > [2] https://github.com/frasertweedale/hs-jose/issues/102
> > [3] https://github.com/haskell/base64-bytestring/pull/45
> >
> > Thanks,
> > Fraser
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
> --
> Hécate ✨
> 🐦: @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
From compl.yue at icloud.com Tue Aug 3 09:19:32 2021
From: compl.yue at icloud.com (YueCompl)
Date: Tue, 3 Aug 2021 17:19:32 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as
some handleable bottom?
Message-ID: <1CB723C2-A8AE-4E10-BCD1-08B6D202B2A1@icloud.com>
Dear Cafe,
I kinda understand the [Floating](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:Floating ) class doesn't care about NaN, as not expecting all floating point implementations to have such semantics.
But [IEEE Silent NaN](https://en.wikipedia.org/wiki/NaN#Quiet_NaN ) has become a norm today, I think it deserves more than mere [isNaN](https://hackage.haskell.org/package/base/docs/GHC-Float.html#v:isNaN ) in the [RealFloat](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:RealFloat ) class.
While [Signaling NaN](https://en.wikipedia.org/wiki/NaN#Signaling_NaN ) can be an `Exception` triggering bottom like "divide by zero" is, the silent `NaN` feels like a different kind of bottom, or some thing similar to `Nothing` as in the `Num a => Maybe a` monad?
Is Haskell's type system capable of encoding silent NaN as a special kind/type of bottom that handleable?
Though I don't think I've gained correct understanding at all, on "bottom"s, I'm interested in what options we have to encode them, especially ergonomics ways to handle them accordingly.
Best regards,
Compl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jarnold at sydrom.com Tue Aug 3 16:45:44 2021
From: jarnold at sydrom.com (John Arnold)
Date: Tue, 3 Aug 2021 12:45:44 -0400
Subject: [Haskell-cafe] Parsing XML
Message-ID:
I am building a prototype for processing ISO 20022 Payment Initiation
messages. These messages are in XML format and I want the prototype to be
built using Haskell.
Conducting a search for 'Haskell XML parsing' yields postings that are in
the region of 10+yrs old.
I am sure there are packages that have been developed/update in the recent
past.
Any thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From thedward at barsoom.net Tue Aug 3 18:03:37 2021
From: thedward at barsoom.net (Thedward Blevins)
Date: Tue, 3 Aug 2021 13:03:37 -0500
Subject: [Haskell-cafe] Parsing XML
In-Reply-To:
References:
Message-ID:
Did you try looking on Hackage ?
After just a quick search I found these:
- xml-parser
- xml-conduit
- hxt
- xml
On Tue, Aug 3, 2021 at 11:46 AM John Arnold wrote:
> I am building a prototype for processing ISO 20022 Payment Initiation
> messages. These messages are in XML format and I want the prototype to be
> built using Haskell.
>
> Conducting a search for 'Haskell XML parsing' yields postings that are in
> the region of 10+yrs old.
>
> I am sure there are packages that have been developed/update in the recent
> past.
> Any thoughts?
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view 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:
From hecate at glitchbra.in Tue Aug 3 20:44:27 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Tue, 3 Aug 2021 22:44:27 +0200
Subject: [Haskell-cafe] base64-bytestring memory corruption bug
In-Reply-To:
References:
Message-ID: <9e5d736f-b40b-601a-c174-94b4f663941a@glitchbra.in>
Wonderful, happy to know it's been resolved!
Le 03/08/2021 à 05:40, Fraser Tweedale a écrit :
> A new proposed fix is being discussed in
> https://github.com/haskell/base64-bytestring/pull/46.
>
> Expect a fix merged and new release sometime in the next few days.
>
> Big thanks to all involved in pinpointing and resolving this issue.
>
> Cheers,
> Fraser
>
> On Mon, Aug 02, 2021 at 11:52:52PM +0200, Hécate wrote:
>> Hi Fraser, do you have further information about this situation?
>>
>> Le 25/07/2021 à 07:50, Fraser Tweedale a écrit :
>>> Hello,
>>>
>>> I want to bring to wider attention a memory bug present in
>>> base64-bytestring[1]. In summary, in some cases too few bytes are
>>> allocated for the output when performing base64url decoding. This
>>> can lead to memory corruption (which I have observed[2]), and
>>> possibly crashes (which I have not observed).
>>>
>>> I submitted a pull request[2] that fixes the issue some days ago,
>>> but did not receive a response from the maintainers yet. I
>>> understand that maintainers may be busy or unavailable, and that is
>>> fine. So I am posting here mainly to ensure that USERS are aware of
>>> the issue.
>>>
>>> To maintainers: let me know if I can provider further assistance to
>>> resolve this issue and release a fix.
>>>
>>> [1] https://github.com/haskell/base64-bytestring/issues/44
>>> [2] https://github.com/frasertweedale/hs-jose/issues/102
>>> [3] https://github.com/haskell/base64-bytestring/pull/45
>>>
>>> Thanks,
>>> Fraser
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>> --
>> Hécate ✨
>> 🐦: @TechnoEmpress
>> IRC: Hecate
>> WWW: https://glitchbra.in
>> RUN: BSD
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
From ruben.astud at gmail.com Tue Aug 3 21:46:46 2021
From: ruben.astud at gmail.com (Ruben Astudillo)
Date: Tue, 3 Aug 2021 17:46:46 -0400
Subject: [Haskell-cafe] Parsing XML
In-Reply-To:
References:
Message-ID:
Hello.
On 03-08-21 12:45, John Arnold wrote:
> Conducting a search for 'Haskell XML parsing' yields postings that are in
> the region of 10+yrs old.
I think that has more to do with the general xml popularity. People aren't
writing XML tutorial in haskell anymore. Now if you look at the json parsing
tutorial...
> I am sure there are packages that have been developed/update in the recent
> past.
> Any thoughts?
The go to option was and is `hxt` [1]. It's a little bit on the huge size,
but it should have the biggest use on the ecosystem [2]. There are probably
newer options now that use lenses if you are on that sort of thing, but I
don't know them.
Good luck.
Rubén. pgp: 4EE9 28F7 932E F4AD
[1]: https://hackage.haskell.org/package/hxt
[2]: https://packdeps.haskellers.com/reverse/hxt
On 03-08-21 12:45, John Arnold wrote:
> I am building a prototype for processing ISO 20022 Payment Initiation
> messages. These messages are in XML format and I want the prototype to be
> built using Haskell.
>
> Conducting a search for 'Haskell XML parsing' yields postings that are in
> the region of 10+yrs old.
>
> I am sure there are packages that have been developed/update in the recent
> past.
> Any thoughts?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL:
From magnus at therning.org Wed Aug 4 06:33:31 2021
From: magnus at therning.org (Magnus Therning)
Date: Wed, 04 Aug 2021 08:33:31 +0200
Subject: [Haskell-cafe] Parsing XML
In-Reply-To:
References:
Message-ID: <87bl6dpvg2.fsf@therning.org>
Thedward Blevins writes:
> Did you try looking on Hackage?
>
> After just a quick search I found these:
>
> * xml-parser
> * xml-conduit
> * hxt
> * xml
The code we have at work related to PAIN.001.001.03 is using the
following libs related to XML:
- xml-hamlet
- xml-conduit
- xml-conduit-writer
/M
--
Magnus Therning OpenPGP: 0x927912051716CE39
email: magnus at therning.org
@magthe at mastodon.technology http://magnus.therning.org/
You can't depend on your judgement when your imagination is out of
focus.
— Mark Twain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL:
From stuart.hungerford at gmail.com Wed Aug 4 06:50:21 2021
From: stuart.hungerford at gmail.com (Stuart Hungerford)
Date: Wed, 4 Aug 2021 16:50:21 +1000
Subject: [Haskell-cafe] GHC 9.x on M1 mac?
Message-ID:
Hi Haskellers,
Has anyone been able to build a 9.x series GHC installation for the M1
mac with macOS, in native binary form (i.e. not under Rosetta
translation)?
TIA,
Stu
From lemming at henning-thielemann.de Wed Aug 4 07:46:34 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 4 Aug 2021 09:46:34 +0200 (CEST)
Subject: [Haskell-cafe] Parsing XML
In-Reply-To: <87bl6dpvg2.fsf@therning.org>
References:
<87bl6dpvg2.fsf@therning.org>
Message-ID: <81854da8-dbd5-b954-8b54-4abeea3c2c9@henning-thielemann.de>
On Wed, 4 Aug 2021, Magnus Therning wrote:
> Thedward Blevins writes:
>
>> Did you try looking on Hackage?
>>
>> After just a quick search I found these:
>>
>> * xml-parser
>> * xml-conduit
>> * hxt
>> * xml
>
> The code we have at work related to PAIN.001.001.03 is using the following
> libs related to XML:
>
> - xml-hamlet
> - xml-conduit
> - xml-conduit-writer
* xeno
* HaXml
* xml-basic
* tagchup
* wraxml
From mgajda at mimuw.edu.pl Wed Aug 4 13:08:08 2021
From: mgajda at mimuw.edu.pl (Michal J Gajda)
Date: Wed, 4 Aug 2021 15:08:08 +0200
Subject: [Haskell-cafe] Parsing XML
Message-ID:
Dear John,
I recommend Xeno: https://gitlab.com/migamake/xeno
It was released on Hackage some time ago by Chris Done, then
maintained by Marco Zocca.
It was benchmarked against fastest parsers in both Haskell and other languages:
* https://arxiv.org/abs/2011.03536
* http://neilmitchell.blogspot.com/2016/12/new-xml-parser-hexml.html
It allows you to use SAX and DOM-style processing. It has an awesome
memory efficiency that is surpassed only by PugiXML parser (which
builds DOM in place, but occasionally crashes).
It does not support some XML features (namespaces, entity
normalization etc.), but these can be added as postprocessing after
the DOM is built.
It is maintained. And there is a yet unreleased version that can be
used to parse HTML documents and documents that are not well formed.
Disclosure: I am current maintainer.
--
Cheers
Michał J. Gajda
From mgajda at mimuw.edu.pl Wed Aug 4 13:11:05 2021
From: mgajda at mimuw.edu.pl (Michal J Gajda)
Date: Wed, 4 Aug 2021 15:11:05 +0200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
Message-ID:
Dear Yue,
Bottom has much weaker semantics than an exception: it means You may
never get a result and thus will never handle it!
Another reason is convenience: it is frequently the case that giving
NaN in a row of numbers is much more informative than crashing a
program with an exception and never printing the result anyway.
Finally IEEE special values have clear propagation semantics: they are
basically Maybe on steroids.
The problem with this approach is indeed a silent handling.
But in order to fix this, it is better to add preconditions to
specific algorithms that do not allow IEEE special value on input
(`isFinite` or `isNotNaN`) and then track the origin of the special
value with the methods like those described here:
https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
Never throw an error without telling exactly why it happened and
exactly where to fix it :-). Using bottom is last resort; exceptions
likewise.
--
Cheers
Michał
From compl.yue at icloud.com Wed Aug 4 14:00:07 2021
From: compl.yue at icloud.com (YueCompl)
Date: Wed, 4 Aug 2021 22:00:07 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References:
Message-ID:
Thanks Michał,
I feel less confused as I realized the non-halting possibility per bottoms, from your hint.
I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.
Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.
> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity
> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.
So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
* Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
* Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
* Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
Cheers,
Compl
> On 2021-08-04, at 02:38, Michał J Gajda wrote:
>
> Dear Yue,
>
> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!
>
> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway.
>
> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.
>
> The problem with this approach is indeed a silent handling.
>
> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
>
> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.
> --
> Cheers
> Michał
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mgajda at mimuw.edu.pl Wed Aug 4 14:24:31 2021
From: mgajda at mimuw.edu.pl (Michal J Gajda)
Date: Wed, 4 Aug 2021 16:24:31 +0200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References:
Message-ID:
The infamous `NaN /= NaN` makes only sense for `NaN` originating as a
result, since we cannot compare `NaN`s originating from different
computations.
But it breaks `Eq` instance laws as needed for property tests.
That is why comparison on `NaN` is better handled by `isFinite`,
`isANumber` predicates.
Note that beside `NaN` we also have other anomalous values, like
Underflow, Overflow, +inf and -inf.
These are all error values, and can hardly be treated in any other way.
And they all need to be handled for floating points.
Yes, comparing `NaN` with anything should give a rise to another error value.
That means that the only way out is making Either Error Float, and
then `(>=) :: Either Error Float -> Either Error Float -> Either Error
Bool`
So basically we need to lift all `Num` operations to the `Either Error` Monad.
That is probably best way to fix the problem: once error value
appears, we need to treat it consistently throughout entire
computation.
At the same time, we do not want a single error value to dominate
entire computation, so that is why we treat collections of
computations as computations that give a collection of good results
and a collection of errors separately.
If we take this into consideration, we notice that most interesting
computations occur on collections of values, and thus yield a
collection of results, not just a single output.
That is one takeaway from the referenced presentation on data
analytics in Haskell. (Similar presentation was also well received on
Data Science Europe. It should be on YouTube by now.)
Example of a 3D rotation is instructive: if NaN appears for any single
coordinate, we can get a useful results for all other coordinates, and
thus narrow impact of an error.
If the next step is projection on X-Y coordinates, then NaN or
Over/Under-flow within Z does not affect the result.
To my understanding, that is also the reason why IEEE mandated special
treatment of error values: most of the computations happen on large
matrices, vectors etc, and crashing for each single NaN would be a
true disaster.
It can be even ignored, when the NaN is computed for an energy
component within a single frame of long-running simulation, and the
error disappears within a single time step.
--
Cheers
Michał
On Wed, Aug 4, 2021 at 4:00 PM YueCompl wrote:
>
> Thanks Michał,
>
> I feel less confused as I realized the non-halting possibility per bottoms, from your hint.
>
> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.
>
> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
>
> > Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.
>
> > Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity
>
> > Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.
>
> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
>
> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
>
> No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
>
> Cheers,
> Compl
>
> On 2021-08-04, at 02:38, Michał J Gajda wrote:
>
> Dear Yue,
>
> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!
>
> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway.
>
> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.
>
> The problem with this approach is indeed a silent handling.
>
> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
>
> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.
> --
> Cheers
> Michał
>
>
--
Pozdrawiam
Michał
From compl.yue at icloud.com Wed Aug 4 14:56:14 2021
From: compl.yue at icloud.com (YueCompl)
Date: Wed, 4 Aug 2021 22:56:14 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References:
Message-ID: <85E4F929-17CC-4CC6-9696-0674B55E37DA@icloud.com>
`Eq` relies on the established `Bool` type, then can we solve it, if given algebraic effects & handlers, by Church-encoding an effectful Boolean type? e.g.
true === \a b -> a
false === \a b -> b
cmpWithNaN === \a b -> perform ComparingWithNaN
Then (==) and (/=) in `Eq`, together with friends in `Ord` like (>) (<) all return `cmpWithNaN` when at least one NaN is involved.
This mechanism is open so all kinds of anomalies can be handled similarly, otherwise even we have all NaN, Inf, Underflow, Overflow etc. handled well, there must be more situations we haven't thought of.
> On 2021-08-04, at 22:24, Michal J Gajda wrote:
>
> The infamous `NaN /= NaN` makes only sense for `NaN` originating as a
> result, since we cannot compare `NaN`s originating from different
> computations.
> But it breaks `Eq` instance laws as needed for property tests.
> That is why comparison on `NaN` is better handled by `isFinite`,
> `isANumber` predicates.
> Note that beside `NaN` we also have other anomalous values, like
> Underflow, Overflow, +inf and -inf.
> These are all error values, and can hardly be treated in any other way.
> And they all need to be handled for floating points.
>
> Yes, comparing `NaN` with anything should give a rise to another error value.
> That means that the only way out is making Either Error Float, and
> then `(>=) :: Either Error Float -> Either Error Float -> Either Error
> Bool`
> So basically we need to lift all `Num` operations to the `Either Error` Monad.
>
> That is probably best way to fix the problem: once error value
> appears, we need to treat it consistently throughout entire
> computation.
> At the same time, we do not want a single error value to dominate
> entire computation, so that is why we treat collections of
> computations as computations that give a collection of good results
> and a collection of errors separately.
> If we take this into consideration, we notice that most interesting
> computations occur on collections of values, and thus yield a
> collection of results, not just a single output.
>
> That is one takeaway from the referenced presentation on data
> analytics in Haskell. (Similar presentation was also well received on
> Data Science Europe. It should be on YouTube by now.)
>
> Example of a 3D rotation is instructive: if NaN appears for any single
> coordinate, we can get a useful results for all other coordinates, and
> thus narrow impact of an error.
> If the next step is projection on X-Y coordinates, then NaN or
> Over/Under-flow within Z does not affect the result.
>
> To my understanding, that is also the reason why IEEE mandated special
> treatment of error values: most of the computations happen on large
> matrices, vectors etc, and crashing for each single NaN would be a
> true disaster.
> It can be even ignored, when the NaN is computed for an energy
> component within a single frame of long-running simulation, and the
> error disappears within a single time step.
> --
> Cheers
> Michał
>
> On Wed, Aug 4, 2021 at 4:00 PM YueCompl > wrote:
>>
>> Thanks Michał,
>>
>> I feel less confused as I realized the non-halting possibility per bottoms, from your hint.
>>
>> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.
>>
>> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
>>
>>> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.
>>
>>> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity
>>
>>> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.
>>
>> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
>>
>> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
>> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
>> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
>>
>> No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
>>
>> Cheers,
>> Compl
>>
>> On 2021-08-04, at 02:38, Michał J Gajda wrote:
>>
>> Dear Yue,
>>
>> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!
>>
>> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway.
>>
>> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.
>>
>> The problem with this approach is indeed a silent handling.
>>
>> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
>>
>> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.
>> --
>> Cheers
>> Michał
>>
>>
>
>
> --
> Pozdrawiam
> Michał
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mgajda at mimuw.edu.pl Thu Aug 5 03:51:10 2021
From: mgajda at mimuw.edu.pl (Michal J Gajda)
Date: Thu, 5 Aug 2021 05:51:10 +0200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To: <85E4F929-17CC-4CC6-9696-0674B55E37DA@icloud.com>
References:
<85E4F929-17CC-4CC6-9696-0674B55E37DA@icloud.com>
Message-ID:
Yue,
Yes, it seems it would work
This useful workaround works uses exception effect.
So it may have two disadvantages:
1. You may only catch the effect in a monad that can catch exceptions, like
IO.
2. It does not give a clear path for handling collections of computations.
Note that DSLs also need to redefine Eq as effectful class. Then `(==) ::
Applicative expr => expr a -> expr a -> expr bool`.
This solution may be preferred if You have:
* a DSL already
* additional metadata attached to values, like provenance, security access
level, versioning, Merkle hash, memo hash, equivalence class etc.
* want to handle error values without exposing Yourself to imprecise
exceptions etc.
It has disadvantage of redefining several standard classes, and we do not
yet seem to have a library that would properly provide these type classes
parameterized over any Applicative.
But again, the need for more principled handling of error values will
likely come as software scales.
—
Best regards
Michał
On Wed, 4 Aug 2021 at 16:56 YueCompl wrote:
> `Eq` relies on the established `Bool` type, then can we solve it, if given
> algebraic effects & handlers, by Church-encoding an effectful Boolean type?
> e.g.
>
> true === \a b -> a
> false === \a b -> b
> cmpWithNaN === \a b -> perform ComparingWithNaN
>
> Then (==) and (/=) in `Eq`, together with friends in `Ord` like (>) (<)
> all return `cmpWithNaN` when at least one NaN is involved.
>
> This mechanism is open so all kinds of anomalies can be handled similarly,
> otherwise even we have all NaN, Inf, Underflow, Overflow etc. handled well,
> there must be more situations we haven't thought of.
>
>
> On 2021-08-04, at 22:24, Michal J Gajda wrote:
>
> The infamous `NaN /= NaN` makes only sense for `NaN` originating as a
> result, since we cannot compare `NaN`s originating from different
> computations.
> But it breaks `Eq` instance laws as needed for property tests.
> That is why comparison on `NaN` is better handled by `isFinite`,
> `isANumber` predicates.
> Note that beside `NaN` we also have other anomalous values, like
> Underflow, Overflow, +inf and -inf.
> These are all error values, and can hardly be treated in any other way.
> And they all need to be handled for floating points.
>
> Yes, comparing `NaN` with anything should give a rise to another error
> value.
> That means that the only way out is making Either Error Float, and
> then `(>=) :: Either Error Float -> Either Error Float -> Either Error
> Bool`
> So basically we need to lift all `Num` operations to the `Either Error`
> Monad.
>
> That is probably best way to fix the problem: once error value
> appears, we need to treat it consistently throughout entire
> computation.
> At the same time, we do not want a single error value to dominate
> entire computation, so that is why we treat collections of
> computations as computations that give a collection of good results
> and a collection of errors separately.
> If we take this into consideration, we notice that most interesting
> computations occur on collections of values, and thus yield a
> collection of results, not just a single output.
>
> That is one takeaway from the referenced presentation on data
> analytics in Haskell. (Similar presentation was also well received on
> Data Science Europe. It should be on YouTube by now.)
>
> Example of a 3D rotation is instructive: if NaN appears for any single
> coordinate, we can get a useful results for all other coordinates, and
> thus narrow impact of an error.
> If the next step is projection on X-Y coordinates, then NaN or
> Over/Under-flow within Z does not affect the result.
>
> To my understanding, that is also the reason why IEEE mandated special
> treatment of error values: most of the computations happen on large
> matrices, vectors etc, and crashing for each single NaN would be a
> true disaster.
> It can be even ignored, when the NaN is computed for an energy
> component within a single frame of long-running simulation, and the
> error disappears within a single time step.
> --
> Cheers
> Michał
>
> On Wed, Aug 4, 2021 at 4:00 PM YueCompl wrote:
>
>
> Thanks Michał,
>
> I feel less confused as I realized the non-halting possibility per
> bottoms, from your hint.
>
> I too think the signaling NaN is dreadful enough, so fortunately it's
> rarely seen nowadays.
>
> Actually what's on my mind was roughly something like "Maybe on steroids",
> I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at
> https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
>
> Note that due to the presence of @NaN@, not all elements of 'Float' have
> an additive inverse.
>
>
> Also note that due to the presence of -0, Float's 'Num' instance doesn't
> have an additive identity
>
>
> Note that due to the presence of @NaN@, not all elements of 'Float' have
> an multiplicative inverse.
>
>
> So it should have been another family of `Num` classes, within which,
> various NaN related semantics can be legal, amongst which I'd think:
>
> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems
> quite acceptable
> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or
> not?
> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a
> theoretical framework for this to hold? Maybe `Boolean` type needs
> enhancement too to do it?
>
> No such family of `Num` classes exists to my aware by now, I just can't
> help wondering why.
>
> Cheers,
> Compl
>
> On 2021-08-04, at 02:38, Michał J Gajda wrote:
>
> Dear Yue,
>
> Bottom has much weaker semantics than an exception: it means You may never
> get a result and thus will never handle it!
>
> Another reason is convenience: it is frequently the case that giving NaN
> in a row of numbers is much more informative than crashing a program with
> an exception and never printing the result anyway.
>
> Finally IEEE special values have clear propagation semantics: they are
> basically Maybe on steroids.
>
> The problem with this approach is indeed a silent handling.
>
> But in order to fix this, it is better to add preconditions to specific
> algorithms that do not allow IEEE special value on input (`isFinite` or
> `isNotNaN`) and then track the origin of the special value with the methods
> like those described here:
> https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
>
> Never throw an error without telling exactly why it happened and exactly
> where to fix it :-). Using bottom is last resort; exceptions likewise.
> --
> Cheers
> Michał
>
>
>
>
> --
> Pozdrawiam
> Michał
>
>
> --
Pozdrawiam
Michał
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From raoknz at gmail.com Thu Aug 5 07:26:27 2021
From: raoknz at gmail.com (Richard O'Keefe)
Date: Thu, 5 Aug 2021 19:26:27 +1200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References:
Message-ID:
You quoted
"> Note that due to the presence of @NaN@, not all elements of 'Float'
have an additive inverse."
Let x y and z be finite floating-point numbers such that x + y ==> z.
Does there always exist neg(y) such that z + neg(y) ==> x?
NO.
And the presence or absence of NaN in the system makes no difference.
If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly.
That is, (x + y) - y == 0, but x is not 0.
In the presence of rounding, additive inverses do not in general exist.
Neither do multiplicative inverses.
Also addition and multiplication are not associative, but you knew that.
The only reason Float and Double are in Num is because Haskell doesn't
offer ad hoc overloading. People have been saying that the Prelude needs
refactoring for years.
The main thing that NaN wrecks that wasn't already broken is Eq. I would
argue that the right decision there would have been to rule that x == y
(when x and y are floating point numbers) precisely when x and y are
represented by the same bit pattern, with a separate operation for IEEE
"ordered and equal".
At some point, Haskell should make provision for decimal floating point,
as the current versions of IEEE 754 and C do, and that might be a good
reorganisation time.
On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe
wrote:
>
> Thanks Michał,
>
> I feel less confused as I realized the non-halting possibility per bottoms, from your hint.
>
> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.
>
> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
>
> > Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.
>
> > Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity
>
> > Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.
>
> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
>
> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
>
> No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
>
> Cheers,
> Compl
>
> On 2021-08-04, at 02:38, Michał J Gajda wrote:
>
> Dear Yue,
>
> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!
>
> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway.
>
> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.
>
> The problem with this approach is indeed a silent handling.
>
> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
>
> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.
> --
> Cheers
> Michał
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
From compl.yue at icloud.com Thu Aug 5 08:22:56 2021
From: compl.yue at icloud.com (YueCompl)
Date: Thu, 5 Aug 2021 16:22:56 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References:
<85E4F929-17CC-4CC6-9696-0674B55E37DA@icloud.com>
Message-ID:
But I'd think algebraic effects is orthogonal to Monad/Applicative/Functor, it's capable to separate effects from pure code on its own.
Current standard classes in Haskell were designed without algebraic effect in mind. Especially the `Num` and its descendants, allied with `Eq` `Ord` and friends, I do see they can never allow `NaN` to be a legal existence, so there sure need another hierarchy of classes works similarly but embraces IEEE 754 at the same time. The hardware de facto has established intrinsic implementation of NaN/Inf semantics, including propagation during arithmetics and special rules during comparisons, we just need ratification in our type system, maybe retrospectively.
Or `NaN` is actually another [billion-dollar mistake](https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions ) we'd rather to avoid?
Aside from that, currently `ArithException` can only be caught within `IO` monad, but it can occur in evaluation of "pure" code. As I understand it, monad is a sublanguage to express "order" in execution (along with its bigger purpose of effect tracking), while evaluation of pure code has no "order" semantics thus in no need of monads. But pure code has nesting structures nevertheless, so to express the awareness/handling of NaN, "divide by zero" and similar situations, in a specific subsection of the pure code block, monad (i.e. IO here) based exception handling is not ideal here, as it sorta works by delimiting related pure computations into monadic steps, but that's unnatural or abuse of the execution order expressing device.
Algebraic effects & handlers is the perfect device for such support, as far as I see it now, but strangely I don't feel it's absolute necessary in doing this job. The situation is still messy in my head...
> On 2021-08-05, at 11:51, Michal J Gajda wrote:
>
> Yue,
>
> Yes, it seems it would work
> This useful workaround works uses exception effect.
> So it may have two disadvantages:
>
> 1. You may only catch the effect in a monad that can catch exceptions, like IO.
> 2. It does not give a clear path for handling collections of computations.
>
> Note that DSLs also need to redefine Eq as effectful class. Then `(==) :: Applicative expr => expr a -> expr a -> expr bool`.
>
> This solution may be preferred if You have:
>
> * a DSL already
> * additional metadata attached to values, like provenance, security access level, versioning, Merkel hash, memo hash, equivalence class etc.
> * want to handle error values without exposing Yourself to imprecise exceptions etc.
>
> It has disadvantage of redefining several standard classes, and we do not yet seem to have a library that would properly provide these type classes parameterized over any Applicative.
>
> But again, the need for more principled handling of error values will likely come as software scales.
> —
> Best regards
> Michał
>
>
>
> On Wed, 4 Aug 2021 at 16:56 YueCompl > wrote:
> `Eq` relies on the established `Bool` type, then can we solve it, if given algebraic effects & handlers, by Church-encoding an effectful Boolean type? e.g.
>
> true === \a b -> a
> false === \a b -> b
> cmpWithNaN === \a b -> perform ComparingWithNaN
>
> Then (==) and (/=) in `Eq`, together with friends in `Ord` like (>) (<) all return `cmpWithNaN` when at least one NaN is involved.
>
> This mechanism is open so all kinds of anomalies can be handled similarly, otherwise even we have all NaN, Inf, Underflow, Overflow etc. handled well, there must be more situations we haven't thought of.
>
>
>> On 2021-08-04, at 22:24, Michal J Gajda > wrote:
>>
>> The infamous `NaN /= NaN` makes only sense for `NaN` originating as a
>> result, since we cannot compare `NaN`s originating from different
>> computations.
>> But it breaks `Eq` instance laws as needed for property tests.
>> That is why comparison on `NaN` is better handled by `isFinite`,
>> `isANumber` predicates.
>> Note that beside `NaN` we also have other anomalous values, like
>> Underflow, Overflow, +inf and -inf.
>> These are all error values, and can hardly be treated in any other way.
>> And they all need to be handled for floating points.
>>
>> Yes, comparing `NaN` with anything should give a rise to another error value.
>> That means that the only way out is making Either Error Float, and
>> then `(>=) :: Either Error Float -> Either Error Float -> Either Error
>> Bool`
>> So basically we need to lift all `Num` operations to the `Either Error` Monad.
>>
>> That is probably best way to fix the problem: once error value
>> appears, we need to treat it consistently throughout entire
>> computation.
>> At the same time, we do not want a single error value to dominate
>> entire computation, so that is why we treat collections of
>> computations as computations that give a collection of good results
>> and a collection of errors separately.
>> If we take this into consideration, we notice that most interesting
>> computations occur on collections of values, and thus yield a
>> collection of results, not just a single output.
>>
>> That is one takeaway from the referenced presentation on data
>> analytics in Haskell. (Similar presentation was also well received on
>> Data Science Europe. It should be on YouTube by now.)
>>
>> Example of a 3D rotation is instructive: if NaN appears for any single
>> coordinate, we can get a useful results for all other coordinates, and
>> thus narrow impact of an error.
>> If the next step is projection on X-Y coordinates, then NaN or
>> Over/Under-flow within Z does not affect the result.
>>
>> To my understanding, that is also the reason why IEEE mandated special
>> treatment of error values: most of the computations happen on large
>> matrices, vectors etc, and crashing for each single NaN would be a
>> true disaster.
>> It can be even ignored, when the NaN is computed for an energy
>> component within a single frame of long-running simulation, and the
>> error disappears within a single time step.
>> --
>> Cheers
>> Michał
>>
>> On Wed, Aug 4, 2021 at 4:00 PM YueCompl > wrote:
>>>
>>> Thanks Michał,
>>>
>>> I feel less confused as I realized the non-halting possibility per bottoms, from your hint.
>>>
>>> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.
>>>
>>> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
>>>
>>>> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.
>>>
>>>> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity
>>>
>>>> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.
>>>
>>> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
>>>
>>> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
>>> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
>>> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
>>>
>>> No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
>>>
>>> Cheers,
>>> Compl
>>>
>>> On 2021-08-04, at 02:38, Michał J Gajda > wrote:
>>>
>>> Dear Yue,
>>>
>>> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!
>>>
>>> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway.
>>>
>>> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.
>>>
>>> The problem with this approach is indeed a silent handling.
>>>
>>> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
>>>
>>> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.
>>> --
>>> Cheers
>>> Michał
>>>
>>>
>>
>>
>> --
>> Pozdrawiam
>> Michał
>
> --
> Pozdrawiam
> Michał
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From compl.yue at icloud.com Thu Aug 5 08:41:42 2021
From: compl.yue at icloud.com (YueCompl)
Date: Thu, 5 Aug 2021 16:41:42 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References:
Message-ID:
> At some point, Haskell should make provision for decimal floating point,
> as the current versions of IEEE 754 and C do, and that might be a good
> reorganisation time.
Yeah, I think this is the thing I'm anticipating, current standard classes favor lossless computation by the laws, but large portion of the computer numeric solutions are taking loss of precision for efficiency. And neural systems even right following this approach as far as it appears, I sincerely hope Haskell can embrace it to some degree.
> On 2021-08-05, at 15:26, Richard O'Keefe wrote:
>
> You quoted
> "> Note that due to the presence of @NaN@, not all elements of 'Float'
> have an additive inverse."
>
> Let x y and z be finite floating-point numbers such that x + y ==> z.
> Does there always exist neg(y) such that z + neg(y) ==> x?
> NO.
>
> And the presence or absence of NaN in the system makes no difference.
> If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly.
> That is, (x + y) - y == 0, but x is not 0.
>
> In the presence of rounding, additive inverses do not in general exist.
> Neither do multiplicative inverses.
>
> Also addition and multiplication are not associative, but you knew that.
> The only reason Float and Double are in Num is because Haskell doesn't
> offer ad hoc overloading. People have been saying that the Prelude needs
> refactoring for years.
>
> The main thing that NaN wrecks that wasn't already broken is Eq. I would
> argue that the right decision there would have been to rule that x == y
> (when x and y are floating point numbers) precisely when x and y are
> represented by the same bit pattern, with a separate operation for IEEE
> "ordered and equal".
>
> At some point, Haskell should make provision for decimal floating point,
> as the current versions of IEEE 754 and C do, and that might be a good
> reorganisation time.
>
>
> On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe
> wrote:
>>
>> Thanks Michał,
>>
>> I feel less confused as I realized the non-halting possibility per bottoms, from your hint.
>>
>> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.
>>
>> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
>>
>>> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.
>>
>>> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity
>>
>>> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.
>>
>> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
>>
>> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
>> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
>> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
>>
>> No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
>>
>> Cheers,
>> Compl
>>
>> On 2021-08-04, at 02:38, Michał J Gajda wrote:
>>
>> Dear Yue,
>>
>> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!
>>
>> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway.
>>
>> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.
>>
>> The problem with this approach is indeed a silent handling.
>>
>> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
>>
>> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.
>> --
>> Cheers
>> Michał
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
From olf at aatal-apotheke.de Thu Aug 5 18:48:09 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 05 Aug 2021 20:48:09 +0200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
Message-ID: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
>
> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
>
> No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
>
> Cheers,
> Compl
>
I like to think of NaN as a glimpse of interval arithmetic. NaN is the
interval -infintity to infinity [*]. When ordering intervals by reverse
inclusion, NaN is indeed the bottom of the domain. For a general
(closed) interval [x,y], how would you answer the questions
[x,y] < [1,1]?
[x,y] /= [1,1]?
There are several possibilities known, extending relations on points to
relations on sets. See Smyth-, Hoare- and Egli-Milner lifting of
relations. So a more descriptive type of Float-ordering may be
(<) :: Float -> Float -> RelationLifting -> Bool
For example, NaN /= NaN under all three relation liftings mentioned
above, but also NaN == NaN, so a /= b = not (a == b) does not hold
anymore.
> If we take this into consideration, we notice that most interesting
> computations occur on collections of values, and thus yield a
> collection of results, not just a single output.
Indeed, one route to real arithmetic is via limits of collections of
approximants. For example, consider a dense set of rationals, excluding
zero, where that all arithmetic operations are well-defined and total
on the approximants. Then express a real number as (Dedekind-)cuts and
see what cut operations like 0/0 result in. Each non-proper cut
corresponds to a special Float value. Incidentally, this is how Conway
constructed his surreal numbers that also contain values like infinity
and -0.
I'm in favour that there be two floating-point types: One IEEE-
compliant that behaves just like in other languages, and one more
lawful one (thereby with fewer class instances) that leverages the
expressive power of Haskell. Ho matter how broken, the former should be
the default unless we want to alienate numerically inclined Haskell
adopters.
Olaf
[*] The mathematical function \(x,y) -> x/y attains every real value
arbitrarily close to (0,0), whence NaN = 0/0 should be interpreted as
the interval encompassing the real line. Likewise log(0) for complex 0.
From ifl21.publicity at gmail.com Thu Aug 5 20:53:39 2021
From: ifl21.publicity at gmail.com (Pieter Koopman)
Date: Thu, 5 Aug 2021 16:53:39 -0400
Subject: [Haskell-cafe] IFL'21 Final call for papers
Message-ID:
================================================================================
IFL 2021
33rd Symposium on Implementation and Application of Functional Languages
venue: online
1 - 3 September 2021
https://ifl21.cs.ru.nl
================================================================================
Note:
- We do accept extended abstracts for presentation
- Submission is open
- Registration is open
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 2021 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.
Industrial track and topics of interest
This year's edition of IFL explicitly solicits original work concerning
*applications*
of functional programming in industry and academia. These contributions
will be reviewed by experts with an industrial background.
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 specialisation
* run-time code generation
* partial evaluation
* (abstract) interpretation
* meta-programming
* 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
* testing and proofing
* virtual/abstract machine architectures
* validation, verification of functional programs
* tools and programming techniques
* applications of functional programming in the industry, including
** functional programming techniques for large applications
** successes of the application functional programming
** challenges for functional programming encountered
** any topic related to the application of functional programming that is
interesting for the IFL community
Post-symposium peer-review
Following IFL tradition, IFL 2021 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 chairs 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.
After the symposium every presenter is invited to submit a full paper,
incorporating feedback from discussions at the symposium. Work submitted to
IFL
may not be simultaneously submitted to other venues; submissions must
adhere to ACM SIGPLAN's republication policy. The program committee will
evaluate these submissions according to their correctness, novelty,
originality,
relevance, significance, and clarity, and will thereby determine whether the
paper is accepted or rejected for the formal proceedings. We plan to publish
these proceedings in the International Conference Proceedings Series of the
ACM Digital Library, as in previous years. Moreover, the proceedings will
also
be made publicly available as open access.
Important dates
Submission deadline of draft papers: 17 August 2021
Notification of acceptance for presentation: 19 August 2021
Registration deadline: 30 August 2021
IFL Symposium: 1-3 September 2021
Submission of papers for proceedings: 6 December 2021
Notification of acceptance: 3 February 2022
Camera-ready version: 15 March 2022
Submission details
All contributions must be written in English. Papers must use the ACM two
columns conference format, which can be found at:
http://www.acm.org/publications/proceedings-template
.
(For LaTeX users, start your document with
\documentclass[format=sigconf]{acmart}.)
Note that this format has a rather long but limited list of packages that
can be used.
Please make sure that your document adheres to this list.
The submission Web page for IFL21 is
https://easychair.org/conferences/?conf=ifl21
.
Peter Landin Prize
The Peter Landin Prize is awarded to the best paper presented at the
symposium every year. The honoured article is selected by the program
committee
based on the submissions received for the formal review process. The prize
carries a cash award equivalent to 150 Euros.
Organisation
IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The
Netherlands
IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands
PC:
Peter Achten (co-chair) - Radboud University, Netherlands
Thomas van Binsbergen - University of Amsterdam, Netherlands
Edwin Brady - University of St. Andrews, Scotland
Laura Castro - University of A Coruña, Spain
Youyou Cong - Tokyo Institute of Technology, Japan
Olaf Chitil - University of Kent, England
Andy Gill - University of Kansas, USA
Clemens Grelck - University of Amsterdam, Netherlands
John Hughes - Chalmers University, Sweden
Pieter Koopman (co-chair) - Radboud University, Netherlands
Cynthia Kop - Radboud University, Netherlands
Jay McCarthey - University of Massachussetts Lowell, USA
Neil Mitchell - Facebook, England
Jan De Muijnck-Hughes - Glasgow University, Scotland
Keiko Nakata - SAP Innovation Center Potsdam, Germany
Jurriën Stutterheim - Standard Chartered, Singapore
Simon Thompson - University of Kent, England
Melinda Tóth - Eötvos Loránd University, Hungary
Phil Trinder - Glasgow University, Scotland
Meng Wang - University of Bristol, England
Viktória Zsók - Eötvos Loránd University, Hungary
Virtual symposium
Because of the Covid-19 pandemic, this year IFL 2021 will be an online
event,
consisting of paper presentations, discussions and virtual social
gatherings.
Registered participants can take part from anywhere in the world.
Registration
Please use the link below to register for IFL 2021:
https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8ofIqshfQFrf4jnvsA/viewform?usp=sf_link
Thanks to the sponsors and the support of the Radboud university
registration is free of charge.
[image: beacon]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From emilypi at cohomolo.gy Thu Aug 5 21:27:12 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Thu, 05 Aug 2021 21:27:12 +0000
Subject: [Haskell-cafe] [ANN] Cabal-3.6.0.0
Message-ID:
Hello All,
The Cabal team is excited to announce the release of Cabal-3.6.0.0!
This is the fourth release of the 3.0 release series, and highlights include support for GHC 9.2, as well as many new code quality improvements + organization work on the repo itself.
For future plans, we've announced a State of the Cabal post which describes where we want to take the library and executable over the next year or two here: https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548.
If you'd like to get involved, feel free to contact anyone from the maintainer team directly, or drop by #hackage on libera.chat ( http://libera.chat/ ) to speak with us. Additionally, as we continue to modernize Cabal, I'd like to highlight and show appreciation for all of the help we've gotten from the community, including the developer hours coming from Well-Typed, Haskell Foundation/Haskell.org ( http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell Language Server folks. I'm glad we could work together!
For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues.
Happy hacking!
Emily
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From icfp.publicity at googlemail.com Fri Aug 6 02:51:16 2021
From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt)
Date: Thu, 05 Aug 2021 22:51:16 -0400
Subject: [Haskell-cafe] Call for Participation: ICFP 2021
Message-ID: <610ca3a4aac4a_1ba72e4145@homer.mail>
=====================================================================
Call for Participation
ICFP 2021
26th ACM SIGPLAN International Conference on Functional Programming
and affiliated events
August 22 - August 27, 2021
Online
http://icfp21.sigplan.org/
Early Registration until August 7!
=====================================================================
ICFP provides a forum for researchers and developers to hear
about the latest work on the design, implementations, principles, and
uses of functional programming. The conference covers the entire
spectrum of work, from practice to theory, including its peripheries.
This year, the conference will be a virtual event. All activities will
take place online.
The main conference will take place from August 23-25, 2021 during two
time bands. The first band will be 4PM-11PM Seoul time, and will
include both technical and social activities. The second band will
repeat (with some variation) the technical program and social
activities 12 hours later, 3PM-10PM New York, the following day.
We’re excited to announce that ICFP 2021 will feature an invited talk
from Ravi Chugh of the University of Chicago. Keynote sessions will
take place at 10 PM Seoul/9 AM New York.
ICFP has officially accepted 35 exciting papers, and (in its second
year) there will also be presentations of 4 papers accepted recently
to the Journal of Functional Programming. Co-located symposia and
workshops will take place the day before and two days immediately
after the main conference.
Registration is now open. The early registration deadline is August
7th, 2021. Registration is not free, but is significantly lower than
usual, including a $10 discounted registration option available to
all. Students who are ACM or SIGPLAN members may register for FREE
before the early deadline.
https://regmaster.com/2021conf/ICFP21/register.php
New this year: Attendees will be able to sign-up for the ICFP
Mentoring Program (either to be a mentor, receive mentorship or both).
* Overview and affiliated events:
http://icfp21.sigplan.org/home
* Accepted papers:
http://icfp21.sigplan.org/track/icfp-2021-papers#event-overview
* JFP Talks:
https://icfp21.sigplan.org/track/icfp-2021-jfp-talks#event-overview
* Registration is available via:
https://regmaster.com/2021conf/ICFP21/register.php
Early registration ends 8 August, 2021.
* Programming contest:
https://icfpcontest2021.github.io/
* Student Research Competition:
https://icfp21.sigplan.org/track/icfp-2021-Student-Research-Competition
* Follow us on Twitter for the latest news:
http://twitter.com/icfp_conference
This year, there are 10 events co-located with ICFP:
* Erlang Workshop (8/26)
* Haskell Implementors' Workshop (8/22)
* Haskell Symposium (8/26-8/27)
* Higher-Order Programming with Effects (8/22)
* miniKanren Workshop (8/26)
* ML Family Workshop (8/26)
* OCaml Workshop (8/27)
* Programming Languages Mentoring Workshop (8/22)
* Scheme Workshop (8/27)
* Type-Driven Development (8/22)
### ICFP Organizers
General Chair: Sukyoung Ryu (KAIST, South Korea)
Program Chair: Ron Garcia (UBC, Canada)
Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA)
Gabriel Scherer (INRIA Saclay, France)
Industrial Relations Chair: Alan Jeffrey (Roblox, USA)
Simon Marlow (Facebook, UK)
Programming Contest Organizers: Alex Lang and Jasper Van der Jeugt
Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA)
Student Research Competition Chair: Anders Miltner (University of Texas, USA)
Workshops Co-Chairs: Zoe Paraskevopoulou (Northeastern University, USA)
Leonidas Lampropoulos (University of Maryland, USA)
Video Co-Chairs: Leif Andersen (Northeastern University, USA)
Ben Chung (Northeastern University, USA)
Student Volunteer Co-Chairs: Hanneli Tavante (McGill University, Canada)
Jaemin Hong (KAIST, South Korea)
Lily Bryant (UBC, Canada)
Accessibility Co-Chairs: Lindsey Kuper (UCSC, USA)
Kathrin Stark (Princeton, USA)
From xnningxie at gmail.com Fri Aug 6 04:06:37 2021
From: xnningxie at gmail.com (Ningning Xie)
Date: Fri, 6 Aug 2021 00:06:37 -0400
Subject: [Haskell-cafe] Call for Lightning Talks: Haskell Implementors'
Workshop @ ICFP'21
Message-ID:
Call for Lightning Talks
ACM SIGPLAN Haskell Implementors' Workshop
https://icfp21.sigplan.org/home/hiw-2021
Virtual, 22 Aug, 2021
Co-located with ICFP 2021
https://icfp21.sigplan.org/
Important dates
---------------
Deadline: Thursday, 19 Aug, 2021
(or when slots are full, whichever is sooner)
Workshop: Sunday, 22 Aug, 2021
The 13th Haskell Implementors' Workshop is to be held alongside ICFP
2021 this year virtually. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.
We will have a number of slots for lightning talks. Lightning talks
will be ~7 minutes and are scheduled on the day of the workshop.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.
Lightning talks are proposed by submitting a title and an abstract.
Submissions will not be part of the peer-review process. Notification
of acceptance will be continuous until slots are full.
Submissions should be made via Google form:
https://forms.gle/BmUSyWWTXt1AMTec8
Accepted lightning talks will be posted on the workshop’s website.
Scope and target audience
-------------------------
The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are specially encouraged to share their work.
The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:
* Compilation techniques
* Language features and extensions
* Type system implementation
* Concurrency and parallelism: language design and implementation
* Performance, optimisation and benchmarking
* Virtual machines and run-time systems
* Libraries and tools for development or deployment
Logistics
---------
Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW)
will be held remotely this year. However, the organizers are still
working hard to provide for a great workshop experience.
While we are sad that this year will lack the robust hallway track that
is often the highlight of HIW, we believe that this remote workshop
presents a unique opportunity to include more of the Haskell community
in our discussion and explore new modes of communicating with our
colleagues. We hope that you will join us in making this HIW as
vibrant as any other.
Contact
-------
* Ningning Xie
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From victor.perez at imdea.org Fri Aug 6 12:02:54 2021
From: victor.perez at imdea.org (Victor Perez)
Date: Fri, 6 Aug 2021 14:02:54 +0200
Subject: [Haskell-cafe] Call for Workshops - FLoC 2022
Message-ID: <997f8788-71eb-da80-4789-541a833f2eec@imdea.org>
Second Call for Workshops- FLoC 2022 — The 2022 Federated Logic Conference
July 31 - August 12, 2022
Haifa, Israel
http://www.floc2022.org/
CALL FOR WORKSHOPS
The Eighth Federated Logic Conference (FLoC 2022) will host the
following ten
conferences and affiliated workshops.
LICS (37th Annual ACM/IEEE Symposium on Logic in Computer Science)
http://lics.rwth-aachen.de/
Workshop chair: Frederic Blanqui Frederic.Blanqui at inria.fr
FSCD (7th International Conference on Formal Structures for Computation
and Deduction)
http://fscd-conference.org/
Workshop chair: Nachum Dershowitz nachumd at tau.ac.il
ITP (13th International Conference on Interactive Theorem Proving)
https://itp-conference.github.io/
Workshop chair: Cyril Cohen cyril.cohen at inria.fr
IJCAR (International Joint Conference on Automated Reasoning)
http://www.ijcar.org
Workshop chairs: Simon Robillard simon.robillard at imt-atlantique.fr
Sophie Tourret stourret at mpi-inf.mpg.de
CSF (35th IEEE Computer Security Foundations Symposium)
http://www.ieee-security.org/CSFWweb/
Workshop chair: Musard Balliu musard at kth.se
CAV (34th International Conference on Computer Aided Verification)
http://i-cav.org/
Workshop chair: TBD
KR (19th International Conference on Principles of Knowledge
Representation and Reasoning)
http://www.kr.org/
Workshop chair: Stefan Borgwardt stefan.borgwardt at tu-dresden.de
ICLP (38th International Conference on Logic Programming)
https://www.cs.nmsu.edu/ALP/conferences/
Workshop chair: Daniela Inclezan inclezd at miamioh.edu
SAT (25th International Conference on Theory and Applications of
Satisfiability Testing)
http://www.satisfiability.org
Workshop chair: Alexander Nadel alexander.nadel at intel.com
CP (25th International Conference on Principles and Practice of
Constraint Programming)
http://a4cp.org/events/cp-conference-series
Workshop chair: TBD
SUBMISSION OF WORKSHOP PROPOSALS
Researchers and practitioners are invited to submit proposals for
workshops on
topics in the field of computer science, related to logic in the broad
sense.
Each workshop proposal must indicate one affiliated conference of FLoC 2022.
It is strongly suggested that prospective workshop organizers contact the
relevant conference workshop chair before submitting a proposal.
Each proposal should consist of the following two parts.
1) A short scientific justification of the proposed topic, its significance,
and the particular benefits of the workshop to the community, as well as a
list of previous or related workshops (if relevant).
2) An organisational part including:
- contact information for the workshop organizers;
- proposed affiliated conference;
- estimate of the number of workshop participants (please note that
small workshops, i.e., of less than ~13 participants, will likely be
cancelled or merged);
- proposed format and agenda (e.g. paper presentations, tutorials,
demo sessions, etc.);
- potential invited speakers (note that expenses of workshop invited
speakers are not covered by FLoC);
- procedures for selecting papers and participants;
- plans for dissemination, if any (e.g. a journal special issue);
- duration (which may vary from one day to two days);
- preferred period (pre or post FLoC);
- virtual/hybrid backup plans (including platform preference).
The FLoC Organizing Committee will determine the final list of accepted
workshops based on the recommendations from the Workshop Chairs of the
hosting
conferences and availability of space and facilities.
Proposals should be submitted through EasyChair:
https://easychair.org/conferences/?conf=floc2022workshops
Please see the Workshop Guidelines page: https://floc2022.org/workshops/
for further details and FAQ.
IMPORTANT DATES
Submission of workshop proposals deadline: September 27, 2021 (note
extended deadline)
Notification: November 1, 2021
Pre-FLoC workshops: Sunday & Monday, July 31–August 1, 2022 (note
corrected dates)
Post-FLoC workshops: Thursday & Friday, August 11-12, 2022
CONTACT INFORMATION
Questions regarding proposals should be sent to the workshop chairs of the
proposed affiliated conference. General questions should be sent to:
shaull at technion.ac.il
GuillermoAlberto.Perez at uantwerpen.be
FLoC 2022 WORKSHOP CHAIRS
Shaull Almagor
Guillermo A. Perez
From compl.yue at icloud.com Fri Aug 6 14:21:51 2021
From: compl.yue at icloud.com (YueCompl)
Date: Fri, 6 Aug 2021 22:21:51 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
Message-ID: <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com>
Thanks Olaf,
Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm.
Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it?
> On 2021-08-06, at 02:48, Olaf Klinke wrote:
>
>> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
>>
>> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
>> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
>> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
>>
>> No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
>>
>> Cheers,
>> Compl
>>
> I like to think of NaN as a glimpse of interval arithmetic. NaN is the
> interval -infintity to infinity [*]. When ordering intervals by reverse
> inclusion, NaN is indeed the bottom of the domain. For a general
> (closed) interval [x,y], how would you answer the questions
> [x,y] < [1,1]?
> [x,y] /= [1,1]?
> There are several possibilities known, extending relations on points to
> relations on sets. See Smyth-, Hoare- and Egli-Milner lifting of
> relations. So a more descriptive type of Float-ordering may be
> (<) :: Float -> Float -> RelationLifting -> Bool
> For example, NaN /= NaN under all three relation liftings mentioned
> above, but also NaN == NaN, so a /= b = not (a == b) does not hold
> anymore.
>
>> If we take this into consideration, we notice that most interesting
>> computations occur on collections of values, and thus yield a
>> collection of results, not just a single output.
>
> Indeed, one route to real arithmetic is via limits of collections of
> approximants. For example, consider a dense set of rationals, excluding
> zero, where that all arithmetic operations are well-defined and total
> on the approximants. Then express a real number as (Dedekind-)cuts and
> see what cut operations like 0/0 result in. Each non-proper cut
> corresponds to a special Float value. Incidentally, this is how Conway
> constructed his surreal numbers that also contain values like infinity
> and -0.
>
> I'm in favour that there be two floating-point types: One IEEE-
> compliant that behaves just like in other languages, and one more
> lawful one (thereby with fewer class instances) that leverages the
> expressive power of Haskell. Ho matter how broken, the former should be
> the default unless we want to alienate numerically inclined Haskell
> adopters.
>
> Olaf
>
> [*] The mathematical function \(x,y) -> x/y attains every real value
> arbitrarily close to (0,0), whence NaN = 0/0 should be interpreted as
> the interval encompassing the real line. Likewise log(0) for complex 0.
>
From olf at aatal-apotheke.de Fri Aug 6 22:16:39 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 07 Aug 2021 00:16:39 +0200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To: <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com>
References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
<7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com>
Message-ID:
On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote:
> Thanks Olaf,
>
> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm.
>
Pen-and-paper or GHCi experiments suffice here, no fancy theoretical
background needed. Say Q is the type of rationals 0 < q and we express
type NonNegativeNumber = ([Q],[Q])
where the first (infinite) list is the lower approximants and the
second the upper approximants. Multiplication is then defined as
(l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
The extremes of this type are
0 = ([],Q)
infty = (Q,[])
It is easily seen that
0 * infty = ([],[])
a number with no lower and no upper approximants, in other words, NaN.
Excercise: Define division for this type and find out what 1/0 and 0/0
is.
> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it?
>
Yes. I think it is vital that we provide a migration path for
programmers coming from other languages. Under the Dedekind
cut/interval interpretation, NaN would behave differently, as I pointed
out. So I'd leave Float as it is, but be more verbose about its
violation of type class laws. To this end, one could have (and now I
might be closer to your initial question) numerical type classes like
HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only
those types that obey the laws in all elements. Naturally, Float would
not be a member. Who would use these new classes? Probably no one,
because we all like to take the quick and dirty route. But at least it
says clearly: Careful, you can not rely on these laws when using Float.
Olaf
From compl.yue at icloud.com Sat Aug 7 07:35:56 2021
From: compl.yue at icloud.com (YueCompl)
Date: Sat, 7 Aug 2021 15:35:56 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
<7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com>
Message-ID: <7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com>
Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before.
But I need some help to get it going:
λ> :set -XTypeSynonymInstances
λ> :set -XFlexibleInstances
λ>
λ> import Data.Ratio
λ> type Q = Rational -- this is probably wrong ...
λ>
λ> type NonNegativeNumber = ([Q],[Q])
λ> :{
λ| instance Num NonNegativeNumber where
λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
λ| :}
:9:12: warning: [-Wmissing-methods]
• No explicit implementation for
‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’)
• In the instance declaration for ‘Num NonNegativeNumber’
λ>
λ> zero = ([],Q)
:13:13: error: Data constructor not in scope: Q
λ> infty = (Q,[])
:14:10: error: Data constructor not in scope: Q
λ>
λ> zero * infty -- expect: = ([],[])
:16:1: error: Variable not in scope: zero
:16:8: error: Variable not in scope: infty
λ>
I'd like to do more exercises, but I'm stuck here ...
> On 2021-08-07, at 06:16, Olaf Klinke wrote:
>
> On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote:
>> Thanks Olaf,
>>
>> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm.
>>
> Pen-and-paper or GHCi experiments suffice here, no fancy theoretical
> background needed. Say Q is the type of rationals 0 < q and we express
> type NonNegativeNumber = ([Q],[Q])
> where the first (infinite) list is the lower approximants and the
> second the upper approximants. Multiplication is then defined as
> (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
> The extremes of this type are
> 0 = ([],Q)
> infty = (Q,[])
> It is easily seen that
> 0 * infty = ([],[])
> a number with no lower and no upper approximants, in other words, NaN.
> Excercise: Define division for this type and find out what 1/0 and 0/0
> is.
>
>> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it?
>>
> Yes. I think it is vital that we provide a migration path for
> programmers coming from other languages. Under the Dedekind
> cut/interval interpretation, NaN would behave differently, as I pointed
> out. So I'd leave Float as it is, but be more verbose about its
> violation of type class laws. To this end, one could have (and now I
> might be closer to your initial question) numerical type classes like
> HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only
> those types that obey the laws in all elements. Naturally, Float would
> not be a member. Who would use these new classes? Probably no one,
> because we all like to take the quick and dirty route. But at least it
> says clearly: Careful, you can not rely on these laws when using Float.
>
> Olaf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From compl.yue at icloud.com Sat Aug 7 08:16:21 2021
From: compl.yue at icloud.com (YueCompl)
Date: Sat, 7 Aug 2021 16:16:21 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To: <7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com>
References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
<7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com>
<7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com>
Message-ID: <671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com>
Another failed attempt:
λ> :set -XTypeSynonymInstances
λ> :set -XFlexibleInstances
λ>
λ> data Q = Q
λ>
λ> type NonNegativeNumber = ([Q],[Q])
λ> :{
λ| instance Num NonNegativeNumber where
λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
λ| :}
:12:25: error:
• No instance for (Num Q) arising from a use of ‘*’
• In the expression: x * x'
In the expression: [x * x' | x <- l, x' <- l']
In the expression:
([x * x' | x <- l, x' <- l'], [y * y' | y <- r, y' <- r'])
λ>
λ> zero = ([],Q)
λ> infty = (Q,[])
λ> zero * infty
:17:8: error:
• Couldn't match type ‘Q’ with ‘[a]’
Expected type: ([a], Q)
Actual type: (Q, [a0])
• In the second argument of ‘(*)’, namely ‘infty’
In the expression: zero * infty
In an equation for ‘it’: it = zero * infty
• Relevant bindings include
it :: ([a], Q) (bound at :17:1)
λ>
> On 2021-08-07, at 15:35, YueCompl via Haskell-Cafe wrote:
>
> Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before.
>
> But I need some help to get it going:
>
> λ> :set -XTypeSynonymInstances
> λ> :set -XFlexibleInstances
> λ>
> λ> import Data.Ratio
> λ> type Q = Rational -- this is probably wrong ...
> λ>
> λ> type NonNegativeNumber = ([Q],[Q])
> λ> :{
> λ| instance Num NonNegativeNumber where
> λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
> λ| :}
>
> :9:12: warning: [-Wmissing-methods]
> • No explicit implementation for
> ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’)
> • In the instance declaration for ‘Num NonNegativeNumber’
> λ>
> λ> zero = ([],Q)
>
> :13:13: error: Data constructor not in scope: Q
> λ> infty = (Q,[])
>
> :14:10: error: Data constructor not in scope: Q
> λ>
> λ> zero * infty -- expect: = ([],[])
>
> :16:1: error: Variable not in scope: zero
>
> :16:8: error: Variable not in scope: infty
> λ>
>
> I'd like to do more exercises, but I'm stuck here ...
>
>
>> On 2021-08-07, at 06:16, Olaf Klinke > wrote:
>>
>> On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote:
>>> Thanks Olaf,
>>>
>>> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm.
>>>
>> Pen-and-paper or GHCi experiments suffice here, no fancy theoretical
>> background needed. Say Q is the type of rationals 0 < q and we express
>> type NonNegativeNumber = ([Q],[Q])
>> where the first (infinite) list is the lower approximants and the
>> second the upper approximants. Multiplication is then defined as
>> (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
>> The extremes of this type are
>> 0 = ([],Q)
>> infty = (Q,[])
>> It is easily seen that
>> 0 * infty = ([],[])
>> a number with no lower and no upper approximants, in other words, NaN.
>> Excercise: Define division for this type and find out what 1/0 and 0/0
>> is.
>>
>>> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it?
>>>
>> Yes. I think it is vital that we provide a migration path for
>> programmers coming from other languages. Under the Dedekind
>> cut/interval interpretation, NaN would behave differently, as I pointed
>> out. So I'd leave Float as it is, but be more verbose about its
>> violation of type class laws. To this end, one could have (and now I
>> might be closer to your initial question) numerical type classes like
>> HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only
>> those types that obey the laws in all elements. Naturally, Float would
>> not be a member. Who would use these new classes? Probably no one,
>> because we all like to take the quick and dirty route. But at least it
>> says clearly: Careful, you can not rely on these laws when using Float.
>>
>> Olaf
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From compl.yue at icloud.com Sat Aug 7 10:21:32 2021
From: compl.yue at icloud.com (YueCompl)
Date: Sat, 7 Aug 2021 18:21:32 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To: <671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com>
References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
<7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com>
<7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com>
<671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com>
Message-ID: <2452CA59-5207-4053-AC59-EFFDD660AC4B@icloud.com>
Okay, I got it working to some extent:
(and I find it a good showcase for my https://marketplace.visualstudio.com/items?itemName=ComplYue.vscode-ghci extension, improved it a bit to support this very scenario, with the src file at https://github.com/complyue/typing.hs/blob/main/src/PoC/Floating.hs )
Obviously my naive implementation `(l, r) / (l', r') = ([x / x' | x <- l, x' <- l'], [y / y' | y <- r, y' <- r'])` is wrong, I think I need to figure out how to represent 1 (the unit number) of this type, even before I can come to a correct definition of the division (/) operation, but so far no clue ...
> On 2021-08-07, at 16:16, YueCompl via Haskell-Cafe wrote:
>
> Another failed attempt:
>
> λ> :set -XTypeSynonymInstances
> λ> :set -XFlexibleInstances
> λ>
> λ> data Q = Q
> λ>
> λ> type NonNegativeNumber = ([Q],[Q])
> λ> :{
> λ| instance Num NonNegativeNumber where
> λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
> λ| :}
>
> :12:25: error:
> • No instance for (Num Q) arising from a use of ‘*’
> • In the expression: x * x'
> In the expression: [x * x' | x <- l, x' <- l']
> In the expression:
> ([x * x' | x <- l, x' <- l'], [y * y' | y <- r, y' <- r'])
> λ>
> λ> zero = ([],Q)
> λ> infty = (Q,[])
> λ> zero * infty
>
> :17:8: error:
> • Couldn't match type ‘Q’ with ‘[a]’
> Expected type: ([a], Q)
> Actual type: (Q, [a0])
> • In the second argument of ‘(*)’, namely ‘infty’
> In the expression: zero * infty
> In an equation for ‘it’: it = zero * infty
> • Relevant bindings include
> it :: ([a], Q) (bound at :17:1)
> λ>
>
>
>> On 2021-08-07, at 15:35, YueCompl via Haskell-Cafe > wrote:
>>
>> Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before.
>>
>> But I need some help to get it going:
>>
>> λ> :set -XTypeSynonymInstances
>> λ> :set -XFlexibleInstances
>> λ>
>> λ> import Data.Ratio
>> λ> type Q = Rational -- this is probably wrong ...
>> λ>
>> λ> type NonNegativeNumber = ([Q],[Q])
>> λ> :{
>> λ| instance Num NonNegativeNumber where
>> λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
>> λ| :}
>>
>> :9:12: warning: [-Wmissing-methods]
>> • No explicit implementation for
>> ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’)
>> • In the instance declaration for ‘Num NonNegativeNumber’
>> λ>
>> λ> zero = ([],Q)
>>
>> :13:13: error: Data constructor not in scope: Q
>> λ> infty = (Q,[])
>>
>> :14:10: error: Data constructor not in scope: Q
>> λ>
>> λ> zero * infty -- expect: = ([],[])
>>
>> :16:1: error: Variable not in scope: zero
>>
>> :16:8: error: Variable not in scope: infty
>> λ>
>>
>> I'd like to do more exercises, but I'm stuck here ...
>>
>>
>>> On 2021-08-07, at 06:16, Olaf Klinke > wrote:
>>>
>>> On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote:
>>>> Thanks Olaf,
>>>>
>>>> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm.
>>>>
>>> Pen-and-paper or GHCi experiments suffice here, no fancy theoretical
>>> background needed. Say Q is the type of rationals 0 < q and we express
>>> type NonNegativeNumber = ([Q],[Q])
>>> where the first (infinite) list is the lower approximants and the
>>> second the upper approximants. Multiplication is then defined as
>>> (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
>>> The extremes of this type are
>>> 0 = ([],Q)
>>> infty = (Q,[])
>>> It is easily seen that
>>> 0 * infty = ([],[])
>>> a number with no lower and no upper approximants, in other words, NaN.
>>> Excercise: Define division for this type and find out what 1/0 and 0/0
>>> is.
>>>
>>>> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it?
>>>>
>>> Yes. I think it is vital that we provide a migration path for
>>> programmers coming from other languages. Under the Dedekind
>>> cut/interval interpretation, NaN would behave differently, as I pointed
>>> out. So I'd leave Float as it is, but be more verbose about its
>>> violation of type class laws. To this end, one could have (and now I
>>> might be closer to your initial question) numerical type classes like
>>> HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only
>>> those types that obey the laws in all elements. Naturally, Float would
>>> not be a member. Who would use these new classes? Probably no one,
>>> because we all like to take the quick and dirty route. But at least it
>>> says clearly: Careful, you can not rely on these laws when using Float.
>>>
>>> Olaf
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 81036 bytes
Desc: not available
URL:
From christopher at conforti.xyz Sat Aug 7 19:18:45 2021
From: christopher at conforti.xyz (Christopher Conforti)
Date: Sat, 7 Aug 2021 15:18:45 -0400
Subject: [Haskell-cafe] Organizing your code files
Message-ID: <20210807151845.6b80d63d@ccc-pc.confortihome.net>
Hi List,
I'm a relatively new Haskeller. I've gotten the syntax of the
language more or less down, and I'm slowly expanding my vocabulary. I've
found in other languages that my coding style and how my code is
organized affect both the quality of my code and how easy it is to
understand.
'Coding style' refers to how code is organized within a block. For
example:
```
foo bar baz bing = x + y * z
```
versus:
```
foo
bar
baz
bing
= x + y * z
```
Code organization refers both to how code is organized within a
source file (i.e., how code blocks are arranged, how they're grouped,
so on) and how source files themselves are organized.
I've got the first part down--I've developed a code style that I'm
satisfied with, I've tried to fine-tune my style to make maximum
effective use of available space (limiting myself to 72 columns, and a
block size of no more than 30 lines) so as to force myself to extract
and abtract away unnecessary details.
The second part is the one I'm having trouble with. There are so many
ways to organize one's code that I don't even know where to begin
developing a method that I like other than to ask other Haskellers how
they do it and why they like doing it that way.
So there you have it: How do you organize your code, and why?
Cheers!
--
Christopher Conforti
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
From olf at aatal-apotheke.de Sat Aug 7 20:54:43 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 07 Aug 2021 22:54:43 +0200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To: <2452CA59-5207-4053-AC59-EFFDD660AC4B@icloud.com>
References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
<7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com>
<7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com>
<671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com>
<2452CA59-5207-4053-AC59-EFFDD660AC4B@icloud.com>
Message-ID:
Dear Compl,
Apologies, my code was meant as math formula in Haskell syntax.
For starters, something like
[x*y | x <- xs, y <- ys]
will not go past the first element of xs if the other list ys is
infinite. Hence you need another way to enumerate an infinite 2-D grid.
I also used the symbol Q as shorthand for "a list that is cofinal in
the set Q" which in case of lower approximants can be [1..] and in the
case of upper approximants can be (fmap recip [1..]).
If you can maintain the invariant that both lists of approximants are
ascending or descending, respecively, then you can replace the above
list comprehension by
zipWith (*) xs ys
which will also be much faster and does the right thing if one list is
empty and the other is infinite.
Further I wouldn't go directly for a full Num instance but define the
arithmetic functions one by one under a different name. That way the
"No explicit implementation for ..." doesn't bite you. Once you have
defined all, the Num instance is just aliasing the Num functions with
your type-specific ones.
For division, you need to think this way: I have a quotient a/b. When I
wobble a or b in either direction, does the quotient get smaller (lower
approximant) or larger (upper approximant)? Clearly, when replacing a
by one of its lower approximants x, then x/b < a/b. (This is only true
because we're excluding negative numbers!) Likewise for upper
approximants to a. Next, if b is replaced by one of its upper
approximants y', then x/y' < x/b < a/b. We conclude that the lower
approximants of a/b are of the form x/y' where x is a lower approximant
of a and y' is an upper approximant of b.
When you're done, you will have implemented exact real arithmetic,
which does not suffer from the rounding errors but is usually also much
slower than floating point arithmetic. And as a by-product you will
have a proof that NaN is the price we must pay for totality of (/) and
(*).
I also attach a chapter from my monograph "Haskell for mathematicians"
which is a literate program containing three different implementations
of exact reals in Haskell, Conway's surreal numbers being one of them,
as well as a more comprehensive surreal numbers implementation.
Olaf
On Sat, 2021-08-07 at 18:21 +0800, YueCompl wrote:
> Okay, I got it working to some extent:
> (and I find it a good showcase for my https://marketplace.visualstudio.com/items?itemName=ComplYue.vscode-ghci extension, improved it a bit to support this very scenario, with the src file at https://github.com/complyue/typing.hs/blob/main/src/PoC/Floating.hs )
>
>
>
> Obviously my naive implementation `(l, r) / (l', r') = ([x / x' | x <- l, x' <- l'], [y / y' | y <- r, y' <- r'])` is wrong, I think I need to figure out how to represent 1 (the unit number) of this type, even before I can come to a correct definition of the division (/) operation, but so far no clue ...
>
> > On 2021-08-07, at 16:16, YueCompl via Haskell-Cafe wrote:
> >
> > Another failed attempt:
> >
> > λ> :set -XTypeSynonymInstances
> > λ> :set -XFlexibleInstances
> > λ>
> > λ> data Q = Q
> > λ>
> > λ> type NonNegativeNumber = ([Q],[Q])
> > λ> :{
> > λ| instance Num NonNegativeNumber where
> > λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
> > λ| :}
> >
> > :12:25: error:
> > • No instance for (Num Q) arising from a use of ‘*’
> > • In the expression: x * x'
> > In the expression: [x * x' | x <- l, x' <- l']
> > In the expression:
> > ([x * x' | x <- l, x' <- l'], [y * y' | y <- r, y' <- r'])
> > λ>
> > λ> zero = ([],Q)
> > λ> infty = (Q,[])
> > λ> zero * infty
> >
> > :17:8: error:
> > • Couldn't match type ‘Q’ with ‘[a]’
> > Expected type: ([a], Q)
> > Actual type: (Q, [a0])
> > • In the second argument of ‘(*)’, namely ‘infty’
> > In the expression: zero * infty
> > In an equation for ‘it’: it = zero * infty
> > • Relevant bindings include
> > it :: ([a], Q) (bound at :17:1)
> > λ>
> >
> >
> > > On 2021-08-07, at 15:35, YueCompl via Haskell-Cafe > wrote:
> > >
> > > Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before.
> > >
> > > But I need some help to get it going:
> > >
> > > λ> :set -XTypeSynonymInstances
> > > λ> :set -XFlexibleInstances
> > > λ>
> > > λ> import Data.Ratio
> > > λ> type Q = Rational -- this is probably wrong ...
> > > λ>
> > > λ> type NonNegativeNumber = ([Q],[Q])
> > > λ> :{
> > > λ| instance Num NonNegativeNumber where
> > > λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
> > > λ| :}
> > >
> > > :9:12: warning: [-Wmissing-methods]
> > > • No explicit implementation for
> > > ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’)
> > > • In the instance declaration for ‘Num NonNegativeNumber’
> > > λ>
> > > λ> zero = ([],Q)
> > >
> > > :13:13: error: Data constructor not in scope: Q
> > > λ> infty = (Q,[])
> > >
> > > :14:10: error: Data constructor not in scope: Q
> > > λ>
> > > λ> zero * infty -- expect: = ([],[])
> > >
> > > :16:1: error: Variable not in scope: zero
> > >
> > > :16:8: error: Variable not in scope: infty
> > > λ>
> > >
> > > I'd like to do more exercises, but I'm stuck here ...
> > >
> > >
> > > > On 2021-08-07, at 06:16, Olaf Klinke > wrote:
> > > >
> > > > On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote:
> > > > > Thanks Olaf,
> > > > >
> > > > > Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm.
> > > > >
> > > > Pen-and-paper or GHCi experiments suffice here, no fancy theoretical
> > > > background needed. Say Q is the type of rationals 0 < q and we express
> > > > type NonNegativeNumber = ([Q],[Q])
> > > > where the first (infinite) list is the lower approximants and the
> > > > second the upper approximants. Multiplication is then defined as
> > > > (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
> > > > The extremes of this type are
> > > > 0 = ([],Q)
> > > > infty = (Q,[])
> > > > It is easily seen that
> > > > 0 * infty = ([],[])
> > > > a number with no lower and no upper approximants, in other words, NaN.
> > > > Excercise: Define division for this type and find out what 1/0 and 0/0
> > > > is.
> > > >
> > > > > Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it?
> > > > >
> > > > Yes. I think it is vital that we provide a migration path for
> > > > programmers coming from other languages. Under the Dedekind
> > > > cut/interval interpretation, NaN would behave differently, as I pointed
> > > > out. So I'd leave Float as it is, but be more verbose about its
> > > > violation of type class laws. To this end, one could have (and now I
> > > > might be closer to your initial question) numerical type classes like
> > > > HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only
> > > > those types that obey the laws in all elements. Naturally, Float would
> > > > not be a member. Who would use these new classes? Probably no one,
> > > > because we all like to take the quick and dirty route. But at least it
> > > > says clearly: Careful, you can not rely on these laws when using Float.
> > > >
> > > > Olaf
> > > >
> > >
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > To (un)subscribe, modify options or view archives go to:
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > Only members subscribed via the mailman list are allowed to post.
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: haskell_for_analysists.lhs
Type: text/x-literate-haskell
Size: 26665 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: surreal.hs
Type: text/x-haskell
Size: 9933 bytes
Desc: not available
URL:
From hecate at glitchbra.in Sun Aug 8 06:50:24 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Sun, 8 Aug 2021 08:50:24 +0200
Subject: [Haskell-cafe] Organizing your code files
In-Reply-To: <20210807151845.6b80d63d@ccc-pc.confortihome.net>
References: <20210807151845.6b80d63d@ccc-pc.confortihome.net>
Message-ID: <89698672-2535-a4d2-c751-e19ebe510d36@glitchbra.in>
Hi Christopher!
On my end, I make use of automated style formatters, so that this kind
of thing can be kept consistent during CI. I invite you not to think too
much about the micro-details of code styles, but rather find a tool that
you can configure so that your style can be enforced automatically.
You'll be able to spend more cycles on programme development.
I can give you an example of a recent library I wrote:
https://github.com/Kleidukos/effectful-contrib/blob/8ae8ad1d76e0c43610619fc04a545dc622bafb88/effectful-cache/src/Data/Cache/Effect.hs#L47-L57
Note that:
* Type variables are made explicit, and as such I annotate even the
simplest of them (with `:: Type`)
* I align the separators (., => and ->)
* I use stylish-haskell & hlint
* If you want finer automated control, try something like Britanny.
Le 07/08/2021 à 21:18, Christopher Conforti a écrit :
> Hi List,
> I'm a relatively new Haskeller. I've gotten the syntax of the
> language more or less down, and I'm slowly expanding my vocabulary. I've
> found in other languages that my coding style and how my code is
> organized affect both the quality of my code and how easy it is to
> understand.
>
> 'Coding style' refers to how code is organized within a block. For
> example:
> ```
> foo bar baz bing = x + y * z
> ```
> versus:
> ```
> foo
> bar
> baz
> bing
> = x + y * z
> ```
>
> Code organization refers both to how code is organized within a
> source file (i.e., how code blocks are arranged, how they're grouped,
> so on) and how source files themselves are organized.
>
> I've got the first part down--I've developed a code style that I'm
> satisfied with, I've tried to fine-tune my style to make maximum
> effective use of available space (limiting myself to 72 columns, and a
> block size of no more than 30 lines) so as to force myself to extract
> and abtract away unnecessary details.
>
> The second part is the one I'm having trouble with. There are so many
> ways to organize one's code that I don't even know where to begin
> developing a method that I like other than to ask other Haskellers how
> they do it and why they like doing it that way.
>
> So there you have it: How do you organize your code, and why?
>
> Cheers!
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mgajda at mimuw.edu.pl Mon Aug 9 10:18:47 2021
From: mgajda at mimuw.edu.pl (Michal J Gajda)
Date: Mon, 9 Aug 2021 12:18:47 +0200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References:
Message-ID:
So we have two things here:
* lossy computation that needs a distance (metric) between points below
epsilon instead of a comparison; in this case we should never ask for exact
equality, but rather ask if a result is within a certain radius from a
result. That means we measure convergence according to a metric, not
equivalence.
```
class Ord m => Metric m a where
dist :: a -> a -> m
a ~= b = dist a b <= epsilon
```
* handling and propagation of different error values.
That would require a rehash of both standard libraries and most
mathematical algebra libraries for Haskell.
For at least two reasons:
* libraries assume a naive equality works for all types. Holds in a world
of infinte precision and lossless operations, but never holds for
approximations.
* our propagation of universal error values is incomplete, and usually
missing from complex algorithms. In other words `Either String` Monad does
not work: we want collections of error values just like we have collections
of inputs.
Personally I will be overjoyed when our community finally gets the better
type class library for approximated types.
Would You agree to review a teaser if I post it here?
—
Cheers
Michał
On Thu, 5 Aug 2021 at 10:41 YueCompl wrote:
> > At some point, Haskell should make provision for decimal floating point,
> > as the current versions of IEEE 754 and C do, and that might be a good
> > reorganisation time.
>
>
> Yeah, I think this is the thing I'm anticipating, current standard classes
> favor lossless computation by the laws, but large portion of the computer
> numeric solutions are taking loss of precision for efficiency. And neural
> systems even right following this approach as far as it appears, I
> sincerely hope Haskell can embrace it to some degree.
>
>
> > On 2021-08-05, at 15:26, Richard O'Keefe wrote:
> >
> > You quoted
> > "> Note that due to the presence of @NaN@, not all elements of 'Float'
> > have an additive inverse."
> >
> > Let x y and z be finite floating-point numbers such that x + y ==> z.
> > Does there always exist neg(y) such that z + neg(y) ==> x?
> > NO.
> >
> > And the presence or absence of NaN in the system makes no difference.
> > If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly.
> > That is, (x + y) - y == 0, but x is not 0.
> >
> > In the presence of rounding, additive inverses do not in general exist.
> > Neither do multiplicative inverses.
> >
> > Also addition and multiplication are not associative, but you knew that.
> > The only reason Float and Double are in Num is because Haskell doesn't
> > offer ad hoc overloading. People have been saying that the Prelude needs
> > refactoring for years.
> >
> > The main thing that NaN wrecks that wasn't already broken is Eq. I would
> > argue that the right decision there would have been to rule that x == y
> > (when x and y are floating point numbers) precisely when x and y are
> > represented by the same bit pattern, with a separate operation for IEEE
> > "ordered and equal".
> >
> > At some point, Haskell should make provision for decimal floating point,
> > as the current versions of IEEE 754 and C do, and that might be a good
> > reorganisation time.
> >
> >
> > On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe
> > wrote:
> >>
> >> Thanks Michał,
> >>
> >> I feel less confused as I realized the non-halting possibility per
> bottoms, from your hint.
> >>
> >> I too think the signaling NaN is dreadful enough, so fortunately it's
> rarely seen nowadays.
> >>
> >> Actually what's on my mind was roughly something like "Maybe on
> steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws,
> as seen at
> https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
> >>
> >>> Note that due to the presence of @NaN@, not all elements of 'Float'
> have an additive inverse.
> >>
> >>> Also note that due to the presence of -0, Float's 'Num' instance
> doesn't have an additive identity
> >>
> >>> Note that due to the presence of @NaN@, not all elements of 'Float'
> have an multiplicative inverse.
> >>
> >> So it should have been another family of `Num` classes, within which,
> various NaN related semantics can be legal, amongst which I'd think:
> >>
> >> * Silent propagation of NaN in arithmetics, like `Maybe` monad does,
> seems quite acceptable
> >> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground
> or not?
> >> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's
> a theoretical framework for this to hold? Maybe `Boolean` type needs
> enhancement too to do it?
> >>
> >> No such family of `Num` classes exists to my aware by now, I just can't
> help wondering why.
> >>
> >> Cheers,
> >> Compl
> >>
> >> On 2021-08-04, at 02:38, Michał J Gajda wrote:
> >>
> >> Dear Yue,
> >>
> >> Bottom has much weaker semantics than an exception: it means You may
> never get a result and thus will never handle it!
> >>
> >> Another reason is convenience: it is frequently the case that giving
> NaN in a row of numbers is much more informative than crashing a program
> with an exception and never printing the result anyway.
> >>
> >> Finally IEEE special values have clear propagation semantics: they are
> basically Maybe on steroids.
> >>
> >> The problem with this approach is indeed a silent handling.
> >>
> >> But in order to fix this, it is better to add preconditions to specific
> algorithms that do not allow IEEE special value on input (`isFinite` or
> `isNotNaN`) and then track the origin of the special value with the methods
> like those described here:
> https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
> >>
> >> Never throw an error without telling exactly why it happened and
> exactly where to fix it :-). Using bottom is last resort; exceptions
> likewise.
> >> --
> >> Cheers
> >> Michał
> >>
> >>
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> To (un)subscribe, modify options or view archives go to:
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >> Only members subscribed via the mailman list are allowed to post.
>
> --
Pozdrawiam
Michał
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From compl.yue at icloud.com Mon Aug 9 11:36:56 2021
From: compl.yue at icloud.com (YueCompl)
Date: Mon, 9 Aug 2021 19:36:56 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References:
Message-ID: <7931FC1B-BEED-4B9A-9857-4C24DF2D5B17@icloud.com>
Dear Michał,
I suppose by "You" you mean more people in this list those are more capable and have greater wisdom in this topic, I don't think myself a qualified Haskeller yet, but I can't help thinking about it.
I especially wonder at this moment, if more proper & prevalent handling of metric errors can lead to new discoveries in neural programming (more principled training of neural networks? synthetic samples & labels beyond mere data acquisition?) I have strong feel that Haskell shall really shine in modeling or trialing related ideas, compared to other languages and tools.
Can't speak for others but I quite anticipate your teaser, even though I may not fully understand it with my limited expertise in this area.
Best regards,
Compl
> On 2021-08-09, at 18:18, Michal J Gajda wrote:
>
> So we have two things here:
>
> * lossy computation that needs a distance (metric) between points below epsilon instead of a comparison; in this case we should never ask for exact equality, but rather ask if a result is within a certain radius from a result. That means we measure convergence according to a metric, not equivalence.
>
>
> ```
> class Ord m => Metric m a where
> dist :: a -> a -> m
>
> a ~= b = dist a b <= epsilon
> ```
>
> * handling and propagation of different error values.
>
> That would require a rehash of both standard libraries and most mathematical algebra libraries for Haskell.
>
> For at least two reasons:
>
> * libraries assume a naive equality works for all types. Holds in a world of infinte precision and lossless operations, but never holds for approximations.
>
> * our propagation of universal error values is incomplete, and usually missing from complex algorithms. In other words `Either String` Monad does not work: we want collections of error values just like we have collections of inputs.
>
> Personally I will be overjoyed when our community finally gets the better type class library for approximated types.
>
> Would You agree to review a teaser if I post it here?
> —
> Cheers
> Michał
>
> On Thu, 5 Aug 2021 at 10:41 YueCompl > wrote:
> > At some point, Haskell should make provision for decimal floating point,
> > as the current versions of IEEE 754 and C do, and that might be a good
> > reorganisation time.
>
>
> Yeah, I think this is the thing I'm anticipating, current standard classes favor lossless computation by the laws, but large portion of the computer numeric solutions are taking loss of precision for efficiency. And neural systems even right following this approach as far as it appears, I sincerely hope Haskell can embrace it to some degree.
>
>
> > On 2021-08-05, at 15:26, Richard O'Keefe > wrote:
> >
> > You quoted
> > "> Note that due to the presence of @NaN@, not all elements of 'Float'
> > have an additive inverse."
> >
> > Let x y and z be finite floating-point numbers such that x + y ==> z.
> > Does there always exist neg(y) such that z + neg(y) ==> x?
> > NO.
> >
> > And the presence or absence of NaN in the system makes no difference.
> > If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly.
> > That is, (x + y) - y == 0, but x is not 0.
> >
> > In the presence of rounding, additive inverses do not in general exist.
> > Neither do multiplicative inverses.
> >
> > Also addition and multiplication are not associative, but you knew that.
> > The only reason Float and Double are in Num is because Haskell doesn't
> > offer ad hoc overloading. People have been saying that the Prelude needs
> > refactoring for years.
> >
> > The main thing that NaN wrecks that wasn't already broken is Eq. I would
> > argue that the right decision there would have been to rule that x == y
> > (when x and y are floating point numbers) precisely when x and y are
> > represented by the same bit pattern, with a separate operation for IEEE
> > "ordered and equal".
> >
> > At some point, Haskell should make provision for decimal floating point,
> > as the current versions of IEEE 754 and C do, and that might be a good
> > reorganisation time.
> >
> >
> > On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe
> > > wrote:
> >>
> >> Thanks Michał,
> >>
> >> I feel less confused as I realized the non-halting possibility per bottoms, from your hint.
> >>
> >> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.
> >>
> >> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs
> >>
> >>> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.
> >>
> >>> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity
> >>
> >>> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.
> >>
> >> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:
> >>
> >> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
> >> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
> >> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?
> >>
> >> No such family of `Num` classes exists to my aware by now, I just can't help wondering why.
> >>
> >> Cheers,
> >> Compl
> >>
> >> On 2021-08-04, at 02:38, Michał J Gajda > wrote:
> >>
> >> Dear Yue,
> >>
> >> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!
> >>
> >> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway.
> >>
> >> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.
> >>
> >> The problem with this approach is indeed a silent handling.
> >>
> >> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding
> >>
> >> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.
> >> --
> >> Cheers
> >> Michał
> >>
> >>
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> To (un)subscribe, modify options or view archives go to:
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >> Only members subscribed via the mailman list are allowed to post.
>
> --
> Pozdrawiam
> Michał
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From compl.yue at icloud.com Mon Aug 9 11:51:36 2021
From: compl.yue at icloud.com (YueCompl)
Date: Mon, 9 Aug 2021 19:51:36 +0800
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
In-Reply-To:
References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de>
<7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com>
<7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com>
<671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com>
<2452CA59-5207-4053-AC59-EFFDD660AC4B@icloud.com>
Message-ID: <7B8A977D-C496-4AAE-992C-84FB714C921F@icloud.com>
Thanks Olaf,
The surreal implementation should help a lot for me to understand the ideas deep enough.
I developed the habit to understand things by tweaking code one little bit a time, and see the differences I made, to get intuitions about how it works, that's due to my career as a software engineer / hacker I guess.
I already felt the difference with Haskell in software engineering practices, than with other programming communities, and I'm quite happy that I can enjoy the beauty of math here, though I'm some slow in understanding things mathematically. I think I just need more time :-)
Best regards,
Compl
> On 2021-08-08, at 04:54, Olaf Klinke wrote:
>
> Dear Compl,
>
> Apologies, my code was meant as math formula in Haskell syntax.
> For starters, something like
> [x*y | x <- xs, y <- ys]
> will not go past the first element of xs if the other list ys is
> infinite. Hence you need another way to enumerate an infinite 2-D grid.
> I also used the symbol Q as shorthand for "a list that is cofinal in
> the set Q" which in case of lower approximants can be [1..] and in the
> case of upper approximants can be (fmap recip [1..]).
> If you can maintain the invariant that both lists of approximants are
> ascending or descending, respecively, then you can replace the above
> list comprehension by
> zipWith (*) xs ys
> which will also be much faster and does the right thing if one list is
> empty and the other is infinite.
>
> Further I wouldn't go directly for a full Num instance but define the
> arithmetic functions one by one under a different name. That way the
> "No explicit implementation for ..." doesn't bite you. Once you have
> defined all, the Num instance is just aliasing the Num functions with
> your type-specific ones.
>
> For division, you need to think this way: I have a quotient a/b. When I
> wobble a or b in either direction, does the quotient get smaller (lower
> approximant) or larger (upper approximant)? Clearly, when replacing a
> by one of its lower approximants x, then x/b < a/b. (This is only true
> because we're excluding negative numbers!) Likewise for upper
> approximants to a. Next, if b is replaced by one of its upper
> approximants y', then x/y' < x/b < a/b. We conclude that the lower
> approximants of a/b are of the form x/y' where x is a lower approximant
> of a and y' is an upper approximant of b.
>
> When you're done, you will have implemented exact real arithmetic,
> which does not suffer from the rounding errors but is usually also much
> slower than floating point arithmetic. And as a by-product you will
> have a proof that NaN is the price we must pay for totality of (/) and
> (*).
>
> I also attach a chapter from my monograph "Haskell for mathematicians"
> which is a literate program containing three different implementations
> of exact reals in Haskell, Conway's surreal numbers being one of them,
> as well as a more comprehensive surreal numbers implementation.
>
> Olaf
>
> On Sat, 2021-08-07 at 18:21 +0800, YueCompl wrote:
>> Okay, I got it working to some extent:
>> (and I find it a good showcase for my https://marketplace.visualstudio.com/items?itemName=ComplYue.vscode-ghci extension, improved it a bit to support this very scenario, with the src file at https://github.com/complyue/typing.hs/blob/main/src/PoC/Floating.hs )
>>
>>
>>
>> Obviously my naive implementation `(l, r) / (l', r') = ([x / x' | x <- l, x' <- l'], [y / y' | y <- r, y' <- r'])` is wrong, I think I need to figure out how to represent 1 (the unit number) of this type, even before I can come to a correct definition of the division (/) operation, but so far no clue ...
>>
>>> On 2021-08-07, at 16:16, YueCompl via Haskell-Cafe wrote:
>>>
>>> Another failed attempt:
>>>
>>> λ> :set -XTypeSynonymInstances
>>> λ> :set -XFlexibleInstances
>>> λ>
>>> λ> data Q = Q
>>> λ>
>>> λ> type NonNegativeNumber = ([Q],[Q])
>>> λ> :{
>>> λ| instance Num NonNegativeNumber where
>>> λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
>>> λ| :}
>>>
>>> :12:25: error:
>>> • No instance for (Num Q) arising from a use of ‘*’
>>> • In the expression: x * x'
>>> In the expression: [x * x' | x <- l, x' <- l']
>>> In the expression:
>>> ([x * x' | x <- l, x' <- l'], [y * y' | y <- r, y' <- r'])
>>> λ>
>>> λ> zero = ([],Q)
>>> λ> infty = (Q,[])
>>> λ> zero * infty
>>>
>>> :17:8: error:
>>> • Couldn't match type ‘Q’ with ‘[a]’
>>> Expected type: ([a], Q)
>>> Actual type: (Q, [a0])
>>> • In the second argument of ‘(*)’, namely ‘infty’
>>> In the expression: zero * infty
>>> In an equation for ‘it’: it = zero * infty
>>> • Relevant bindings include
>>> it :: ([a], Q) (bound at :17:1)
>>> λ>
>>>
>>>
>>>> On 2021-08-07, at 15:35, YueCompl via Haskell-Cafe > wrote:
>>>>
>>>> Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before.
>>>>
>>>> But I need some help to get it going:
>>>>
>>>> λ> :set -XTypeSynonymInstances
>>>> λ> :set -XFlexibleInstances
>>>> λ>
>>>> λ> import Data.Ratio
>>>> λ> type Q = Rational -- this is probably wrong ...
>>>> λ>
>>>> λ> type NonNegativeNumber = ([Q],[Q])
>>>> λ> :{
>>>> λ| instance Num NonNegativeNumber where
>>>> λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
>>>> λ| :}
>>>>
>>>> :9:12: warning: [-Wmissing-methods]
>>>> • No explicit implementation for
>>>> ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’)
>>>> • In the instance declaration for ‘Num NonNegativeNumber’
>>>> λ>
>>>> λ> zero = ([],Q)
>>>>
>>>> :13:13: error: Data constructor not in scope: Q
>>>> λ> infty = (Q,[])
>>>>
>>>> :14:10: error: Data constructor not in scope: Q
>>>> λ>
>>>> λ> zero * infty -- expect: = ([],[])
>>>>
>>>> :16:1: error: Variable not in scope: zero
>>>>
>>>> :16:8: error: Variable not in scope: infty
>>>> λ>
>>>>
>>>> I'd like to do more exercises, but I'm stuck here ...
>>>>
>>>>
>>>>> On 2021-08-07, at 06:16, Olaf Klinke > wrote:
>>>>>
>>>>> On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote:
>>>>>> Thanks Olaf,
>>>>>>
>>>>>> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm.
>>>>>>
>>>>> Pen-and-paper or GHCi experiments suffice here, no fancy theoretical
>>>>> background needed. Say Q is the type of rationals 0 < q and we express
>>>>> type NonNegativeNumber = ([Q],[Q])
>>>>> where the first (infinite) list is the lower approximants and the
>>>>> second the upper approximants. Multiplication is then defined as
>>>>> (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r'])
>>>>> The extremes of this type are
>>>>> 0 = ([],Q)
>>>>> infty = (Q,[])
>>>>> It is easily seen that
>>>>> 0 * infty = ([],[])
>>>>> a number with no lower and no upper approximants, in other words, NaN.
>>>>> Excercise: Define division for this type and find out what 1/0 and 0/0
>>>>> is.
>>>>>
>>>>>> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it?
>>>>>>
>>>>> Yes. I think it is vital that we provide a migration path for
>>>>> programmers coming from other languages. Under the Dedekind
>>>>> cut/interval interpretation, NaN would behave differently, as I pointed
>>>>> out. So I'd leave Float as it is, but be more verbose about its
>>>>> violation of type class laws. To this end, one could have (and now I
>>>>> might be closer to your initial question) numerical type classes like
>>>>> HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only
>>>>> those types that obey the laws in all elements. Naturally, Float would
>>>>> not be a member. Who would use these new classes? Probably no one,
>>>>> because we all like to take the quick and dirty route. But at least it
>>>>> says clearly: Careful, you can not rely on these laws when using Float.
>>>>>
>>>>> Olaf
>>>>>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>
>
From olf at aatal-apotheke.de Mon Aug 9 21:59:58 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Mon, 09 Aug 2021 23:59:58 +0200
Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs
as some handleable bottom?
Message-ID: <4371a0a10fc612ece9a8b73ba2ed26e321487bac.camel@aatal-apotheke.de>
> * libraries assume a naive equality works for all types. Holds in a world
> of infinte precision and lossless operations, but never holds for
> approximations.
>
> * our propagation of universal error values is incomplete, and usually
> missing from complex algorithms. In other words `Either String` Monad does
> not work: we want collections of error values just like we have collections
> of inputs.
>
> Personally I will be overjoyed when our community finally gets the better
> type class library for approximated types.
>
> Would You agree to review a teaser if I post it here?
Yes, please.
I'm curious whether there is a single abstraction that can describe
both finite precision with variable errors as well as potentially
infinite precision with known errors.
Olaf
From johannes.waldmann at htwk-leipzig.de Tue Aug 10 14:32:27 2021
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 10 Aug 2021 16:32:27 +0200
Subject: [Haskell-cafe] Organizing your code files
Message-ID:
Hécate:
> * Type variables are made explicit, and as such I annotate even the
> simplest of them (with `:: Type`)
This! I am moving towards that style.
Especially in teaching (type abstraction, type application)
where I want everything to be very much explicit -
before discussing abbreviations and omissions (type inference).
With current GHC, this is entirely possible but looks somewhat clumsy
{-# language ExplicitForall, KindSignatures #-}
import Data.Kind (Type)
g :: forall (t :: Type) . t -> t ; g x = x
{-# language TypeApplications #-} g @N Z
yes I could hide these pragmas somewhere but that again feels wrong.
But - good thing: after
https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst
(I understand that GHC2021 is default-enabled in GHC-9.2)
we no longer need to write these pragmas. Yay!
Sadly, we still need the import.
- J.
NB: Haskell's implicit declaration of type variables
by their starting with lowercase letters
always reminds me of Fortran's implicit type specification
for variables, going by the first letter (I .. N means integer).
Fortran has "implicit none" though, so let's have "t :: Type"...
From benjamin.redelings at gmail.com Tue Aug 10 15:57:15 2021
From: benjamin.redelings at gmail.com (Benjamin Redelings)
Date: Tue, 10 Aug 2021 11:57:15 -0400
Subject: [Haskell-cafe] Help on syntactic sugar for combining lazy &
strict monads?
In-Reply-To:
References:
Message-ID: <379f9543-ac04-a459-ddb1-cec1732d22d5@gmail.com>
Hi Olaf,
If you recall, I actually wrote to this list asking for help. Adam
Scibior's response was quite helpful, but this conversation, as far as I
can tell, has not provided any help, so I will regretfully have to stop
replying at some point. Unfortunately, I don't have enough time to
respond to everything - my apologies!
I may be able to clarify some of the questions that you asked. But I
doubt that I can actually satisfy all of your concerns. So, perhaps
these responses will mostly clarify our points of disagreement.
1. It seems like you are assuming that the semantics of a probabilistic
program is determined by running it under a rejection sampling
interpreter. Such an interpreter would:
(a) interpret statements like "x <- normal 0 1" by performing a
(pseudo)random sample from the distribution
(b) interpret statements like "2.0 `observed_from` normal z 1`" by
first sampling from "normal z 1" and then rejecting the program run if
the sample from "normal z 1" does not satisfy (2.0==).
That is a rejection sampler, and it would work if the observations did
not have probability 0. But it is only one kind of sampler. There are
other kinds of samplers, that you (maybe?) have not considered:
* importance sampling: the paper that I recommended is using the
observation statements to weight the samples by the probability DENSITY
of the observations. This is called "importance sampling" -- we
generate sampling from one distribution, but reweight them to
approximate a different distribution.
* MCMC: my approach is based on MCMC, and so performs a random walk
over the space of program traces. In this case, running the program
must compute the probability DENSITY of samples from the prior (like "x
<- normal 0 1") as well as observations (like observing 2.0 from "normal
z 1").
These three alternative interpreters are alternative ways of sampling
from the posterior distribution. However, none of these three
interpreters constitutes the semantics of the probabilistic program.
I mentioned the Giry monad (which I am no expert on) because it gives
semantics that is not based on any interpreter. I do not think that the
semantics of probabilistic programs should be given by an interpreter.
Perhaps we disagree on this.
2. You wrote "If the observe_from statement is never demanded, then what
semantics should it have?"
> run_lazy $ do
> x <- normal 0 1
> y <- normal x 1
> z <- normal y 1
> 2.0 `observe_from` normal z 1
> return y
The semantics that it should have seems fairly obvious?
This program leads to the following (un-normalized!) probability density
on (x,y,z):
Pr(x) * Pr(y|x) * Pr(z|y) * Pr(2.0|z) = normal_pdf(x,0,1) *
normal_pdf(y,x,1) * normal_pdf(z,y,1) * normal_pdf(2.0,z,1)
Therefore, the program leads to both (i) a distribution on (x,y,z) and
(ii) a distribution on the return value y.
I don't think this has anything to to with whether there is a result
that is demanded, but perhaps we disagree on that.
3. You wrote "But conditioning usually is a function "Observation a ->
Dist a -> Dist a" so you must use the result of the conditioning somehow."
I was initially very confused by this, because it sounded like you are
saying that because people USUALLY do something, therefore I HAVE AN
OBLIGATION to do something. But, now I realize that you mean "IT MUST
BE THE CASE that you use the result of the conditioning somehow". It is
indeed the case that the "observe_from" command affects the intepreter
somehow.
I think this is pretty simple ... the `observe_from` statement has a
side-effect. For both (i) importance-sampling interpreters and (ii)
MCMC interpreters, the side-effect is to weight the current trace by the
probability (or probability density) of the observation.
However, like the "put" command in the state monad, the result "()" of
the observation is not demanded. So in that sense, I am not "using the
result". It is perhaps interesting that the lazy state monad does not
have the problem that "put" commands are ignored.
4. You wrote "And isn't the principle of Monte Carlo to approximate the
posterior by sampling from it?"
I am not really sure what this means. Sometimes you can generate
samples directly from the posterior, and sometimes you can't. In most
situations where you have observations, you CANNOT generate samples from
the posterior.
For example, in MCMC, we talk about the distribution of the sampled
points CONVERGING to the posterior. If an MCMC chain has points X[t]
for t = 0...\infty, there is no t where X[t] is distributed according to
the posterior distribution.
5. You wrote "I claim that once you have typed everything, it becomes
clear where the problem is."
That is an interesting claim. I don't think that there is actually
"problem" per se, so I am not were that typing everything can reveal
where it is. Also, this exact same issue comes up in the Practical
Probabilistic Programming with Monads paper, and they have typed
everything. So, I guess I disbelieve this claim, until I see evidence
to the contrary.
I guess we will see, after I finish programming the type system.
6. You wrote:
> I believe I understand the Giry monad well, and it is my measuring
> stick for functional probabilistic programming. Even more well-suited
> for programming ought to be the valuation monad, because that is a
> monad on domains, the [*] semantic spaces of the lambda calculus.
> Unfortunately, to my knowledge until now attempts were unsuccessful to
> find a cartesian closed category of domains which is also closed under
> this probabilistic powerdomain construction.
>
> [*] There are of course other semantics, domains being one option.
Given your expertise in this area, I doubt that I can shed any light on
this. I presume that you have read
https://arxiv.org/pdf/1811.04196.pdf, and similar papers. This is
getting pretty far afield from my original question.
7. You wrote:
>>
>> 2. The paper "Practical Probabilistic Programming with Monads" -
>> https://doi.org/10.1145/2804302.2804317
>
> Wasn't that what you linked to in your original post? As said above,
> measure spaces is the wrong target category, in my opinion. There is
> too much non constructive stuff in there. See the work of Culbertson
> and Sturtz, which is categorically nice but not very constructive.
The link was indeed in my original post, but it did not seem like you
had read it, since you did not consider the possibility of probabilistic
programs generating WEIGHTED samples.
Also, the idea that probabilistic programs should not yield measures
seems weird. Partly because I am not sure what your alternative is, and
partly because everybody else seems to disagree with you. For example,
the following paper assumes measures:
https://link.springer.com/chapter/10.1007/978-3-030-72019-3_16
Again, this is getting pretty far away from my original question.
8. You wrote:
> Perhaps I am being too much of a point-free topologist here. Call me
> pedantic. Or I don't understand sampling at all. To me, a point is an
> idealised object, only open sets really exist and are observable. If
> the space is discrete, points are open sets. But on the real line you
> can not measure with infinite precision, so any observation must
> contain an interval. That aligns very nicely with functional
> programming, where only finite parts of infinite lazy structures are
> ever observable, and these finite parts are the open sets in the
> domain semantics. So please explain how observing 2.0 from a
> continuous distribution is not nonsensical.
You haven't actually shown that observing 2.0 from a continuous
distribution is nonsensical. What you have done is stated that you
don't like it, and that you would like people to represent observations
as intervals instead of points. However, its not my job to convince you
that point observations make sense, so I think I'll just leave that
where it is.
OK, that's enough for now.
-BenRI
On 7/22/21 2:15 AM, Olaf Klinke wrote:
>> However, a lazy interpreter causes problems when trying to introduce
>> *observation* statements (aka conditioning statements) into the monad
>> [3]. For example,
>>
>> run_lazy $ do
>> x <- normal 0 1
>> y <- normal x 1
>> z <- normal y 1
>> 2.0 `observe_from` normal z 1
>> return y
>>
>> In the above code fragment, y will be forced because it is returned, and
>> y will force x. However, the "observe_from" statement will never be
>> forced, because it does not produce a result that is demanded.
>
> I'm very confused. If the observe_from statement is never demanded,
> then what semantics should it have? What is the type of observe_from?
> It seems it is
> a -> m a -> m ()
> for whatever monad m you are using. But conditioning usually is a
> function
> Observation a -> Dist a -> Dist a
> so you must use the result of the conditioning somehow. And isn't the
> principle of Monte Carlo to approximate the posterior by sampling from
> it? I tend to agree with your suggestion that observations and
> sampling can not be mixed (in the same do-notation) but the latter
> have to be collected in a prior, then conditioned by an observation.
>
> What is the semantic connection between your sample and obsersvation
> monad? What is the connection between both and the semantic
> probability distributions? I claim that once you have typed
> everything, it becomes clear where the problem is.
>
> Olaf
>
> P.S. It has always bugged me that probabilists use elements and events
> interchangingly, while this can only be done on discrete spaces. So
> above I would rather like to write
> (2.0==) `observe_from` (normal 0 1)
> which still is a non-sensical statement if (normal 0 1) is a
> continuous distribution where each point set has probability zero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonathan.protzenko at gmail.com Wed Aug 11 21:14:02 2021
From: jonathan.protzenko at gmail.com (Jonathan Protzenko)
Date: Wed, 11 Aug 2021 14:14:02 -0700
Subject: [Haskell-cafe] Call for participation: ML Family Workshop 2021
Message-ID: