From ekmett at gmail.com Sun Feb 3 18:17:56 2019 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 3 Feb 2019 13:17:56 -0500 Subject: New Core Libraries Committee members Message-ID: I would like to formally welcome the following new and returning members to the Core Libraries Committee: Eric Mertens (returning) George Wilson Herbert Valerio Riedel Carter Schonwald Daniel Cartwright They will be joining myself, Neil Mitchell, Andrew Thaddeus Martin and Ryan GL Scott on the committee. I would like to thank everyone who applied, and our departing, and existing committee members. In particular, I'd like to thank Michael Snoyman for all of his efforts in helping to shepherd this committee through its formative years. Without the procedures and systems he helped put in place, we would be far worse off. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Feb 4 00:35:14 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 3 Feb 2019 19:35:14 -0500 Subject: Order of constructors in Data.Map.Internal In-Reply-To: References: Message-ID: This is about first run branch prediction on cpus and how constructor order can influence code gen of case expressions. This is more Andreask’S wheelhouse rather than David’s. In fact Andreas has some work to make things like this easier to do in progress. Johan did some super detailed benchmarking when he did this and other work. Perhaps he can share with you more about how he did it. I ccd him on this email. On Mon, Jan 28, 2019 at 4:44 PM chessai . wrote: > When looking through the source of Data.Map.Internal, there's a note: > > -- [Note: Order of constructors] > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- The order of constructors of Map matters when considering performance. > -- Currently in GHC 7.0, when type has 2 constructors, a forward > conditional > -- jump is made when successfully matching second constructor. Successful > match > -- of first constructor results in the forward jump not taken. > -- On GHC 7.0, reordering constructors from Tip | Bin to Bin | Tip > -- improves the benchmark by up to 10% on x86. > > I've been curious about this for a while now. GHC 7.0 was released > quite a long time ago, so I wonder if this is still the case? David > might know. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Mon Feb 4 00:39:45 2019 From: chessai1996 at gmail.com (chessai .) Date: Sun, 3 Feb 2019 19:39:45 -0500 Subject: Order of constructors in Data.Map.Internal In-Reply-To: References: Message-ID: Awesome, thanks. On Sun, Feb 3, 2019, 7:35 PM Carter Schonwald This is about first run branch prediction on cpus and how constructor > order can influence code gen of case expressions. > > This is more Andreask’S wheelhouse rather than David’s. In fact Andreas > has some work to make things like this easier to do in progress. > > Johan did some super detailed benchmarking when he did this and other > work. Perhaps he can share with you more about how he did it. I ccd him on > this email. > > On Mon, Jan 28, 2019 at 4:44 PM chessai . wrote: > >> When looking through the source of Data.Map.Internal, there's a note: >> >> -- [Note: Order of constructors] >> -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> -- The order of constructors of Map matters when considering performance. >> -- Currently in GHC 7.0, when type has 2 constructors, a forward >> conditional >> -- jump is made when successfully matching second constructor. Successful >> match >> -- of first constructor results in the forward jump not taken. >> -- On GHC 7.0, reordering constructors from Tip | Bin to Bin | Tip >> -- improves the benchmark by up to 10% on x86. >> >> I've been curious about this for a while now. GHC 7.0 was released >> quite a long time ago, so I wonder if this is still the case? David >> might know. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Feb 4 01:08:38 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 3 Feb 2019 20:08:38 -0500 Subject: Order of constructors in Data.Map.Internal In-Reply-To: References: Message-ID: I would like to also emphasize that doing robust measurement for these things is super subtle. There’s all sorts of cpu micro architecture things you possibly need to account for , plus sometimes tools like perf and dtrace apparently have “skids” where there’s hard to avoid attribution/measurement errors in an instruction stream. Or I’m totally out of date and wrong. Or both On Sun, Feb 3, 2019 at 7:39 PM chessai . wrote: > Awesome, thanks. > > On Sun, Feb 3, 2019, 7:35 PM Carter Schonwald wrote: > >> This is about first run branch prediction on cpus and how constructor >> order can influence code gen of case expressions. >> >> This is more Andreask’S wheelhouse rather than David’s. In fact Andreas >> has some work to make things like this easier to do in progress. >> >> Johan did some super detailed benchmarking when he did this and other >> work. Perhaps he can share with you more about how he did it. I ccd him on >> this email. >> >> On Mon, Jan 28, 2019 at 4:44 PM chessai . wrote: >> >>> When looking through the source of Data.Map.Internal, there's a note: >>> >>> -- [Note: Order of constructors] >>> -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> -- The order of constructors of Map matters when considering performance. >>> -- Currently in GHC 7.0, when type has 2 constructors, a forward >>> conditional >>> -- jump is made when successfully matching second constructor. >>> Successful match >>> -- of first constructor results in the forward jump not taken. >>> -- On GHC 7.0, reordering constructors from Tip | Bin to Bin | Tip >>> -- improves the benchmark by up to 10% on x86. >>> >>> I've been curious about this for a while now. GHC 7.0 was released >>> quite a long time ago, so I wonder if this is still the case? David >>> might know. >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Wed Feb 6 19:29:18 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Wed, 6 Feb 2019 14:29:18 -0500 Subject: Peeking into StgInfoTable in cmm Message-ID: <45059A3F-1DBA-4362-9336-74C79FC0CAF9@gmail.com> For an optimization I’m implementing, I’m trying to write an inline primop that gives me lets me inspect the closure type of an arbitrary heap-allocated value. I’m close to figuring this out, and the FCode machinery is starting to make sense, but one thing eludes me. Starting from a StgHeader, I get the info table pointer. This is easy since it’s the first field in the struct. But next I have to deference the info table pointer and get the closure type. There are two fields at the beginning of an info table that may or may not be present. I don’t know how to figure out if they are present or not. I suspect that there is something I can get out of DynFlags that tells me this, but I can’t find anything else in the stg-to-cmm pass that reads from an info table. Sent from my iPhone From matthewtpickering at gmail.com Wed Feb 6 19:54:24 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 6 Feb 2019 19:54:24 +0000 Subject: Peeking into StgInfoTable in cmm In-Reply-To: <45059A3F-1DBA-4362-9336-74C79FC0CAF9@gmail.com> References: <45059A3F-1DBA-4362-9336-74C79FC0CAF9@gmail.com> Message-ID: Unless I am misunderstanding you want something which works like ghc-heap. If so, perhaps these three files will be instructive? https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTable.hsc https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTableProf.hsc https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/Closures.hs#L25 Cheers, Matt On Wed, Feb 6, 2019 at 7:29 PM Andrew Martin wrote: > > For an optimization I’m implementing, I’m trying to write an inline primop that gives me lets me inspect the closure type of an arbitrary heap-allocated value. I’m close to figuring this out, and the FCode machinery is starting to make sense, but one thing eludes me. Starting from a StgHeader, I get the info table pointer. This is easy since it’s the first field in the struct. But next I have to deference the info table pointer and get the closure type. There are two fields at the beginning of an info table that may or may not be present. I don’t know how to figure out if they are present or not. I suspect that there is something I can get out of DynFlags that tells me this, but I can’t find anything else in the stg-to-cmm pass that reads from an info table. > > Sent from my iPhone > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From chessai1996 at gmail.com Wed Feb 6 20:43:06 2019 From: chessai1996 at gmail.com (chessai .) Date: Wed, 6 Feb 2019 15:43:06 -0500 Subject: Add Ord Laws to next Haskell Report Message-ID: Per GHC.Classes (haddock-viewable from Data.Ord) "The Haskell Report defines no laws for Ord. However, <= is customarily expected to implement a non-strict partial order and have the following properties:" I propose that in the next report that the expected typeclass laws for Ord be added. They're generally agreed upon/understood. From andrew.thaddeus at gmail.com Wed Feb 6 20:49:51 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Wed, 6 Feb 2019 15:49:51 -0500 Subject: Peeking into StgInfoTable in cmm In-Reply-To: References: <45059A3F-1DBA-4362-9336-74C79FC0CAF9@gmail.com> Message-ID: Thanks. The source code of ghc-heap has led me to what I was looking for. That whole library hinges upon unpackClosure# (stg_unpackClosurezh), whose implementation opens with the telling: info = %GET_STD_INFO(UNTAG(closure)); In CmmParse.y, we find the implementation of GET_STD_INFO, and just a few lines below is the INFO_TYPE macro. The combination of these (along with a cmm implementation of UNTAG, which I am still unsure of exactly how to accomplish) should do the trick. On Wed, Feb 6, 2019 at 2:53 PM Matthew Pickering < matthewtpickering at gmail.com> wrote: > Unless I am misunderstanding you want something which works like ghc-heap. > > If so, perhaps these three files will be instructive? > > > https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTable.hsc > > https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTableProf.hsc > > https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/Closures.hs#L25 > > Cheers, > > Matt > > On Wed, Feb 6, 2019 at 7:29 PM Andrew Martin > wrote: > > > > For an optimization I’m implementing, I’m trying to write an inline > primop that gives me lets me inspect the closure type of an arbitrary > heap-allocated value. I’m close to figuring this out, and the FCode > machinery is starting to make sense, but one thing eludes me. Starting from > a StgHeader, I get the info table pointer. This is easy since it’s the > first field in the struct. But next I have to deference the info table > pointer and get the closure type. There are two fields at the beginning of > an info table that may or may not be present. I don’t know how to figure > out if they are present or not. I suspect that there is something I can get > out of DynFlags that tells me this, but I can’t find anything else in the > stg-to-cmm pass that reads from an info table. > > > > Sent from my iPhone > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Feb 6 20:52:44 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 6 Feb 2019 21:52:44 +0100 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: On Wed, Feb 6, 2019 at 9:43 PM chessai . wrote: > Per GHC.Classes (haddock-viewable from Data.Ord) > > "The Haskell Report defines no laws for Ord. However, <= is > customarily expected to implement a non-strict partial order and have > the following properties:" > > I propose that in the next report that the expected typeclass laws for > Ord be added. They're generally agreed upon/understood. > Can you spell out the concrete change to the report wording you're suggesting? For reference, the current wording used in the 2010 Haskell Report is quoted below. While at it, you might also want to take into account the `Eq` class definition in the report. 6.3.2 The Ord Class class (Eq a) => Ord a where compare :: a -> a -> Ordering (<), (<=), (>=), (>) :: a -> a -> Bool max, min :: a -> a -> a compare x y | x == y = EQ | x <= y = LT | otherwise = GT x <= y = compare x y /= GT x < y = compare x y == LT x >= y = compare x y /= LT x > y = compare x y == GT -- Note that (min x y, max x y) = (x,y) or (y,x) max x y | x <= y = y | otherwise = x min x y | x <= y = x | otherwise = y The Ord class is used for totally ordered datatypes. All basic datatypes except for functions, IO, and IOError, are instances of this class. Instances of Ord can be derived for any user-defined datatype whose constituent types are in Ord. The declared order of the constructors in the data declaration determines the ordering in derived Ord instances. The Ordering datatype allows a single comparison to determine the precise ordering of two objects. The default declarations allow a user to create an Ord instance either with a type-specific compare function or with type-specific == and <= functions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Wed Feb 6 20:57:12 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Wed, 6 Feb 2019 15:57:12 -0500 Subject: Peeking into StgInfoTable in cmm In-Reply-To: References: <45059A3F-1DBA-4362-9336-74C79FC0CAF9@gmail.com> Message-ID: Or even better, it looks like cmmGetClosureType already combines the two for me. On Wed, Feb 6, 2019 at 3:49 PM Andrew Martin wrote: > Thanks. The source code of ghc-heap has led me to what I was looking for. > That whole library hinges upon unpackClosure# (stg_unpackClosurezh), whose > implementation opens with the telling: > > info = %GET_STD_INFO(UNTAG(closure)); > > In CmmParse.y, we find the implementation of GET_STD_INFO, and just a few > lines below is the INFO_TYPE macro. The combination of these (along with a > cmm implementation of UNTAG, which I am still unsure of exactly how to > accomplish) should do the trick. > > On Wed, Feb 6, 2019 at 2:53 PM Matthew Pickering < > matthewtpickering at gmail.com> wrote: > >> Unless I am misunderstanding you want something which works like ghc-heap. >> >> If so, perhaps these three files will be instructive? >> >> >> https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTable.hsc >> >> https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTableProf.hsc >> >> https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/Closures.hs#L25 >> >> Cheers, >> >> Matt >> >> On Wed, Feb 6, 2019 at 7:29 PM Andrew Martin >> wrote: >> > >> > For an optimization I’m implementing, I’m trying to write an inline >> primop that gives me lets me inspect the closure type of an arbitrary >> heap-allocated value. I’m close to figuring this out, and the FCode >> machinery is starting to make sense, but one thing eludes me. Starting from >> a StgHeader, I get the info table pointer. This is easy since it’s the >> first field in the struct. But next I have to deference the info table >> pointer and get the closure type. There are two fields at the beginning of >> an info table that may or may not be present. I don’t know how to figure >> out if they are present or not. I suspect that there is something I can get >> out of DynFlags that tells me this, but I can’t find anything else in the >> stg-to-cmm pass that reads from an info table. >> > >> > Sent from my iPhone >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > -- > -Andrew Thaddeus Martin > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Wed Feb 6 21:02:38 2019 From: tikhon at jelv.is (Tikhon Jelvis) Date: Wed, 6 Feb 2019 13:02:38 -0800 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: Does the wording of the report specify "totally ordered" as a law? I think it would be good to make that explicit, laying out the axioms for what a total order is—similar to the current documentation in Data.Ord but explicitly as the laws for the class. The relationship between Eq and Ord should be explicitly specified too, if it isn't. On Wed, Feb 6, 2019, 12:53 Herbert Valerio Riedel > > > > On Wed, Feb 6, 2019 at 9:43 PM chessai . wrote: > >> Per GHC.Classes (haddock-viewable from Data.Ord) >> >> "The Haskell Report defines no laws for Ord. However, <= is >> customarily expected to implement a non-strict partial order and have >> the following properties:" >> >> I propose that in the next report that the expected typeclass laws for >> Ord be added. They're generally agreed upon/understood. >> > > > Can you spell out the concrete change to the report wording you're > suggesting? For reference, the current wording used in the 2010 Haskell > Report is quoted below. While at it, you might also want to take into > account the `Eq` class definition in the report. > > > 6.3.2 The Ord Class > > class (Eq a) => Ord a where > compare :: a -> a -> Ordering > (<), (<=), (>=), (>) :: a -> a -> Bool > max, min :: a -> a -> a > > compare x y | x == y = EQ > | x <= y = LT > | otherwise = GT > > x <= y = compare x y /= GT > x < y = compare x y == LT > x >= y = compare x y /= LT > x > y = compare x y == GT > > -- Note that (min x y, max x y) = (x,y) or (y,x) > max x y | x <= y = y > | otherwise = x > min x y | x <= y = x > | otherwise = y > > The Ord class is used for totally ordered datatypes. All basic datatypes > except for functions, IO, and IOError, are instances of this class. > Instances of Ord can be derived for any user-defined datatype whose > constituent types are in Ord. The declared order of the constructors in > the data declaration determines the ordering in derived Ord instances. > The Ordering datatype allows a single comparison to determine the precise > ordering of two objects. > > The default declarations allow a user to create an Ord instance either > with a type-specific compare function or with type-specific == and <= > functions. > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From timmcgil at gmail.com Wed Feb 6 21:23:06 2019 From: timmcgil at gmail.com (Tim McGilchrist) Date: Thu, 7 Feb 2019 08:23:06 +1100 Subject: Contacting bytestring-trie maintainers In-Reply-To: References: Message-ID: Hi All, I am again attempting to get in touch with the maintainer for bytestring- trie package (http://hackage.haskell.org/package/bytestring-trie), Wren Romano. I have tried to contact the maintainer a number of times over the space of more than a year now. Could I ask to take over maintainership of the package so that I can fix build errors with newer GHCs and the downstream packages that depend on this, including my own personal and work projects. Cheers, Tim McGilchrist On Thu, Nov 1, 2018 at 9:00 AM Tim McGilchrist wrote: > Thanks I’ve sent off a few emails to various addresses. Hope her health > improves. > > Tim > > On Wed, 31 Oct 2018 at 12:39 pm, Lennart Augustsson < > lennart at augustsson.net> wrote: > >> Hi, >> >> Wren has been on sick leave for a while, but she should be coming back >> soon, I think. >> >> — Lennart >> >> On Tue, Oct 30, 2018 at 16:06 Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> Last I checked she works with lennart and co at google. Perhaps he can >>> help ? >>> >>> On Tue, Oct 30, 2018 at 4:52 PM Tim McGilchrist >>> wrote: >>> >>>> Hi All, >>>> >>>> I am trying to get in touch with the maintainers for bytestring-trie >>>> package ( >>>> http://hackage.haskell.org/package/bytestring-trie >>>> ), which appears to be Wren Romano. I have a patch to fix issues with >>>> GHC 8.4 support. I have sent 2 emails over the last few months using the >>>> contact details in the cabal file and haven’t received a reply. Email >>>> attached below. >>>> >>>> Could I ask if someone has a better contact address or is able to pass >>>> on the email that they would. Failing that I’d like to get access to push >>>> the fix to hackage without the need for making a forked package. >>>> >>>> Cheers, >>>> Tim McGilchrist >>>> >>>> >>>> ——————————————————— >>>> Hi Wren, >>>> >>>> I'm using your bytestring-trie library in a package (airship) and >>>> wanted to add support for GHC 8.4.3 to both airship and bytestring-trie. >>>> Please find attached a minor patch to add support which is mainly concerned >>>> with adding the Semigroup instances required. >>>> >>>> If you're happy with the changes I'd also appreciate a new release of >>>> the package to hackage. >>>> >>>> Regards, >>>> Tim McGilchrist >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Wed Feb 6 21:31:27 2019 From: chessai1996 at gmail.com (chessai .) Date: Wed, 6 Feb 2019 16:31:27 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: Sure. There are no explicit mention of the laws of Ord. I think they should be explicitly stated in the report, perhaps like so: ---------- start proposed change class (Eq a) => Ord a where compare :: a -> a -> Ordering (<), (<=), (>), (>=) :: a -> a -> Bool max, min :: a -> a -> a compare x y = if x == y then EQ else if x <= y then LT else GT x < y = case compare x y of { LT -> True; _ -> False } x <= y = case compare x y of { GT -> False; _ -> True } x > y = case compare x y of { GT -> True; _ -> False } x >= y = case compare x y of { LT -> False; _ -> True } max x y = if x <= y then y else x min x y = if x <= y then x else y {-# MINIMAL compare | (<=) #-} The `Ord` class is used for totally ordered datatypes. Instances of 'Ord' can be derived for any user-defined datatype whose constituent types are in 'Ord'. The declared order of the constructors in the data declaration determines the ordering in the derived 'Ord' instances. The 'Ordering' datatype allows a single comparison to determine the precise ordering of two objects. A minimal instance of 'Ord' implements either 'compare' or '<=', and is expected to adhere to the following laws: Antisymmetry (a <= b && b <= a = a == b) Transitivity (a <= b && b <= c = a <= c) Totality (a <= b || b <= a = True) An additional law, Reflexity, is implied by Totality. It states (x <= x = True). ---------- end proposed change I don't particularly like the bit in the current documentation about (<=) implementing a non-strict partial ordering, because if (<=) constitutes a minimal definition of Ord and is required only to be a partial ordering on the type parameterised by Ord, then why is Ord required to be a total ordering? That seems sort of confusing. It seems to me that the current documentation leans more toward 'Ord' implementing a partial order than a total order. I can't speak for others, but when I think of 'Ord' I usually think of a total ordering. Additionally, Reflexity is strictly weaker than Totality, so specifying their relationship (Reflexivity is implied by Totality) and also writing out what Totality means in the context of Ord makes sense to me. For Eq, the report currently states: ----------begin report quote class Eq a where (==), (/=) :: a -> a -> Bool x /= y = not (x == y) x == y = not (x /= y) The Eq class provides equality (==) and inequality (/=) methods. All basic datatypes except for functions and IO are instances of this class. Instances of Eq can be derived for any user-defined datatype whose constituents are also instances of Eq. This declaration gives default method declarations for both /= and ==, each being defined in terms of the other. If an instance declaration for Eq defines neither == nor /=, then both will loop. If one is defined, the default method for the other will make use of the one that is defined. If both are defined, neither default method is used. ----------end report quote I think the following changes make sense: ---------- begin proposed changes class Eq a where (==), (/=) :: a -> a -> Bool x /= y = not (x == y) x == y = not (x /= y) The 'Eq' class defines equality ('==') and inequality ('/='). All the basic datatypes exported by the "Prelude" are instances of 'Eq', and 'Eq' may be derived for any datatype whose constituents are also instances of 'Eq'. '==' implements an equivalence relationship where two values comparing equal are considered indistinguishable. A minimal instance of 'Eq' implements either '==' or '/=', and must adhere to the following laws: Reflexivity (x == x = True) Symmetry (x == y = y == x) Transitivity (x == y && y == z = x == z) Substitutivity (x == y = f x == f y) Negation (x /= y = not (x = y) ---------- end proposed changes On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel wrote: > > > > > > On Wed, Feb 6, 2019 at 9:43 PM chessai . wrote: >> >> Per GHC.Classes (haddock-viewable from Data.Ord) >> >> "The Haskell Report defines no laws for Ord. However, <= is >> customarily expected to implement a non-strict partial order and have >> the following properties:" >> >> I propose that in the next report that the expected typeclass laws for >> Ord be added. They're generally agreed upon/understood. > > > > Can you spell out the concrete change to the report wording you're suggesting? For reference, the current wording used in the 2010 Haskell Report is quoted below. While at it, you might also want to take into account the `Eq` class definition in the report. > > > 6.3.2 The Ord Class > > class (Eq a) => Ord a where > compare :: a -> a -> Ordering > (<), (<=), (>=), (>) :: a -> a -> Bool > max, min :: a -> a -> a > > compare x y | x == y = EQ > | x <= y = LT > | otherwise = GT > > x <= y = compare x y /= GT > x < y = compare x y == LT > x >= y = compare x y /= LT > x > y = compare x y == GT > > -- Note that (min x y, max x y) = (x,y) or (y,x) > max x y | x <= y = y > | otherwise = x > min x y | x <= y = x > | otherwise = y > > The Ord class is used for totally ordered datatypes. All basic datatypes except for functions, IO, and IOError, are instances of this class. Instances of Ord can be derived for any user-defined datatype whose constituent types are in Ord. The declared order of the constructors in the data declaration determines the ordering in derived Ord instances. The Ordering datatype allows a single comparison to determine the precise ordering of two objects. > > The default declarations allow a user to create an Ord instance either with a type-specific compare function or with type-specific == and <= functions. > > > From carter.schonwald at gmail.com Wed Feb 6 21:34:42 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 6 Feb 2019 16:34:42 -0500 Subject: Contacting bytestring-trie maintainers In-Reply-To: References: Message-ID: wren was on medical leave but certainly reachable .. albeit slowly as an interrum fix while we resolve maintainership , please open a request for a hackage trustee/admin nmu to resolve any outstanding issues On Wed, Feb 6, 2019 at 4:23 PM Tim McGilchrist wrote: > Hi All, > > I am again attempting to get in touch with the maintainer for bytestring- > trie package (http://hackage.haskell.org/package/bytestring-trie), Wren > Romano. > > I have tried to contact the maintainer a number of times over the space of > more than a year now. Could I ask to take over maintainership of the > package so that I can fix build errors with newer GHCs and the downstream > packages that depend on this, including my own personal and work projects. > > Cheers, > Tim McGilchrist > > On Thu, Nov 1, 2018 at 9:00 AM Tim McGilchrist wrote: > >> Thanks I’ve sent off a few emails to various addresses. Hope her health >> improves. >> >> Tim >> >> On Wed, 31 Oct 2018 at 12:39 pm, Lennart Augustsson < >> lennart at augustsson.net> wrote: >> >>> Hi, >>> >>> Wren has been on sick leave for a while, but she should be coming back >>> soon, I think. >>> >>> — Lennart >>> >>> On Tue, Oct 30, 2018 at 16:06 Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> Last I checked she works with lennart and co at google. Perhaps he can >>>> help ? >>>> >>>> On Tue, Oct 30, 2018 at 4:52 PM Tim McGilchrist >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I am trying to get in touch with the maintainers for bytestring-trie >>>>> package ( >>>>> http://hackage.haskell.org/package/bytestring-trie >>>>> ), which appears to be Wren Romano. I have a patch to fix issues with >>>>> GHC 8.4 support. I have sent 2 emails over the last few months using the >>>>> contact details in the cabal file and haven’t received a reply. Email >>>>> attached below. >>>>> >>>>> Could I ask if someone has a better contact address or is able to pass >>>>> on the email that they would. Failing that I’d like to get access to push >>>>> the fix to hackage without the need for making a forked package. >>>>> >>>>> Cheers, >>>>> Tim McGilchrist >>>>> >>>>> >>>>> ——————————————————— >>>>> Hi Wren, >>>>> >>>>> I'm using your bytestring-trie library in a package (airship) and >>>>> wanted to add support for GHC 8.4.3 to both airship and bytestring-trie. >>>>> Please find attached a minor patch to add support which is mainly concerned >>>>> with adding the Semigroup instances required. >>>>> >>>>> If you're happy with the changes I'd also appreciate a new release of >>>>> the package to hackage. >>>>> >>>>> Regards, >>>>> Tim McGilchrist >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Feb 6 22:29:28 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Feb 2019 22:29:28 +0000 Subject: Peeking into StgInfoTable in cmm In-Reply-To: References: <45059A3F-1DBA-4362-9336-74C79FC0CAF9@gmail.com> Message-ID: You might also find compiler/ghci/RtClosureInspect.hs useful. It’s the main module of the GHCi debugger, and allows Haskell code to inspect the Haskell heap. So it has mechanisms for unpacking arbitrary closures, all in Haskell. It’s tough going though. It was written a long time ago by Pepe Iborra (in a GSoC project), and has not received much love since. Maybe you could be a source of love?! Simon From: Libraries On Behalf Of Andrew Martin Sent: 06 February 2019 20:57 To: Matthew Pickering Cc: Haskell Libraries Subject: Re: Peeking into StgInfoTable in cmm Or even better, it looks like cmmGetClosureType already combines the two for me. On Wed, Feb 6, 2019 at 3:49 PM Andrew Martin > wrote: Thanks. The source code of ghc-heap has led me to what I was looking for. That whole library hinges upon unpackClosure# (stg_unpackClosurezh), whose implementation opens with the telling: info = %GET_STD_INFO(UNTAG(closure)); In CmmParse.y, we find the implementation of GET_STD_INFO, and just a few lines below is the INFO_TYPE macro. The combination of these (along with a cmm implementation of UNTAG, which I am still unsure of exactly how to accomplish) should do the trick. On Wed, Feb 6, 2019 at 2:53 PM Matthew Pickering > wrote: Unless I am misunderstanding you want something which works like ghc-heap. If so, perhaps these three files will be instructive? https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTable.hsc https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTableProf.hsc https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/Closures.hs#L25 Cheers, Matt On Wed, Feb 6, 2019 at 7:29 PM Andrew Martin > wrote: > > For an optimization I’m implementing, I’m trying to write an inline primop that gives me lets me inspect the closure type of an arbitrary heap-allocated value. I’m close to figuring this out, and the FCode machinery is starting to make sense, but one thing eludes me. Starting from a StgHeader, I get the info table pointer. This is easy since it’s the first field in the struct. But next I have to deference the info table pointer and get the closure type. There are two fields at the beginning of an info table that may or may not be present. I don’t know how to figure out if they are present or not. I suspect that there is something I can get out of DynFlags that tells me this, but I can’t find anything else in the stg-to-cmm pass that reads from an info table. > > Sent from my iPhone > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- -Andrew Thaddeus Martin -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Wed Feb 6 22:36:43 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Wed, 6 Feb 2019 17:36:43 -0500 Subject: Peeking into StgInfoTable in cmm In-Reply-To: References: <45059A3F-1DBA-4362-9336-74C79FC0CAF9@gmail.com> Message-ID: Woah, that's pretty neat. I didn't even realize that GHCi could do that. >From a quick perusal of the GHCi docs, it looks like :print and :force are related commands. How is GHCi used to show the type of a closure though? On Wed, Feb 6, 2019 at 5:29 PM Simon Peyton Jones wrote: > You might also find compiler/ghci/RtClosureInspect.hs useful. > > > > It’s the main module of the GHCi debugger, and allows Haskell code to > inspect the Haskell heap. So it has mechanisms for unpacking arbitrary > closures, all in Haskell. > > > > It’s tough going though. It was written a long time ago by Pepe Iborra > (in a GSoC project), and has not received much love since. Maybe you could > be a source of love?! > > > > Simon > > > > *From:* Libraries *On Behalf Of *Andrew > Martin > *Sent:* 06 February 2019 20:57 > *To:* Matthew Pickering > *Cc:* Haskell Libraries > *Subject:* Re: Peeking into StgInfoTable in cmm > > > > Or even better, it looks like cmmGetClosureType already combines the two > for me. > > > > On Wed, Feb 6, 2019 at 3:49 PM Andrew Martin > wrote: > > Thanks. The source code of ghc-heap has led me to what I was looking for. > That whole library hinges upon unpackClosure# (stg_unpackClosurezh), whose > implementation opens with the telling: > > > > info = %GET_STD_INFO(UNTAG(closure)); > > > > In CmmParse.y, we find the implementation of GET_STD_INFO, and just a few > lines below is the INFO_TYPE macro. The combination of these (along with a > cmm implementation of UNTAG, which I am still unsure of exactly how to > accomplish) should do the trick. > > > > On Wed, Feb 6, 2019 at 2:53 PM Matthew Pickering < > matthewtpickering at gmail.com> wrote: > > Unless I am misunderstanding you want something which works like ghc-heap. > > If so, perhaps these three files will be instructive? > > > https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTable.hsc > > > https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/InfoTableProf.hsc > > > https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/ghc-heap/GHC/Exts/Heap/Closures.hs#L25 > > > Cheers, > > Matt > > On Wed, Feb 6, 2019 at 7:29 PM Andrew Martin > wrote: > > > > For an optimization I’m implementing, I’m trying to write an inline > primop that gives me lets me inspect the closure type of an arbitrary > heap-allocated value. I’m close to figuring this out, and the FCode > machinery is starting to make sense, but one thing eludes me. Starting from > a StgHeader, I get the info table pointer. This is easy since it’s the > first field in the struct. But next I have to deference the info table > pointer and get the closure type. There are two fields at the beginning of > an info table that may or may not be present. I don’t know how to figure > out if they are present or not. I suspect that there is something I can get > out of DynFlags that tells me this, but I can’t find anything else in the > stg-to-cmm pass that reads from an info table. > > > > Sent from my iPhone > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > -- > > -Andrew Thaddeus Martin > > > > > -- > > -Andrew Thaddeus Martin > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Wed Feb 6 22:44:54 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Wed, 6 Feb 2019 17:44:54 -0500 Subject: Calling the callback when event registration fails Message-ID: In the event manager's registerFd_, we find: registerFd_ :: EventManager -> IOCallback -> Fd -> Event -> Lifetime -> IO (FdKey, Bool) registerFd_ mgr@(EventManager{..}) cb !fd !evs lt = do ... <- ... (modify,ok) <- withMVar (callbackTableVar mgr fd) $ \tbl -> do ... <- ... -- this simulates behavior of old IO manager: -- i.e. just call the callback if the registration fails. when (not ok) (cb reg evs) return (reg,modify) A comment and a question. Comment: registerFd_ is only ever called in contexts where exceptions are masked, so withMVar is doing some needless mask/restore. Question: why do we immidiately call the callback if event registration fails? This means that if event registration fails during something like `threadWaitRead`, the end result would be that `threadWaitRead` would just return immidiately. That doesn't seem good. -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From george at wils.online Wed Feb 6 23:53:34 2019 From: george at wils.online (George Wilson) Date: Thu, 7 Feb 2019 09:53:34 +1000 Subject: Contacting bytestring-trie maintainers In-Reply-To: References: Message-ID: I've started the non-maintainer upload process here: https://github.com/haskell-infra/hackage-trustees/issues/210 Cheers, George On Thu, 7 Feb 2019 at 07:35, Carter Schonwald wrote: > > wren was on medical leave but certainly reachable .. albeit slowly > > as an interrum fix while we resolve maintainership , please open a request for a hackage trustee/admin nmu to resolve any outstanding issues > > On Wed, Feb 6, 2019 at 4:23 PM Tim McGilchrist wrote: >> >> Hi All, >> >> I am again attempting to get in touch with the maintainer for bytestring-trie package (http://hackage.haskell.org/package/bytestring-trie), Wren Romano. >> >> I have tried to contact the maintainer a number of times over the space of more than a year now. Could I ask to take over maintainership of the package so that I can fix build errors with newer GHCs and the downstream packages that depend on this, including my own personal and work projects. >> >> Cheers, >> Tim McGilchrist >> >> On Thu, Nov 1, 2018 at 9:00 AM Tim McGilchrist wrote: >>> >>> Thanks I’ve sent off a few emails to various addresses. Hope her health improves. >>> >>> Tim >>> >>> On Wed, 31 Oct 2018 at 12:39 pm, Lennart Augustsson wrote: >>>> >>>> Hi, >>>> >>>> Wren has been on sick leave for a while, but she should be coming back soon, I think. >>>> >>>> — Lennart >>>> >>>> On Tue, Oct 30, 2018 at 16:06 Carter Schonwald wrote: >>>>> >>>>> Last I checked she works with lennart and co at google. Perhaps he can help ? >>>>> >>>>> On Tue, Oct 30, 2018 at 4:52 PM Tim McGilchrist wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> I am trying to get in touch with the maintainers for bytestring-trie package ( >>>>>> http://hackage.haskell.org/package/bytestring-trie >>>>>> ), which appears to be Wren Romano. I have a patch to fix issues with GHC 8.4 support. I have sent 2 emails over the last few months using the contact details in the cabal file and haven’t received a reply. Email attached below. >>>>>> >>>>>> Could I ask if someone has a better contact address or is able to pass on the email that they would. Failing that I’d like to get access to push the fix to hackage without the need for making a forked package. >>>>>> >>>>>> Cheers, >>>>>> Tim McGilchrist >>>>>> >>>>>> >>>>>> ——————————————————— >>>>>> Hi Wren, >>>>>> >>>>>> I'm using your bytestring-trie library in a package (airship) and wanted to add support for GHC 8.4.3 to both airship and bytestring-trie. Please find attached a minor patch to add support which is mainly concerned with adding the Semigroup instances required. >>>>>> >>>>>> If you're happy with the changes I'd also appreciate a new release of the package to hackage. >>>>>> >>>>>> Regards, >>>>>> Tim McGilchrist >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From andrew.thaddeus at gmail.com Thu Feb 7 00:09:35 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Wed, 6 Feb 2019 19:09:35 -0500 Subject: Calling the callback when event registration fails In-Reply-To: References: Message-ID: Digging through the different backends, it looks like only the kqueue backend is even capable of returning False when modifyFd/modifyFdOnce is called. This happens when kevent returns eINTR or eINVAL. Why do we call the callback here instead of just throwing an error like we do in so many other cases? On Wed, Feb 6, 2019 at 5:44 PM Andrew Martin wrote: > In the event manager's registerFd_, we find: > > registerFd_ :: EventManager -> IOCallback -> Fd -> Event -> Lifetime > -> IO (FdKey, Bool) > registerFd_ mgr@(EventManager{..}) cb !fd !evs lt = do > ... <- ... > (modify,ok) <- withMVar (callbackTableVar mgr fd) $ \tbl -> do > ... <- ... > -- this simulates behavior of old IO manager: > -- i.e. just call the callback if the registration fails. > when (not ok) (cb reg evs) > return (reg,modify) > > A comment and a question. Comment: registerFd_ is only ever called in > contexts where exceptions are masked, so withMVar is doing some needless > mask/restore. Question: why do we immidiately call the callback if event > registration fails? This means that if event registration fails during > something like `threadWaitRead`, the end result would be that > `threadWaitRead` would just return immidiately. That doesn't seem good. > > -- > -Andrew Thaddeus Martin > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 01:55:45 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 6 Feb 2019 20:55:45 -0500 Subject: Calling the callback when event registration fails In-Reply-To: References: Message-ID: under what circumstances would those failure modes happen where the process can still run? (if need be, i can help you dig into the *BSD code bases if we aren't sure when the kqueue code would do that) On Wed, Feb 6, 2019 at 7:10 PM Andrew Martin wrote: > Digging through the different backends, it looks like only the kqueue > backend is even capable of returning False when modifyFd/modifyFdOnce is > called. This happens when kevent returns eINTR or eINVAL. Why do we call > the callback here instead of just throwing an error like we do in so many > other cases? > > On Wed, Feb 6, 2019 at 5:44 PM Andrew Martin > wrote: > >> In the event manager's registerFd_, we find: >> >> registerFd_ :: EventManager -> IOCallback -> Fd -> Event -> Lifetime >> -> IO (FdKey, Bool) >> registerFd_ mgr@(EventManager{..}) cb !fd !evs lt = do >> ... <- ... >> (modify,ok) <- withMVar (callbackTableVar mgr fd) $ \tbl -> do >> ... <- ... >> -- this simulates behavior of old IO manager: >> -- i.e. just call the callback if the registration fails. >> when (not ok) (cb reg evs) >> return (reg,modify) >> >> A comment and a question. Comment: registerFd_ is only ever called in >> contexts where exceptions are masked, so withMVar is doing some needless >> mask/restore. Question: why do we immidiately call the callback if event >> registration fails? This means that if event registration fails during >> something like `threadWaitRead`, the end result would be that >> `threadWaitRead` would just return immidiately. That doesn't seem good. >> >> -- >> -Andrew Thaddeus Martin >> > > > -- > -Andrew Thaddeus Martin > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 02:43:23 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 6 Feb 2019 21:43:23 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: We cant add laws at the moment unless we change how the Ord instances for Float and Double are defined. (which i think SHOULd happen, but needs some care and has lots of implications) there are several possible semantics we can choose that act as we expect on +/- infity and finite floats, but differ in the handling of nans option 1) use the total order defined in floating point standard 2008, section 5.10, which defines negative nans below -infity, positive nans above +infty (this has the nice property that you could check for not nan by -infty <= x && x <= infty) option 2) shift haskell/ GHC to having signalling NAN semantics by default, so the only "fully evaluated" floating point values are in the interval from negative to positive infinity , option 3) some mixture of the above I am slowly doing some patches to improve floating point bits in ghc (and pave the way towards doing something like one of the above), though theres still much to do also: the current definitions of min/max via compare aren't commutative if either argument is nan (they become right biased or left biased, i forget which) http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a copy of ieee floating point 2008 (easy to google up a copy if that link doesnt work) On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: > Sure. There are no explicit mention of the laws of Ord. I think they > should be explicitly stated in the report, perhaps like so: > > ---------- start proposed change > class (Eq a) => Ord a where > compare :: a -> a -> Ordering > (<), (<=), (>), (>=) :: a -> a -> Bool > max, min :: a -> a -> a > > compare x y = if x == y then EQ > else if x <= y then LT > else GT > > x < y = case compare x y of { LT -> True; _ -> False } > x <= y = case compare x y of { GT -> False; _ -> True } > x > y = case compare x y of { GT -> True; _ -> False } > x >= y = case compare x y of { LT -> False; _ -> True } > > max x y = if x <= y then y else x > min x y = if x <= y then x else y > {-# MINIMAL compare | (<=) #-} > > The `Ord` class is used for totally ordered datatypes. Instances of > 'Ord' can be derived for any user-defined datatype whose constituent > types are in 'Ord'. The declared order of the constructors in the data > declaration determines the ordering in the derived 'Ord' instances. > The 'Ordering' datatype allows a single comparison to determine the > precise ordering of two objects. > > A minimal instance of 'Ord' implements either 'compare' or '<=', and > is expected to adhere to the following laws: > > Antisymmetry (a <= b && b <= a = a == b) > Transitivity (a <= b && b <= c = a <= c) > Totality (a <= b || b <= a = True) > > An additional law, Reflexity, is implied by Totality. It states (x <= x = > True). > ---------- end proposed change > > I don't particularly like the bit in the current documentation about > (<=) implementing a non-strict partial ordering, because if (<=) > constitutes a minimal definition of Ord and is required only to be a > partial ordering on the type parameterised by Ord, then why is Ord > required to be a total ordering? That seems sort of confusing. It > seems to me that the current documentation leans more toward 'Ord' > implementing a partial order than a total order. I can't speak for > others, but when I think of 'Ord' I usually think of a total ordering. > > Additionally, Reflexity is strictly weaker than Totality, so > specifying their relationship (Reflexivity is implied by Totality) and > also writing out what Totality means in the context of Ord makes sense > to me. > > For Eq, the report currently states: > > ----------begin report quote > class Eq a where > (==), (/=) :: a -> a -> Bool > > x /= y = not (x == y) > x == y = not (x /= y) > > The Eq class provides equality (==) and inequality (/=) methods. All > basic datatypes except for functions and IO are instances of this > class. Instances of Eq can be derived for any user-defined datatype > whose constituents are also instances of Eq. > > This declaration gives default method declarations for both /= and ==, > each being defined in terms of the other. If an instance declaration > for Eq defines neither == nor /=, then both will loop. If one is > defined, the default method for the other will make use of the one > that is defined. If both are defined, neither default method is used. > ----------end report quote > > I think the following changes make sense: > > ---------- begin proposed changes > > class Eq a where > (==), (/=) :: a -> a -> Bool > x /= y = not (x == y) > x == y = not (x /= y) > > The 'Eq' class defines equality ('==') and inequality ('/='). > All the basic datatypes exported by the "Prelude" are instances of 'Eq', > and 'Eq' may be derived for any datatype whose constituents are also > instances of 'Eq'. > > '==' implements an equivalence relationship where two values comparing > equal > are considered indistinguishable. A minimal instance of 'Eq' > implements either '==' or '/=', and must adhere to the following laws: > > Reflexivity (x == x = True) > Symmetry (x == y = y == x) > Transitivity (x == y && y == z = x == z) > Substitutivity (x == y = f x == f y) > Negation (x /= y = not (x = y) > ---------- end proposed changes > > On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel > wrote: > > > > > > > > > > > > On Wed, Feb 6, 2019 at 9:43 PM chessai . wrote: > >> > >> Per GHC.Classes (haddock-viewable from Data.Ord) > >> > >> "The Haskell Report defines no laws for Ord. However, <= is > >> customarily expected to implement a non-strict partial order and have > >> the following properties:" > >> > >> I propose that in the next report that the expected typeclass laws for > >> Ord be added. They're generally agreed upon/understood. > > > > > > > > Can you spell out the concrete change to the report wording you're > suggesting? For reference, the current wording used in the 2010 Haskell > Report is quoted below. While at it, you might also want to take into > account the `Eq` class definition in the report. > > > > > > 6.3.2 The Ord Class > > > > class (Eq a) => Ord a where > > compare :: a -> a -> Ordering > > (<), (<=), (>=), (>) :: a -> a -> Bool > > max, min :: a -> a -> a > > > > compare x y | x == y = EQ > > | x <= y = LT > > | otherwise = GT > > > > x <= y = compare x y /= GT > > x < y = compare x y == LT > > x >= y = compare x y /= LT > > x > y = compare x y == GT > > > > -- Note that (min x y, max x y) = (x,y) or (y,x) > > max x y | x <= y = y > > | otherwise = x > > min x y | x <= y = x > > | otherwise = y > > > > The Ord class is used for totally ordered datatypes. All basic datatypes > except for functions, IO, and IOError, are instances of this class. > Instances of Ord can be derived for any user-defined datatype whose > constituent types are in Ord. The declared order of the constructors in the > data declaration determines the ordering in derived Ord instances. The > Ordering datatype allows a single comparison to determine the precise > ordering of two objects. > > > > The default declarations allow a user to create an Ord instance either > with a type-specific compare function or with type-specific == and <= > functions. > > > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From timmcgil at gmail.com Thu Feb 7 03:15:00 2019 From: timmcgil at gmail.com (Tim McGilchrist) Date: Thu, 7 Feb 2019 14:15:00 +1100 Subject: Contacting bytestring-trie maintainers In-Reply-To: References: Message-ID: Thanks George On Thu, 7 Feb 2019 at 10:54 am, George Wilson wrote: > I've started the non-maintainer upload process here: > https://github.com/haskell-infra/hackage-trustees/issues/210 > > Cheers, > George > > On Thu, 7 Feb 2019 at 07:35, Carter Schonwald > wrote: > > > > wren was on medical leave but certainly reachable .. albeit slowly > > > > as an interrum fix while we resolve maintainership , please open a > request for a hackage trustee/admin nmu to resolve any outstanding issues > > > > On Wed, Feb 6, 2019 at 4:23 PM Tim McGilchrist > wrote: > >> > >> Hi All, > >> > >> I am again attempting to get in touch with the maintainer for > bytestring-trie package ( > http://hackage.haskell.org/package/bytestring-trie), Wren Romano. > >> > >> I have tried to contact the maintainer a number of times over the space > of more than a year now. Could I ask to take over maintainership of the > package so that I can fix build errors with newer GHCs and the downstream > packages that depend on this, including my own personal and work projects. > >> > >> Cheers, > >> Tim McGilchrist > >> > >> On Thu, Nov 1, 2018 at 9:00 AM Tim McGilchrist > wrote: > >>> > >>> Thanks I’ve sent off a few emails to various addresses. Hope her > health improves. > >>> > >>> Tim > >>> > >>> On Wed, 31 Oct 2018 at 12:39 pm, Lennart Augustsson < > lennart at augustsson.net> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Wren has been on sick leave for a while, but she should be coming > back soon, I think. > >>>> > >>>> — Lennart > >>>> > >>>> On Tue, Oct 30, 2018 at 16:06 Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >>>>> > >>>>> Last I checked she works with lennart and co at google. Perhaps he > can help ? > >>>>> > >>>>> On Tue, Oct 30, 2018 at 4:52 PM Tim McGilchrist > wrote: > >>>>>> > >>>>>> Hi All, > >>>>>> > >>>>>> I am trying to get in touch with the maintainers for > bytestring-trie package ( > >>>>>> http://hackage.haskell.org/package/bytestring-trie > >>>>>> ), which appears to be Wren Romano. I have a patch to fix issues > with GHC 8.4 support. I have sent 2 emails over the last few months using > the contact details in the cabal file and haven’t received a reply. Email > attached below. > >>>>>> > >>>>>> Could I ask if someone has a better contact address or is able to > pass on the email that they would. Failing that I’d like to get access to > push the fix to hackage without the need for making a forked package. > >>>>>> > >>>>>> Cheers, > >>>>>> Tim McGilchrist > >>>>>> > >>>>>> > >>>>>> ——————————————————— > >>>>>> Hi Wren, > >>>>>> > >>>>>> I'm using your bytestring-trie library in a package (airship) and > wanted to add support for GHC 8.4.3 to both airship and bytestring-trie. > Please find attached a minor patch to add support which is mainly concerned > with adding the Semigroup instances required. > >>>>>> > >>>>>> If you're happy with the changes I'd also appreciate a new release > of the package to hackage. > >>>>>> > >>>>>> Regards, > >>>>>> Tim McGilchrist > >>>>>> _______________________________________________ > >>>>>> Libraries mailing list > >>>>>> Libraries at haskell.org > >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Feb 7 03:30:00 2019 From: david.feuer at gmail.com (David Feuer) Date: Wed, 6 Feb 2019 22:30:00 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: We can add laws while recognizing that some existing instances are not lawful. On Wed, Feb 6, 2019, 9:43 PM Carter Schonwald We cant add laws at the moment unless we change how the Ord instances for > Float and Double are defined. (which i think SHOULd happen, but needs some > care and has lots of implications) > > there are several possible semantics we can choose that act as we expect > on +/- infity and finite floats, but differ in the handling of nans > > option 1) use the total order defined in floating point standard 2008, > section 5.10, which defines negative nans below -infity, positive nans > above +infty > (this has the nice property that you could check for not nan by -infty > <= x && x <= infty) > > option 2) shift haskell/ GHC to having signalling NAN semantics by > default, so the only "fully evaluated" floating point values are in the > interval from negative to positive infinity , > > option 3) some mixture of the above > > I am slowly doing some patches to improve floating point bits in ghc (and > pave the way towards doing something like one of the above), though theres > still much to do > > also: the current definitions of min/max via compare aren't commutative if > either argument is nan (they become right biased or left biased, i forget > which) > > http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a > copy of ieee floating point 2008 (easy to google up a copy if that link > doesnt work) > > > > > On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: > >> Sure. There are no explicit mention of the laws of Ord. I think they >> should be explicitly stated in the report, perhaps like so: >> >> ---------- start proposed change >> class (Eq a) => Ord a where >> compare :: a -> a -> Ordering >> (<), (<=), (>), (>=) :: a -> a -> Bool >> max, min :: a -> a -> a >> >> compare x y = if x == y then EQ >> else if x <= y then LT >> else GT >> >> x < y = case compare x y of { LT -> True; _ -> False } >> x <= y = case compare x y of { GT -> False; _ -> True } >> x > y = case compare x y of { GT -> True; _ -> False } >> x >= y = case compare x y of { LT -> False; _ -> True } >> >> max x y = if x <= y then y else x >> min x y = if x <= y then x else y >> {-# MINIMAL compare | (<=) #-} >> >> The `Ord` class is used for totally ordered datatypes. Instances of >> 'Ord' can be derived for any user-defined datatype whose constituent >> types are in 'Ord'. The declared order of the constructors in the data >> declaration determines the ordering in the derived 'Ord' instances. >> The 'Ordering' datatype allows a single comparison to determine the >> precise ordering of two objects. >> >> A minimal instance of 'Ord' implements either 'compare' or '<=', and >> is expected to adhere to the following laws: >> >> Antisymmetry (a <= b && b <= a = a == b) >> Transitivity (a <= b && b <= c = a <= c) >> Totality (a <= b || b <= a = True) >> >> An additional law, Reflexity, is implied by Totality. It states (x <= x = >> True). >> ---------- end proposed change >> >> I don't particularly like the bit in the current documentation about >> (<=) implementing a non-strict partial ordering, because if (<=) >> constitutes a minimal definition of Ord and is required only to be a >> partial ordering on the type parameterised by Ord, then why is Ord >> required to be a total ordering? That seems sort of confusing. It >> seems to me that the current documentation leans more toward 'Ord' >> implementing a partial order than a total order. I can't speak for >> others, but when I think of 'Ord' I usually think of a total ordering. >> >> Additionally, Reflexity is strictly weaker than Totality, so >> specifying their relationship (Reflexivity is implied by Totality) and >> also writing out what Totality means in the context of Ord makes sense >> to me. >> >> For Eq, the report currently states: >> >> ----------begin report quote >> class Eq a where >> (==), (/=) :: a -> a -> Bool >> >> x /= y = not (x == y) >> x == y = not (x /= y) >> >> The Eq class provides equality (==) and inequality (/=) methods. All >> basic datatypes except for functions and IO are instances of this >> class. Instances of Eq can be derived for any user-defined datatype >> whose constituents are also instances of Eq. >> >> This declaration gives default method declarations for both /= and ==, >> each being defined in terms of the other. If an instance declaration >> for Eq defines neither == nor /=, then both will loop. If one is >> defined, the default method for the other will make use of the one >> that is defined. If both are defined, neither default method is used. >> ----------end report quote >> >> I think the following changes make sense: >> >> ---------- begin proposed changes >> >> class Eq a where >> (==), (/=) :: a -> a -> Bool >> x /= y = not (x == y) >> x == y = not (x /= y) >> >> The 'Eq' class defines equality ('==') and inequality ('/='). >> All the basic datatypes exported by the "Prelude" are instances of 'Eq', >> and 'Eq' may be derived for any datatype whose constituents are also >> instances of 'Eq'. >> >> '==' implements an equivalence relationship where two values comparing >> equal >> are considered indistinguishable. A minimal instance of 'Eq' >> implements either '==' or '/=', and must adhere to the following laws: >> >> Reflexivity (x == x = True) >> Symmetry (x == y = y == x) >> Transitivity (x == y && y == z = x == z) >> Substitutivity (x == y = f x == f y) >> Negation (x /= y = not (x = y) >> ---------- end proposed changes >> >> On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel >> wrote: >> > >> > >> > >> > >> > >> > On Wed, Feb 6, 2019 at 9:43 PM chessai . wrote: >> >> >> >> Per GHC.Classes (haddock-viewable from Data.Ord) >> >> >> >> "The Haskell Report defines no laws for Ord. However, <= is >> >> customarily expected to implement a non-strict partial order and have >> >> the following properties:" >> >> >> >> I propose that in the next report that the expected typeclass laws for >> >> Ord be added. They're generally agreed upon/understood. >> > >> > >> > >> > Can you spell out the concrete change to the report wording you're >> suggesting? For reference, the current wording used in the 2010 Haskell >> Report is quoted below. While at it, you might also want to take into >> account the `Eq` class definition in the report. >> > >> > >> > 6.3.2 The Ord Class >> > >> > class (Eq a) => Ord a where >> > compare :: a -> a -> Ordering >> > (<), (<=), (>=), (>) :: a -> a -> Bool >> > max, min :: a -> a -> a >> > >> > compare x y | x == y = EQ >> > | x <= y = LT >> > | otherwise = GT >> > >> > x <= y = compare x y /= GT >> > x < y = compare x y == LT >> > x >= y = compare x y /= LT >> > x > y = compare x y == GT >> > >> > -- Note that (min x y, max x y) = (x,y) or (y,x) >> > max x y | x <= y = y >> > | otherwise = x >> > min x y | x <= y = x >> > | otherwise = y >> > >> > The Ord class is used for totally ordered datatypes. All basic >> datatypes except for functions, IO, and IOError, are instances of this >> class. Instances of Ord can be derived for any user-defined datatype whose >> constituent types are in Ord. The declared order of the constructors in the >> data declaration determines the ordering in derived Ord instances. The >> Ordering datatype allows a single comparison to determine the precise >> ordering of two objects. >> > >> > The default declarations allow a user to create an Ord instance either >> with a type-specific compare function or with type-specific == and <= >> functions. >> > >> > >> > >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 03:42:29 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 6 Feb 2019 22:42:29 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: true, i just actually WANT to fixup those corners of float, assuming impact can be managed suitably On Wed, Feb 6, 2019 at 10:30 PM David Feuer wrote: > We can add laws while recognizing that some existing instances are not > lawful. > > On Wed, Feb 6, 2019, 9:43 PM Carter Schonwald wrote: > >> We cant add laws at the moment unless we change how the Ord instances for >> Float and Double are defined. (which i think SHOULd happen, but needs some >> care and has lots of implications) >> >> there are several possible semantics we can choose that act as we expect >> on +/- infity and finite floats, but differ in the handling of nans >> >> option 1) use the total order defined in floating point standard 2008, >> section 5.10, which defines negative nans below -infity, positive nans >> above +infty >> (this has the nice property that you could check for not nan by -infty >> <= x && x <= infty) >> >> option 2) shift haskell/ GHC to having signalling NAN semantics by >> default, so the only "fully evaluated" floating point values are in the >> interval from negative to positive infinity , >> >> option 3) some mixture of the above >> >> I am slowly doing some patches to improve floating point bits in ghc (and >> pave the way towards doing something like one of the above), though theres >> still much to do >> >> also: the current definitions of min/max via compare aren't commutative >> if either argument is nan (they become right biased or left biased, i >> forget which) >> >> http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a >> copy of ieee floating point 2008 (easy to google up a copy if that link >> doesnt work) >> >> >> >> >> On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: >> >>> Sure. There are no explicit mention of the laws of Ord. I think they >>> should be explicitly stated in the report, perhaps like so: >>> >>> ---------- start proposed change >>> class (Eq a) => Ord a where >>> compare :: a -> a -> Ordering >>> (<), (<=), (>), (>=) :: a -> a -> Bool >>> max, min :: a -> a -> a >>> >>> compare x y = if x == y then EQ >>> else if x <= y then LT >>> else GT >>> >>> x < y = case compare x y of { LT -> True; _ -> False } >>> x <= y = case compare x y of { GT -> False; _ -> True } >>> x > y = case compare x y of { GT -> True; _ -> False } >>> x >= y = case compare x y of { LT -> False; _ -> True } >>> >>> max x y = if x <= y then y else x >>> min x y = if x <= y then x else y >>> {-# MINIMAL compare | (<=) #-} >>> >>> The `Ord` class is used for totally ordered datatypes. Instances of >>> 'Ord' can be derived for any user-defined datatype whose constituent >>> types are in 'Ord'. The declared order of the constructors in the data >>> declaration determines the ordering in the derived 'Ord' instances. >>> The 'Ordering' datatype allows a single comparison to determine the >>> precise ordering of two objects. >>> >>> A minimal instance of 'Ord' implements either 'compare' or '<=', and >>> is expected to adhere to the following laws: >>> >>> Antisymmetry (a <= b && b <= a = a == b) >>> Transitivity (a <= b && b <= c = a <= c) >>> Totality (a <= b || b <= a = True) >>> >>> An additional law, Reflexity, is implied by Totality. It states (x <= x >>> = True). >>> ---------- end proposed change >>> >>> I don't particularly like the bit in the current documentation about >>> (<=) implementing a non-strict partial ordering, because if (<=) >>> constitutes a minimal definition of Ord and is required only to be a >>> partial ordering on the type parameterised by Ord, then why is Ord >>> required to be a total ordering? That seems sort of confusing. It >>> seems to me that the current documentation leans more toward 'Ord' >>> implementing a partial order than a total order. I can't speak for >>> others, but when I think of 'Ord' I usually think of a total ordering. >>> >>> Additionally, Reflexity is strictly weaker than Totality, so >>> specifying their relationship (Reflexivity is implied by Totality) and >>> also writing out what Totality means in the context of Ord makes sense >>> to me. >>> >>> For Eq, the report currently states: >>> >>> ----------begin report quote >>> class Eq a where >>> (==), (/=) :: a -> a -> Bool >>> >>> x /= y = not (x == y) >>> x == y = not (x /= y) >>> >>> The Eq class provides equality (==) and inequality (/=) methods. All >>> basic datatypes except for functions and IO are instances of this >>> class. Instances of Eq can be derived for any user-defined datatype >>> whose constituents are also instances of Eq. >>> >>> This declaration gives default method declarations for both /= and ==, >>> each being defined in terms of the other. If an instance declaration >>> for Eq defines neither == nor /=, then both will loop. If one is >>> defined, the default method for the other will make use of the one >>> that is defined. If both are defined, neither default method is used. >>> ----------end report quote >>> >>> I think the following changes make sense: >>> >>> ---------- begin proposed changes >>> >>> class Eq a where >>> (==), (/=) :: a -> a -> Bool >>> x /= y = not (x == y) >>> x == y = not (x /= y) >>> >>> The 'Eq' class defines equality ('==') and inequality ('/='). >>> All the basic datatypes exported by the "Prelude" are instances of 'Eq', >>> and 'Eq' may be derived for any datatype whose constituents are also >>> instances of 'Eq'. >>> >>> '==' implements an equivalence relationship where two values comparing >>> equal >>> are considered indistinguishable. A minimal instance of 'Eq' >>> implements either '==' or '/=', and must adhere to the following laws: >>> >>> Reflexivity (x == x = True) >>> Symmetry (x == y = y == x) >>> Transitivity (x == y && y == z = x == z) >>> Substitutivity (x == y = f x == f y) >>> Negation (x /= y = not (x = y) >>> ---------- end proposed changes >>> >>> On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel >>> wrote: >>> > >>> > >>> > >>> > >>> > >>> > On Wed, Feb 6, 2019 at 9:43 PM chessai . >>> wrote: >>> >> >>> >> Per GHC.Classes (haddock-viewable from Data.Ord) >>> >> >>> >> "The Haskell Report defines no laws for Ord. However, <= is >>> >> customarily expected to implement a non-strict partial order and have >>> >> the following properties:" >>> >> >>> >> I propose that in the next report that the expected typeclass laws for >>> >> Ord be added. They're generally agreed upon/understood. >>> > >>> > >>> > >>> > Can you spell out the concrete change to the report wording you're >>> suggesting? For reference, the current wording used in the 2010 Haskell >>> Report is quoted below. While at it, you might also want to take into >>> account the `Eq` class definition in the report. >>> > >>> > >>> > 6.3.2 The Ord Class >>> > >>> > class (Eq a) => Ord a where >>> > compare :: a -> a -> Ordering >>> > (<), (<=), (>=), (>) :: a -> a -> Bool >>> > max, min :: a -> a -> a >>> > >>> > compare x y | x == y = EQ >>> > | x <= y = LT >>> > | otherwise = GT >>> > >>> > x <= y = compare x y /= GT >>> > x < y = compare x y == LT >>> > x >= y = compare x y /= LT >>> > x > y = compare x y == GT >>> > >>> > -- Note that (min x y, max x y) = (x,y) or (y,x) >>> > max x y | x <= y = y >>> > | otherwise = x >>> > min x y | x <= y = x >>> > | otherwise = y >>> > >>> > The Ord class is used for totally ordered datatypes. All basic >>> datatypes except for functions, IO, and IOError, are instances of this >>> class. Instances of Ord can be derived for any user-defined datatype whose >>> constituent types are in Ord. The declared order of the constructors in the >>> data declaration determines the ordering in derived Ord instances. The >>> Ordering datatype allows a single comparison to determine the precise >>> ordering of two objects. >>> > >>> > The default declarations allow a user to create an Ord instance either >>> with a type-specific compare function or with type-specific == and <= >>> functions. >>> > >>> > >>> > >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 03:46:43 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 6 Feb 2019 22:46:43 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: (and to be even clearer, its definitely something where any help on determining impact and minimizing it would be a pure joy to have ) On Wed, Feb 6, 2019 at 10:42 PM Carter Schonwald wrote: > true, i just actually WANT to fixup those corners of float, assuming > impact can be managed suitably > > On Wed, Feb 6, 2019 at 10:30 PM David Feuer wrote: > >> We can add laws while recognizing that some existing instances are not >> lawful. >> >> On Wed, Feb 6, 2019, 9:43 PM Carter Schonwald > wrote: >> >>> We cant add laws at the moment unless we change how the Ord instances >>> for Float and Double are defined. (which i think SHOULd happen, but needs >>> some care and has lots of implications) >>> >>> there are several possible semantics we can choose that act as we expect >>> on +/- infity and finite floats, but differ in the handling of nans >>> >>> option 1) use the total order defined in floating point standard 2008, >>> section 5.10, which defines negative nans below -infity, positive nans >>> above +infty >>> (this has the nice property that you could check for not nan by >>> -infty <= x && x <= infty) >>> >>> option 2) shift haskell/ GHC to having signalling NAN semantics by >>> default, so the only "fully evaluated" floating point values are in the >>> interval from negative to positive infinity , >>> >>> option 3) some mixture of the above >>> >>> I am slowly doing some patches to improve floating point bits in ghc >>> (and pave the way towards doing something like one of the above), though >>> theres still much to do >>> >>> also: the current definitions of min/max via compare aren't commutative >>> if either argument is nan (they become right biased or left biased, i >>> forget which) >>> >>> http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a >>> copy of ieee floating point 2008 (easy to google up a copy if that link >>> doesnt work) >>> >>> >>> >>> >>> On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: >>> >>>> Sure. There are no explicit mention of the laws of Ord. I think they >>>> should be explicitly stated in the report, perhaps like so: >>>> >>>> ---------- start proposed change >>>> class (Eq a) => Ord a where >>>> compare :: a -> a -> Ordering >>>> (<), (<=), (>), (>=) :: a -> a -> Bool >>>> max, min :: a -> a -> a >>>> >>>> compare x y = if x == y then EQ >>>> else if x <= y then LT >>>> else GT >>>> >>>> x < y = case compare x y of { LT -> True; _ -> False } >>>> x <= y = case compare x y of { GT -> False; _ -> True } >>>> x > y = case compare x y of { GT -> True; _ -> False } >>>> x >= y = case compare x y of { LT -> False; _ -> True } >>>> >>>> max x y = if x <= y then y else x >>>> min x y = if x <= y then x else y >>>> {-# MINIMAL compare | (<=) #-} >>>> >>>> The `Ord` class is used for totally ordered datatypes. Instances of >>>> 'Ord' can be derived for any user-defined datatype whose constituent >>>> types are in 'Ord'. The declared order of the constructors in the data >>>> declaration determines the ordering in the derived 'Ord' instances. >>>> The 'Ordering' datatype allows a single comparison to determine the >>>> precise ordering of two objects. >>>> >>>> A minimal instance of 'Ord' implements either 'compare' or '<=', and >>>> is expected to adhere to the following laws: >>>> >>>> Antisymmetry (a <= b && b <= a = a == b) >>>> Transitivity (a <= b && b <= c = a <= c) >>>> Totality (a <= b || b <= a = True) >>>> >>>> An additional law, Reflexity, is implied by Totality. It states (x <= x >>>> = True). >>>> ---------- end proposed change >>>> >>>> I don't particularly like the bit in the current documentation about >>>> (<=) implementing a non-strict partial ordering, because if (<=) >>>> constitutes a minimal definition of Ord and is required only to be a >>>> partial ordering on the type parameterised by Ord, then why is Ord >>>> required to be a total ordering? That seems sort of confusing. It >>>> seems to me that the current documentation leans more toward 'Ord' >>>> implementing a partial order than a total order. I can't speak for >>>> others, but when I think of 'Ord' I usually think of a total ordering. >>>> >>>> Additionally, Reflexity is strictly weaker than Totality, so >>>> specifying their relationship (Reflexivity is implied by Totality) and >>>> also writing out what Totality means in the context of Ord makes sense >>>> to me. >>>> >>>> For Eq, the report currently states: >>>> >>>> ----------begin report quote >>>> class Eq a where >>>> (==), (/=) :: a -> a -> Bool >>>> >>>> x /= y = not (x == y) >>>> x == y = not (x /= y) >>>> >>>> The Eq class provides equality (==) and inequality (/=) methods. All >>>> basic datatypes except for functions and IO are instances of this >>>> class. Instances of Eq can be derived for any user-defined datatype >>>> whose constituents are also instances of Eq. >>>> >>>> This declaration gives default method declarations for both /= and ==, >>>> each being defined in terms of the other. If an instance declaration >>>> for Eq defines neither == nor /=, then both will loop. If one is >>>> defined, the default method for the other will make use of the one >>>> that is defined. If both are defined, neither default method is used. >>>> ----------end report quote >>>> >>>> I think the following changes make sense: >>>> >>>> ---------- begin proposed changes >>>> >>>> class Eq a where >>>> (==), (/=) :: a -> a -> Bool >>>> x /= y = not (x == y) >>>> x == y = not (x /= y) >>>> >>>> The 'Eq' class defines equality ('==') and inequality ('/='). >>>> All the basic datatypes exported by the "Prelude" are instances of 'Eq', >>>> and 'Eq' may be derived for any datatype whose constituents are also >>>> instances of 'Eq'. >>>> >>>> '==' implements an equivalence relationship where two values comparing >>>> equal >>>> are considered indistinguishable. A minimal instance of 'Eq' >>>> implements either '==' or '/=', and must adhere to the following laws: >>>> >>>> Reflexivity (x == x = True) >>>> Symmetry (x == y = y == x) >>>> Transitivity (x == y && y == z = x == z) >>>> Substitutivity (x == y = f x == f y) >>>> Negation (x /= y = not (x = y) >>>> ---------- end proposed changes >>>> >>>> On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel >>>> wrote: >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > On Wed, Feb 6, 2019 at 9:43 PM chessai . >>>> wrote: >>>> >> >>>> >> Per GHC.Classes (haddock-viewable from Data.Ord) >>>> >> >>>> >> "The Haskell Report defines no laws for Ord. However, <= is >>>> >> customarily expected to implement a non-strict partial order and have >>>> >> the following properties:" >>>> >> >>>> >> I propose that in the next report that the expected typeclass laws >>>> for >>>> >> Ord be added. They're generally agreed upon/understood. >>>> > >>>> > >>>> > >>>> > Can you spell out the concrete change to the report wording you're >>>> suggesting? For reference, the current wording used in the 2010 Haskell >>>> Report is quoted below. While at it, you might also want to take into >>>> account the `Eq` class definition in the report. >>>> > >>>> > >>>> > 6.3.2 The Ord Class >>>> > >>>> > class (Eq a) => Ord a where >>>> > compare :: a -> a -> Ordering >>>> > (<), (<=), (>=), (>) :: a -> a -> Bool >>>> > max, min :: a -> a -> a >>>> > >>>> > compare x y | x == y = EQ >>>> > | x <= y = LT >>>> > | otherwise = GT >>>> > >>>> > x <= y = compare x y /= GT >>>> > x < y = compare x y == LT >>>> > x >= y = compare x y /= LT >>>> > x > y = compare x y == GT >>>> > >>>> > -- Note that (min x y, max x y) = (x,y) or (y,x) >>>> > max x y | x <= y = y >>>> > | otherwise = x >>>> > min x y | x <= y = x >>>> > | otherwise = y >>>> > >>>> > The Ord class is used for totally ordered datatypes. All basic >>>> datatypes except for functions, IO, and IOError, are instances of this >>>> class. Instances of Ord can be derived for any user-defined datatype whose >>>> constituent types are in Ord. The declared order of the constructors in the >>>> data declaration determines the ordering in derived Ord instances. The >>>> Ordering datatype allows a single comparison to determine the precise >>>> ordering of two objects. >>>> > >>>> > The default declarations allow a user to create an Ord instance >>>> either with a type-specific compare function or with type-specific == and >>>> <= functions. >>>> > >>>> > >>>> > >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 05:02:29 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Feb 2019 00:02:29 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: I guess the OTHER important reason is: any code that assumes those putative laws will break horribly on floating point data types in the presence of NAN values for any code that assumes those laws (but only when NANs happen ) On Wed, Feb 6, 2019 at 10:46 PM Carter Schonwald wrote: > (and to be even clearer, its definitely something where any help on > determining impact and minimizing it would be a pure joy to have ) > > On Wed, Feb 6, 2019 at 10:42 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> true, i just actually WANT to fixup those corners of float, assuming >> impact can be managed suitably >> >> On Wed, Feb 6, 2019 at 10:30 PM David Feuer >> wrote: >> >>> We can add laws while recognizing that some existing instances are not >>> lawful. >>> >>> On Wed, Feb 6, 2019, 9:43 PM Carter Schonwald < >>> carter.schonwald at gmail.com wrote: >>> >>>> We cant add laws at the moment unless we change how the Ord instances >>>> for Float and Double are defined. (which i think SHOULd happen, but needs >>>> some care and has lots of implications) >>>> >>>> there are several possible semantics we can choose that act as we >>>> expect on +/- infity and finite floats, but differ in the handling of nans >>>> >>>> option 1) use the total order defined in floating point standard 2008, >>>> section 5.10, which defines negative nans below -infity, positive nans >>>> above +infty >>>> (this has the nice property that you could check for not nan by >>>> -infty <= x && x <= infty) >>>> >>>> option 2) shift haskell/ GHC to having signalling NAN semantics by >>>> default, so the only "fully evaluated" floating point values are in the >>>> interval from negative to positive infinity , >>>> >>>> option 3) some mixture of the above >>>> >>>> I am slowly doing some patches to improve floating point bits in ghc >>>> (and pave the way towards doing something like one of the above), though >>>> theres still much to do >>>> >>>> also: the current definitions of min/max via compare aren't commutative >>>> if either argument is nan (they become right biased or left biased, i >>>> forget which) >>>> >>>> http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a >>>> copy of ieee floating point 2008 (easy to google up a copy if that link >>>> doesnt work) >>>> >>>> >>>> >>>> >>>> On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: >>>> >>>>> Sure. There are no explicit mention of the laws of Ord. I think they >>>>> should be explicitly stated in the report, perhaps like so: >>>>> >>>>> ---------- start proposed change >>>>> class (Eq a) => Ord a where >>>>> compare :: a -> a -> Ordering >>>>> (<), (<=), (>), (>=) :: a -> a -> Bool >>>>> max, min :: a -> a -> a >>>>> >>>>> compare x y = if x == y then EQ >>>>> else if x <= y then LT >>>>> else GT >>>>> >>>>> x < y = case compare x y of { LT -> True; _ -> False } >>>>> x <= y = case compare x y of { GT -> False; _ -> True } >>>>> x > y = case compare x y of { GT -> True; _ -> False } >>>>> x >= y = case compare x y of { LT -> False; _ -> True } >>>>> >>>>> max x y = if x <= y then y else x >>>>> min x y = if x <= y then x else y >>>>> {-# MINIMAL compare | (<=) #-} >>>>> >>>>> The `Ord` class is used for totally ordered datatypes. Instances of >>>>> 'Ord' can be derived for any user-defined datatype whose constituent >>>>> types are in 'Ord'. The declared order of the constructors in the data >>>>> declaration determines the ordering in the derived 'Ord' instances. >>>>> The 'Ordering' datatype allows a single comparison to determine the >>>>> precise ordering of two objects. >>>>> >>>>> A minimal instance of 'Ord' implements either 'compare' or '<=', and >>>>> is expected to adhere to the following laws: >>>>> >>>>> Antisymmetry (a <= b && b <= a = a == b) >>>>> Transitivity (a <= b && b <= c = a <= c) >>>>> Totality (a <= b || b <= a = True) >>>>> >>>>> An additional law, Reflexity, is implied by Totality. It states (x <= >>>>> x = True). >>>>> ---------- end proposed change >>>>> >>>>> I don't particularly like the bit in the current documentation about >>>>> (<=) implementing a non-strict partial ordering, because if (<=) >>>>> constitutes a minimal definition of Ord and is required only to be a >>>>> partial ordering on the type parameterised by Ord, then why is Ord >>>>> required to be a total ordering? That seems sort of confusing. It >>>>> seems to me that the current documentation leans more toward 'Ord' >>>>> implementing a partial order than a total order. I can't speak for >>>>> others, but when I think of 'Ord' I usually think of a total ordering. >>>>> >>>>> Additionally, Reflexity is strictly weaker than Totality, so >>>>> specifying their relationship (Reflexivity is implied by Totality) and >>>>> also writing out what Totality means in the context of Ord makes sense >>>>> to me. >>>>> >>>>> For Eq, the report currently states: >>>>> >>>>> ----------begin report quote >>>>> class Eq a where >>>>> (==), (/=) :: a -> a -> Bool >>>>> >>>>> x /= y = not (x == y) >>>>> x == y = not (x /= y) >>>>> >>>>> The Eq class provides equality (==) and inequality (/=) methods. All >>>>> basic datatypes except for functions and IO are instances of this >>>>> class. Instances of Eq can be derived for any user-defined datatype >>>>> whose constituents are also instances of Eq. >>>>> >>>>> This declaration gives default method declarations for both /= and ==, >>>>> each being defined in terms of the other. If an instance declaration >>>>> for Eq defines neither == nor /=, then both will loop. If one is >>>>> defined, the default method for the other will make use of the one >>>>> that is defined. If both are defined, neither default method is used. >>>>> ----------end report quote >>>>> >>>>> I think the following changes make sense: >>>>> >>>>> ---------- begin proposed changes >>>>> >>>>> class Eq a where >>>>> (==), (/=) :: a -> a -> Bool >>>>> x /= y = not (x == y) >>>>> x == y = not (x /= y) >>>>> >>>>> The 'Eq' class defines equality ('==') and inequality ('/='). >>>>> All the basic datatypes exported by the "Prelude" are instances of >>>>> 'Eq', >>>>> and 'Eq' may be derived for any datatype whose constituents are also >>>>> instances of 'Eq'. >>>>> >>>>> '==' implements an equivalence relationship where two values comparing >>>>> equal >>>>> are considered indistinguishable. A minimal instance of 'Eq' >>>>> implements either '==' or '/=', and must adhere to the following laws: >>>>> >>>>> Reflexivity (x == x = True) >>>>> Symmetry (x == y = y == x) >>>>> Transitivity (x == y && y == z = x == z) >>>>> Substitutivity (x == y = f x == f y) >>>>> Negation (x /= y = not (x = y) >>>>> ---------- end proposed changes >>>>> >>>>> On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel >>>>> wrote: >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > On Wed, Feb 6, 2019 at 9:43 PM chessai . >>>>> wrote: >>>>> >> >>>>> >> Per GHC.Classes (haddock-viewable from Data.Ord) >>>>> >> >>>>> >> "The Haskell Report defines no laws for Ord. However, <= is >>>>> >> customarily expected to implement a non-strict partial order and >>>>> have >>>>> >> the following properties:" >>>>> >> >>>>> >> I propose that in the next report that the expected typeclass laws >>>>> for >>>>> >> Ord be added. They're generally agreed upon/understood. >>>>> > >>>>> > >>>>> > >>>>> > Can you spell out the concrete change to the report wording you're >>>>> suggesting? For reference, the current wording used in the 2010 Haskell >>>>> Report is quoted below. While at it, you might also want to take into >>>>> account the `Eq` class definition in the report. >>>>> > >>>>> > >>>>> > 6.3.2 The Ord Class >>>>> > >>>>> > class (Eq a) => Ord a where >>>>> > compare :: a -> a -> Ordering >>>>> > (<), (<=), (>=), (>) :: a -> a -> Bool >>>>> > max, min :: a -> a -> a >>>>> > >>>>> > compare x y | x == y = EQ >>>>> > | x <= y = LT >>>>> > | otherwise = GT >>>>> > >>>>> > x <= y = compare x y /= GT >>>>> > x < y = compare x y == LT >>>>> > x >= y = compare x y /= LT >>>>> > x > y = compare x y == GT >>>>> > >>>>> > -- Note that (min x y, max x y) = (x,y) or (y,x) >>>>> > max x y | x <= y = y >>>>> > | otherwise = x >>>>> > min x y | x <= y = x >>>>> > | otherwise = y >>>>> > >>>>> > The Ord class is used for totally ordered datatypes. All basic >>>>> datatypes except for functions, IO, and IOError, are instances of this >>>>> class. Instances of Ord can be derived for any user-defined datatype whose >>>>> constituent types are in Ord. The declared order of the constructors in the >>>>> data declaration determines the ordering in derived Ord instances. The >>>>> Ordering datatype allows a single comparison to determine the precise >>>>> ordering of two objects. >>>>> > >>>>> > The default declarations allow a user to create an Ord instance >>>>> either with a type-specific compare function or with type-specific == and >>>>> <= functions. >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Thu Feb 7 13:08:45 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Thu, 7 Feb 2019 08:08:45 -0500 Subject: Calling the callback when event registration fails In-Reply-To: References: Message-ID: Here's the relevant code from GHC's event manager: modifyFd :: KQueue -> Fd -> E.Event -> E.Event -> IO Bool modifyFd kq fd oevt nevt = kqueueControl (kqueueFd kq) evs where evs | nevt == mempty = toEvents fd (toFilter oevt) flagDelete noteEOF | otherwise = toEvents fd (toFilter nevt) flagAdd noteEOF modifyFdOnce :: KQueue -> Fd -> E.Event -> IO Bool modifyFdOnce kq fd evt = kqueueControl (kqueueFd kq) (toEvents fd (toFilter evt) (flagAdd .|. flagOneshot) noteEOF) kqueueControl :: KQueueFd -> [Event] -> IO Bool kqueueControl kfd evts = withTimeSpec (TimeSpec 0 0) $ \tp -> withArrayLen evts $ \evlen evp -> do res <- kevent False kfd evp evlen nullPtr 0 tp if res == -1 then do err <- getErrno case err of _ | err == eINTR -> return True _ | err == eINVAL -> return False _ | err == eNOTSUP -> return False _ -> throwErrno "kevent" And the kevent haskell function just wraps C's kevent function. Here's FreeBSD's docs on the two relevant error codes: [EINVAL] The specified time limit or filter is invalid. There is no similar documentation for ENOTSUP. I also found this in the mailing list archive: https://mail.haskell.org/pipermail/ghc-devs/2013-March/000798.html. It confirms my suspicions. Immediately calling the callback when event registration fails leads to undesirable behavior. The caller of threadWaitRead will think that a file description is ready for a read when it really isn't, and then whatever buffer-copying uninterruptible FFI call they perform next will potentially block the runtime. The linked thread suggests a fix (fallback on select when kqueue doesn't work). What's weird is that the EPoll backend just throws an exception when it gets an error like this. Maybe it would be more honest to make the kqueue backend do the same. On Wed, Feb 6, 2019 at 8:56 PM Carter Schonwald wrote: > under what circumstances would those failure modes happen where the > process can still run? (if need be, i can help you dig into the *BSD code > bases if we aren't sure when the kqueue code would do that) > > On Wed, Feb 6, 2019 at 7:10 PM Andrew Martin > wrote: > >> Digging through the different backends, it looks like only the kqueue >> backend is even capable of returning False when modifyFd/modifyFdOnce is >> called. This happens when kevent returns eINTR or eINVAL. Why do we call >> the callback here instead of just throwing an error like we do in so many >> other cases? >> >> On Wed, Feb 6, 2019 at 5:44 PM Andrew Martin >> wrote: >> >>> In the event manager's registerFd_, we find: >>> >>> registerFd_ :: EventManager -> IOCallback -> Fd -> Event -> Lifetime >>> -> IO (FdKey, Bool) >>> registerFd_ mgr@(EventManager{..}) cb !fd !evs lt = do >>> ... <- ... >>> (modify,ok) <- withMVar (callbackTableVar mgr fd) $ \tbl -> do >>> ... <- ... >>> -- this simulates behavior of old IO manager: >>> -- i.e. just call the callback if the registration fails. >>> when (not ok) (cb reg evs) >>> return (reg,modify) >>> >>> A comment and a question. Comment: registerFd_ is only ever called in >>> contexts where exceptions are masked, so withMVar is doing some needless >>> mask/restore. Question: why do we immidiately call the callback if event >>> registration fails? This means that if event registration fails during >>> something like `threadWaitRead`, the end result would be that >>> `threadWaitRead` would just return immidiately. That doesn't seem good. >>> >>> -- >>> -Andrew Thaddeus Martin >>> >> >> >> -- >> -Andrew Thaddeus Martin >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Thu Feb 7 15:14:40 2019 From: chessai1996 at gmail.com (chessai .) Date: Thu, 7 Feb 2019 10:14:40 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: Yeah, Float/Double are always a problem when it comes to Ord. I think it might be best to just acknowledge their unlawfulness. It's unfortunate that they have Ord instances at all, IMO, but at this point there's no changing that. On Thu, Feb 7, 2019 at 12:02 AM Carter Schonwald wrote: > > I guess the OTHER important reason is: any code that assumes those putative laws will break horribly on floating point data types in the presence of NAN values for any code that assumes those laws (but only when NANs happen ) > > On Wed, Feb 6, 2019 at 10:46 PM Carter Schonwald wrote: >> >> (and to be even clearer, its definitely something where any help on determining impact and minimizing it would be a pure joy to have ) >> >> On Wed, Feb 6, 2019 at 10:42 PM Carter Schonwald wrote: >>> >>> true, i just actually WANT to fixup those corners of float, assuming impact can be managed suitably >>> >>> On Wed, Feb 6, 2019 at 10:30 PM David Feuer wrote: >>>> >>>> We can add laws while recognizing that some existing instances are not lawful. >>>> >>>> On Wed, Feb 6, 2019, 9:43 PM Carter Schonwald >>>> >>>>> We cant add laws at the moment unless we change how the Ord instances for Float and Double are defined. (which i think SHOULd happen, but needs some care and has lots of implications) >>>>> >>>>> there are several possible semantics we can choose that act as we expect on +/- infity and finite floats, but differ in the handling of nans >>>>> >>>>> option 1) use the total order defined in floating point standard 2008, section 5.10, which defines negative nans below -infity, positive nans above +infty >>>>> (this has the nice property that you could check for not nan by -infty <= x && x <= infty) >>>>> >>>>> option 2) shift haskell/ GHC to having signalling NAN semantics by default, so the only "fully evaluated" floating point values are in the interval from negative to positive infinity , >>>>> >>>>> option 3) some mixture of the above >>>>> >>>>> I am slowly doing some patches to improve floating point bits in ghc (and pave the way towards doing something like one of the above), though theres still much to do >>>>> >>>>> also: the current definitions of min/max via compare aren't commutative if either argument is nan (they become right biased or left biased, i forget which) >>>>> >>>>> http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a copy of ieee floating point 2008 (easy to google up a copy if that link doesnt work) >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: >>>>>> >>>>>> Sure. There are no explicit mention of the laws of Ord. I think they >>>>>> should be explicitly stated in the report, perhaps like so: >>>>>> >>>>>> ---------- start proposed change >>>>>> class (Eq a) => Ord a where >>>>>> compare :: a -> a -> Ordering >>>>>> (<), (<=), (>), (>=) :: a -> a -> Bool >>>>>> max, min :: a -> a -> a >>>>>> >>>>>> compare x y = if x == y then EQ >>>>>> else if x <= y then LT >>>>>> else GT >>>>>> >>>>>> x < y = case compare x y of { LT -> True; _ -> False } >>>>>> x <= y = case compare x y of { GT -> False; _ -> True } >>>>>> x > y = case compare x y of { GT -> True; _ -> False } >>>>>> x >= y = case compare x y of { LT -> False; _ -> True } >>>>>> >>>>>> max x y = if x <= y then y else x >>>>>> min x y = if x <= y then x else y >>>>>> {-# MINIMAL compare | (<=) #-} >>>>>> >>>>>> The `Ord` class is used for totally ordered datatypes. Instances of >>>>>> 'Ord' can be derived for any user-defined datatype whose constituent >>>>>> types are in 'Ord'. The declared order of the constructors in the data >>>>>> declaration determines the ordering in the derived 'Ord' instances. >>>>>> The 'Ordering' datatype allows a single comparison to determine the >>>>>> precise ordering of two objects. >>>>>> >>>>>> A minimal instance of 'Ord' implements either 'compare' or '<=', and >>>>>> is expected to adhere to the following laws: >>>>>> >>>>>> Antisymmetry (a <= b && b <= a = a == b) >>>>>> Transitivity (a <= b && b <= c = a <= c) >>>>>> Totality (a <= b || b <= a = True) >>>>>> >>>>>> An additional law, Reflexity, is implied by Totality. It states (x <= x = True). >>>>>> ---------- end proposed change >>>>>> >>>>>> I don't particularly like the bit in the current documentation about >>>>>> (<=) implementing a non-strict partial ordering, because if (<=) >>>>>> constitutes a minimal definition of Ord and is required only to be a >>>>>> partial ordering on the type parameterised by Ord, then why is Ord >>>>>> required to be a total ordering? That seems sort of confusing. It >>>>>> seems to me that the current documentation leans more toward 'Ord' >>>>>> implementing a partial order than a total order. I can't speak for >>>>>> others, but when I think of 'Ord' I usually think of a total ordering. >>>>>> >>>>>> Additionally, Reflexity is strictly weaker than Totality, so >>>>>> specifying their relationship (Reflexivity is implied by Totality) and >>>>>> also writing out what Totality means in the context of Ord makes sense >>>>>> to me. >>>>>> >>>>>> For Eq, the report currently states: >>>>>> >>>>>> ----------begin report quote >>>>>> class Eq a where >>>>>> (==), (/=) :: a -> a -> Bool >>>>>> >>>>>> x /= y = not (x == y) >>>>>> x == y = not (x /= y) >>>>>> >>>>>> The Eq class provides equality (==) and inequality (/=) methods. All >>>>>> basic datatypes except for functions and IO are instances of this >>>>>> class. Instances of Eq can be derived for any user-defined datatype >>>>>> whose constituents are also instances of Eq. >>>>>> >>>>>> This declaration gives default method declarations for both /= and ==, >>>>>> each being defined in terms of the other. If an instance declaration >>>>>> for Eq defines neither == nor /=, then both will loop. If one is >>>>>> defined, the default method for the other will make use of the one >>>>>> that is defined. If both are defined, neither default method is used. >>>>>> ----------end report quote >>>>>> >>>>>> I think the following changes make sense: >>>>>> >>>>>> ---------- begin proposed changes >>>>>> >>>>>> class Eq a where >>>>>> (==), (/=) :: a -> a -> Bool >>>>>> x /= y = not (x == y) >>>>>> x == y = not (x /= y) >>>>>> >>>>>> The 'Eq' class defines equality ('==') and inequality ('/='). >>>>>> All the basic datatypes exported by the "Prelude" are instances of 'Eq', >>>>>> and 'Eq' may be derived for any datatype whose constituents are also >>>>>> instances of 'Eq'. >>>>>> >>>>>> '==' implements an equivalence relationship where two values comparing equal >>>>>> are considered indistinguishable. A minimal instance of 'Eq' >>>>>> implements either '==' or '/=', and must adhere to the following laws: >>>>>> >>>>>> Reflexivity (x == x = True) >>>>>> Symmetry (x == y = y == x) >>>>>> Transitivity (x == y && y == z = x == z) >>>>>> Substitutivity (x == y = f x == f y) >>>>>> Negation (x /= y = not (x = y) >>>>>> ---------- end proposed changes >>>>>> >>>>>> On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel >>>>>> wrote: >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Wed, Feb 6, 2019 at 9:43 PM chessai . wrote: >>>>>> >> >>>>>> >> Per GHC.Classes (haddock-viewable from Data.Ord) >>>>>> >> >>>>>> >> "The Haskell Report defines no laws for Ord. However, <= is >>>>>> >> customarily expected to implement a non-strict partial order and have >>>>>> >> the following properties:" >>>>>> >> >>>>>> >> I propose that in the next report that the expected typeclass laws for >>>>>> >> Ord be added. They're generally agreed upon/understood. >>>>>> > >>>>>> > >>>>>> > >>>>>> > Can you spell out the concrete change to the report wording you're suggesting? For reference, the current wording used in the 2010 Haskell Report is quoted below. While at it, you might also want to take into account the `Eq` class definition in the report. >>>>>> > >>>>>> > >>>>>> > 6.3.2 The Ord Class >>>>>> > >>>>>> > class (Eq a) => Ord a where >>>>>> > compare :: a -> a -> Ordering >>>>>> > (<), (<=), (>=), (>) :: a -> a -> Bool >>>>>> > max, min :: a -> a -> a >>>>>> > >>>>>> > compare x y | x == y = EQ >>>>>> > | x <= y = LT >>>>>> > | otherwise = GT >>>>>> > >>>>>> > x <= y = compare x y /= GT >>>>>> > x < y = compare x y == LT >>>>>> > x >= y = compare x y /= LT >>>>>> > x > y = compare x y == GT >>>>>> > >>>>>> > -- Note that (min x y, max x y) = (x,y) or (y,x) >>>>>> > max x y | x <= y = y >>>>>> > | otherwise = x >>>>>> > min x y | x <= y = x >>>>>> > | otherwise = y >>>>>> > >>>>>> > The Ord class is used for totally ordered datatypes. All basic datatypes except for functions, IO, and IOError, are instances of this class. Instances of Ord can be derived for any user-defined datatype whose constituent types are in Ord. The declared order of the constructors in the data declaration determines the ordering in derived Ord instances. The Ordering datatype allows a single comparison to determine the precise ordering of two objects. >>>>>> > >>>>>> > The default declarations allow a user to create an Ord instance either with a type-specific compare function or with type-specific == and <= functions. >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From merijn at inconsistent.nl Thu Feb 7 15:45:17 2019 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Thu, 7 Feb 2019 16:45:17 +0100 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: I was discussing this with Carter on IRC, so to chime in with my two cents: I think the default behaviour for Float/Double should use a trapping NaN. The current value NaN is as if every Double value has an implicit "fromJust" and finding out which part of larger computations/pipelines introduced the NaNs in your output is a pain. Trapping NaN would also eliminate the brokenness of Ord. If some people are really attached to value NaNs (why?!? What's wrong with you?) we could allow disabling trapping at compile or runtime so they get the old behaviour. Cheers, Merijn > On 7 Feb 2019, at 03:43, Carter Schonwald wrote: > > We cant add laws at the moment unless we change how the Ord instances for Float and Double are defined. (which i think SHOULd happen, but needs some care and has lots of implications) > > there are several possible semantics we can choose that act as we expect on +/- infity and finite floats, but differ in the handling of nans > > option 1) use the total order defined in floating point standard 2008, section 5.10, which defines negative nans below -infity, positive nans above +infty > (this has the nice property that you could check for not nan by -infty <= x && x <= infty) > > option 2) shift haskell/ GHC to having signalling NAN semantics by default, so the only "fully evaluated" floating point values are in the interval from negative to positive infinity , > > option 3) some mixture of the above > > I am slowly doing some patches to improve floating point bits in ghc (and pave the way towards doing something like one of the above), though theres still much to do > > also: the current definitions of min/max via compare aren't commutative if either argument is nan (they become right biased or left biased, i forget which) > > http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a copy of ieee floating point 2008 (easy to google up a copy if that link doesnt work) > > > > > On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: > Sure. There are no explicit mention of the laws of Ord. I think they > should be explicitly stated in the report, perhaps like so: > > ---------- start proposed change > class (Eq a) => Ord a where > compare :: a -> a -> Ordering > (<), (<=), (>), (>=) :: a -> a -> Bool > max, min :: a -> a -> a > > compare x y = if x == y then EQ > else if x <= y then LT > else GT > > x < y = case compare x y of { LT -> True; _ -> False } > x <= y = case compare x y of { GT -> False; _ -> True } > x > y = case compare x y of { GT -> True; _ -> False } > x >= y = case compare x y of { LT -> False; _ -> True } > > max x y = if x <= y then y else x > min x y = if x <= y then x else y > {-# MINIMAL compare | (<=) #-} > > The `Ord` class is used for totally ordered datatypes. Instances of > 'Ord' can be derived for any user-defined datatype whose constituent > types are in 'Ord'. The declared order of the constructors in the data > declaration determines the ordering in the derived 'Ord' instances. > The 'Ordering' datatype allows a single comparison to determine the > precise ordering of two objects. > > A minimal instance of 'Ord' implements either 'compare' or '<=', and > is expected to adhere to the following laws: > > Antisymmetry (a <= b && b <= a = a == b) > Transitivity (a <= b && b <= c = a <= c) > Totality (a <= b || b <= a = True) > > An additional law, Reflexity, is implied by Totality. It states (x <= x = True). > ---------- end proposed change > > I don't particularly like the bit in the current documentation about > (<=) implementing a non-strict partial ordering, because if (<=) > constitutes a minimal definition of Ord and is required only to be a > partial ordering on the type parameterised by Ord, then why is Ord > required to be a total ordering? That seems sort of confusing. It > seems to me that the current documentation leans more toward 'Ord' > implementing a partial order than a total order. I can't speak for > others, but when I think of 'Ord' I usually think of a total ordering. > > Additionally, Reflexity is strictly weaker than Totality, so > specifying their relationship (Reflexivity is implied by Totality) and > also writing out what Totality means in the context of Ord makes sense > to me. > > For Eq, the report currently states: > > ----------begin report quote > class Eq a where > (==), (/=) :: a -> a -> Bool > > x /= y = not (x == y) > x == y = not (x /= y) > > The Eq class provides equality (==) and inequality (/=) methods. All > basic datatypes except for functions and IO are instances of this > class. Instances of Eq can be derived for any user-defined datatype > whose constituents are also instances of Eq. > > This declaration gives default method declarations for both /= and ==, > each being defined in terms of the other. If an instance declaration > for Eq defines neither == nor /=, then both will loop. If one is > defined, the default method for the other will make use of the one > that is defined. If both are defined, neither default method is used. > ----------end report quote > > I think the following changes make sense: > > ---------- begin proposed changes > > class Eq a where > (==), (/=) :: a -> a -> Bool > x /= y = not (x == y) > x == y = not (x /= y) > > The 'Eq' class defines equality ('==') and inequality ('/='). > All the basic datatypes exported by the "Prelude" are instances of 'Eq', > and 'Eq' may be derived for any datatype whose constituents are also > instances of 'Eq'. > > '==' implements an equivalence relationship where two values comparing equal > are considered indistinguishable. A minimal instance of 'Eq' > implements either '==' or '/=', and must adhere to the following laws: > > Reflexivity (x == x = True) > Symmetry (x == y = y == x) > Transitivity (x == y && y == z = x == z) > Substitutivity (x == y = f x == f y) > Negation (x /= y = not (x = y) > ---------- end proposed changes > > On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel > wrote: > > > > > > > > > > > > On Wed, Feb 6, 2019 at 9:43 PM chessai . wrote: > >> > >> Per GHC.Classes (haddock-viewable from Data.Ord) > >> > >> "The Haskell Report defines no laws for Ord. However, <= is > >> customarily expected to implement a non-strict partial order and have > >> the following properties:" > >> > >> I propose that in the next report that the expected typeclass laws for > >> Ord be added. They're generally agreed upon/understood. > > > > > > > > Can you spell out the concrete change to the report wording you're suggesting? For reference, the current wording used in the 2010 Haskell Report is quoted below. While at it, you might also want to take into account the `Eq` class definition in the report. > > > > > > 6.3.2 The Ord Class > > > > class (Eq a) => Ord a where > > compare :: a -> a -> Ordering > > (<), (<=), (>=), (>) :: a -> a -> Bool > > max, min :: a -> a -> a > > > > compare x y | x == y = EQ > > | x <= y = LT > > | otherwise = GT > > > > x <= y = compare x y /= GT > > x < y = compare x y == LT > > x >= y = compare x y /= LT > > x > y = compare x y == GT > > > > -- Note that (min x y, max x y) = (x,y) or (y,x) > > max x y | x <= y = y > > | otherwise = x > > min x y | x <= y = x > > | otherwise = y > > > > The Ord class is used for totally ordered datatypes. All basic datatypes except for functions, IO, and IOError, are instances of this class. Instances of Ord can be derived for any user-defined datatype whose constituent types are in Ord. The declared order of the constructors in the data declaration determines the ordering in derived Ord instances. The Ordering datatype allows a single comparison to determine the precise ordering of two objects. > > > > The default declarations allow a user to create an Ord instance either with a type-specific compare function or with type-specific == and <= functions. > > > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From eacameron at gmail.com Thu Feb 7 16:21:11 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Thu, 7 Feb 2019 11:21:11 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: While I'm sure it would be a lot of churn, couldn't we introduce a `TotalOrd` class and guard it more carefully? On Thu, Feb 7, 2019 at 10:45 AM Merijn Verstraaten wrote: > I was discussing this with Carter on IRC, so to chime in with my two cents: > > I think the default behaviour for Float/Double should use a trapping NaN. > The current value NaN is as if every Double value has an implicit > "fromJust" and finding out which part of larger computations/pipelines > introduced the NaNs in your output is a pain. > > Trapping NaN would also eliminate the brokenness of Ord. If some people > are really attached to value NaNs (why?!? What's wrong with you?) we could > allow disabling trapping at compile or runtime so they get the old > behaviour. > > Cheers, > Merijn > > > On 7 Feb 2019, at 03:43, Carter Schonwald > wrote: > > > > We cant add laws at the moment unless we change how the Ord instances > for Float and Double are defined. (which i think SHOULd happen, but needs > some care and has lots of implications) > > > > there are several possible semantics we can choose that act as we expect > on +/- infity and finite floats, but differ in the handling of nans > > > > option 1) use the total order defined in floating point standard 2008, > section 5.10, which defines negative nans below -infity, positive nans > above +infty > > (this has the nice property that you could check for not nan by > -infty <= x && x <= infty) > > > > option 2) shift haskell/ GHC to having signalling NAN semantics by > default, so the only "fully evaluated" floating point values are in the > interval from negative to positive infinity , > > > > option 3) some mixture of the above > > > > I am slowly doing some patches to improve floating point bits in ghc > (and pave the way towards doing something like one of the above), though > theres still much to do > > > > also: the current definitions of min/max via compare aren't commutative > if either argument is nan (they become right biased or left biased, i > forget which) > > > > http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a > copy of ieee floating point 2008 (easy to google up a copy if that link > doesnt work) > > > > > > > > > > On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: > > Sure. There are no explicit mention of the laws of Ord. I think they > > should be explicitly stated in the report, perhaps like so: > > > > ---------- start proposed change > > class (Eq a) => Ord a where > > compare :: a -> a -> Ordering > > (<), (<=), (>), (>=) :: a -> a -> Bool > > max, min :: a -> a -> a > > > > compare x y = if x == y then EQ > > else if x <= y then LT > > else GT > > > > x < y = case compare x y of { LT -> True; _ -> False } > > x <= y = case compare x y of { GT -> False; _ -> True } > > x > y = case compare x y of { GT -> True; _ -> False } > > x >= y = case compare x y of { LT -> False; _ -> True } > > > > max x y = if x <= y then y else x > > min x y = if x <= y then x else y > > {-# MINIMAL compare | (<=) #-} > > > > The `Ord` class is used for totally ordered datatypes. Instances of > > 'Ord' can be derived for any user-defined datatype whose constituent > > types are in 'Ord'. The declared order of the constructors in the data > > declaration determines the ordering in the derived 'Ord' instances. > > The 'Ordering' datatype allows a single comparison to determine the > > precise ordering of two objects. > > > > A minimal instance of 'Ord' implements either 'compare' or '<=', and > > is expected to adhere to the following laws: > > > > Antisymmetry (a <= b && b <= a = a == b) > > Transitivity (a <= b && b <= c = a <= c) > > Totality (a <= b || b <= a = True) > > > > An additional law, Reflexity, is implied by Totality. It states (x <= x > = True). > > ---------- end proposed change > > > > I don't particularly like the bit in the current documentation about > > (<=) implementing a non-strict partial ordering, because if (<=) > > constitutes a minimal definition of Ord and is required only to be a > > partial ordering on the type parameterised by Ord, then why is Ord > > required to be a total ordering? That seems sort of confusing. It > > seems to me that the current documentation leans more toward 'Ord' > > implementing a partial order than a total order. I can't speak for > > others, but when I think of 'Ord' I usually think of a total ordering. > > > > Additionally, Reflexity is strictly weaker than Totality, so > > specifying their relationship (Reflexivity is implied by Totality) and > > also writing out what Totality means in the context of Ord makes sense > > to me. > > > > For Eq, the report currently states: > > > > ----------begin report quote > > class Eq a where > > (==), (/=) :: a -> a -> Bool > > > > x /= y = not (x == y) > > x == y = not (x /= y) > > > > The Eq class provides equality (==) and inequality (/=) methods. All > > basic datatypes except for functions and IO are instances of this > > class. Instances of Eq can be derived for any user-defined datatype > > whose constituents are also instances of Eq. > > > > This declaration gives default method declarations for both /= and ==, > > each being defined in terms of the other. If an instance declaration > > for Eq defines neither == nor /=, then both will loop. If one is > > defined, the default method for the other will make use of the one > > that is defined. If both are defined, neither default method is used. > > ----------end report quote > > > > I think the following changes make sense: > > > > ---------- begin proposed changes > > > > class Eq a where > > (==), (/=) :: a -> a -> Bool > > x /= y = not (x == y) > > x == y = not (x /= y) > > > > The 'Eq' class defines equality ('==') and inequality ('/='). > > All the basic datatypes exported by the "Prelude" are instances of 'Eq', > > and 'Eq' may be derived for any datatype whose constituents are also > > instances of 'Eq'. > > > > '==' implements an equivalence relationship where two values comparing > equal > > are considered indistinguishable. A minimal instance of 'Eq' > > implements either '==' or '/=', and must adhere to the following laws: > > > > Reflexivity (x == x = True) > > Symmetry (x == y = y == x) > > Transitivity (x == y && y == z = x == z) > > Substitutivity (x == y = f x == f y) > > Negation (x /= y = not (x = y) > > ---------- end proposed changes > > > > On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Feb 6, 2019 at 9:43 PM chessai . > wrote: > > >> > > >> Per GHC.Classes (haddock-viewable from Data.Ord) > > >> > > >> "The Haskell Report defines no laws for Ord. However, <= is > > >> customarily expected to implement a non-strict partial order and have > > >> the following properties:" > > >> > > >> I propose that in the next report that the expected typeclass laws for > > >> Ord be added. They're generally agreed upon/understood. > > > > > > > > > > > > Can you spell out the concrete change to the report wording you're > suggesting? For reference, the current wording used in the 2010 Haskell > Report is quoted below. While at it, you might also want to take into > account the `Eq` class definition in the report. > > > > > > > > > 6.3.2 The Ord Class > > > > > > class (Eq a) => Ord a where > > > compare :: a -> a -> Ordering > > > (<), (<=), (>=), (>) :: a -> a -> Bool > > > max, min :: a -> a -> a > > > > > > compare x y | x == y = EQ > > > | x <= y = LT > > > | otherwise = GT > > > > > > x <= y = compare x y /= GT > > > x < y = compare x y == LT > > > x >= y = compare x y /= LT > > > x > y = compare x y == GT > > > > > > -- Note that (min x y, max x y) = (x,y) or (y,x) > > > max x y | x <= y = y > > > | otherwise = x > > > min x y | x <= y = x > > > | otherwise = y > > > > > > The Ord class is used for totally ordered datatypes. All basic > datatypes except for functions, IO, and IOError, are instances of this > class. Instances of Ord can be derived for any user-defined datatype whose > constituent types are in Ord. The declared order of the constructors in the > data declaration determines the ordering in derived Ord instances. The > Ordering datatype allows a single comparison to determine the precise > ordering of two objects. > > > > > > The default declarations allow a user to create an Ord instance either > with a type-specific compare function or with type-specific == and <= > functions. > > > > > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Feb 7 16:22:23 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 7 Feb 2019 17:22:23 +0100 (CET) Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: On Thu, 7 Feb 2019, Merijn Verstraaten wrote: > I think the default behaviour for Float/Double should use a trapping > NaN. The current value NaN is as if every Double value has an implicit > "fromJust" I like to think of it like all operations are lifted to (Maybe Float). > Trapping NaN would also eliminate the brokenness of Ord. If some people > are really attached to value NaNs (why?!? What's wrong with you?) we > could allow disabling trapping at compile or runtime so they get the old > behaviour. What about calling into foreign code? If I call a BLAS routine and one element of the result vector is NaN, shall this be trapped? Or shall it be trapped once I access the NaN element? From svenpanne at gmail.com Thu Feb 7 17:04:51 2019 From: svenpanne at gmail.com (Sven Panne) Date: Thu, 7 Feb 2019 18:04:51 +0100 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: Am Do., 7. Feb. 2019 um 17:22 Uhr schrieb Henning Thielemann < lemming at henning-thielemann.de>: > [...] What about calling into foreign code? If I call a BLAS routine and > one > element of the result vector is NaN, shall this be trapped? Or shall it be > trapped once I access the NaN element? > IMHO this is the biggest show stopper for some exotic NaN handling, as correct as it may be mathematically or aesthetically: The floating point environment is a thread-local (i.e. basically global) entity on most platforms, and most programming language runtimes expect a "default" environment, i.e. no traps when NaNs are encountered. So if Haskell wants to do things differently, the FPE has to be set/reset around foreign calls and for around every Haskell callback. I am not sure if this is really worth the trouble and the performance loss. For some special applications it might be OK or even important, but my gut feeling is that trapping NaNs is the wrong default in our current world... -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 21:27:53 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Feb 2019 16:27:53 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: @sven and @henning : i'm actually doing some preliminary work to add save and restore for FPU state to the GHC RTS, at the green/haskell thread layer. after first ripping out x87 code gen, which just needs some more docs written out before its merged in. note that i'm speaking specifically of the MXCSR register save and restore, not the more hefty operations you might be thinking. FPU mode state save and restore is done already on EVERY OS when switching threads/processes, and in the agner fog latency tables the cost of manipulating mxcsr registers is pretty small! https://www.agner.org/optimize/instruction_tables.pdf LDMXCSR (restore) and STMXCSR (save) have cpu latencies at like 5-20 cycles (more often 8-15), so having the current C ffi calls set the default C FPU environment (as we currently have ordinarily) is super doable to ensure no breakage of existing C bindings, plus have a new ccall variant that inherits the host haskell thread FPU state. we're talking sub 10 nanosecond overhead on x86 and x86_64 platforms (and either way, on those platforms soon ghc will only be using the sse2 or higher ). point being: aside from like AMD piledriver micro architecture and some stuff from VIA, the performance of the CPU instruction for the signalling nans state setup and related rounding mode etc, should work perfectly well, @Daniel Cartwright I do not support documenting false laws in any enshrined way, it will result in broken code. (Also i'm actually working to do some fixes, if you reread my remarks and merijn's, and i think we can have our cake and eat it, with the finest floats). Lets fix stuff and then document true laws! On Thu, Feb 7, 2019 at 12:05 PM Sven Panne wrote: > Am Do., 7. Feb. 2019 um 17:22 Uhr schrieb Henning Thielemann < > lemming at henning-thielemann.de>: > >> [...] What about calling into foreign code? If I call a BLAS routine and >> one >> element of the result vector is NaN, shall this be trapped? Or shall it >> be >> trapped once I access the NaN element? >> > > IMHO this is the biggest show stopper for some exotic NaN handling, as > correct as it may be mathematically or aesthetically: The floating point > environment is a thread-local (i.e. basically global) entity on most > platforms, and most programming language runtimes expect a "default" > environment, i.e. no traps when NaNs are encountered. So if Haskell wants > to do things differently, the FPE has to be set/reset around foreign calls > and for around every Haskell callback. I am not sure if this is really > worth the trouble and the performance loss. For some special applications > it might be OK or even important, but my gut feeling is that trapping NaNs > is the wrong default in our current world... > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 21:29:01 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Feb 2019 16:29:01 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: to further add weight, i'm still doing preliminary hackery on the signalling approach, but the signalling for FP state stuff seems to be OS thread local, so it can be treated as an exception perfectly well! On Thu, Feb 7, 2019 at 4:27 PM Carter Schonwald wrote: > @sven and @henning : > i'm actually doing some preliminary work to add save and restore for FPU > state to the GHC RTS, at the green/haskell thread layer. after first > ripping out x87 code gen, which just needs some more docs written out > before its merged in. note that i'm speaking specifically of the MXCSR > register save and restore, not the more hefty operations you might be > thinking. > > FPU mode state save and restore is done already on EVERY OS when switching > threads/processes, and in the agner fog latency tables the cost of > manipulating mxcsr registers is pretty small! > https://www.agner.org/optimize/instruction_tables.pdf > > LDMXCSR (restore) and STMXCSR (save) have cpu latencies at like 5-20 > cycles (more often 8-15), so having the current C ffi calls set the > default C FPU environment (as we currently have ordinarily) is super doable > to ensure no breakage of existing C bindings, plus have a new ccall variant > that inherits the host haskell thread FPU state. we're talking sub 10 > nanosecond overhead on x86 and x86_64 platforms (and either way, on those > platforms soon ghc will only be using the sse2 or higher ). > > point being: aside from like AMD piledriver micro architecture and some > stuff from VIA, the performance of the CPU instruction for the signalling > nans state setup and related rounding mode etc, should work perfectly well, > > @Daniel Cartwright I do not support documenting > false laws in any enshrined way, it will result in broken code. (Also i'm > actually working to do some fixes, if you reread my remarks and merijn's, > and i think we can have our cake and eat it, with the finest floats). Lets > fix stuff and then document true laws! > > > > On Thu, Feb 7, 2019 at 12:05 PM Sven Panne wrote: > >> Am Do., 7. Feb. 2019 um 17:22 Uhr schrieb Henning Thielemann < >> lemming at henning-thielemann.de>: >> >>> [...] What about calling into foreign code? If I call a BLAS routine and >>> one >>> element of the result vector is NaN, shall this be trapped? Or shall it >>> be >>> trapped once I access the NaN element? >>> >> >> IMHO this is the biggest show stopper for some exotic NaN handling, as >> correct as it may be mathematically or aesthetically: The floating point >> environment is a thread-local (i.e. basically global) entity on most >> platforms, and most programming language runtimes expect a "default" >> environment, i.e. no traps when NaNs are encountered. So if Haskell wants >> to do things differently, the FPE has to be set/reset around foreign calls >> and for around every Haskell callback. I am not sure if this is really >> worth the trouble and the performance loss. For some special applications >> it might be OK or even important, but my gut feeling is that trapping NaNs >> is the wrong default in our current world... >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.Butterfield at scss.tcd.ie Thu Feb 7 16:48:49 2019 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Thu, 7 Feb 2019 16:48:49 +0000 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: Given that compare :: ... -> Ordering and Ordering = LT | EQ | GT, then the current Ord class has to support *total* orders, as there is no way to indicate when two elements are incomparable. Imagine trying to define the obvious partial ordering on sets - i.e. subset-or-equal using the Ord class. What should be the result, for Instance Ord (Set Int) of compare (fromList [1]) (fromList [2]) or fromList [2] <= fromList [1] ? Cheers, Andrew > On 7 Feb 2019, at 16:21, Elliot Cameron wrote: > > While I'm sure it would be a lot of churn, couldn't we introduce a `TotalOrd` class and guard it more carefully? > > On Thu, Feb 7, 2019 at 10:45 AM Merijn Verstraaten > wrote: > I was discussing this with Carter on IRC, so to chime in with my two cents: > > I think the default behaviour for Float/Double should use a trapping NaN. The current value NaN is as if every Double value has an implicit "fromJust" and finding out which part of larger computations/pipelines introduced the NaNs in your output is a pain. > > Trapping NaN would also eliminate the brokenness of Ord. If some people are really attached to value NaNs (why?!? What's wrong with you?) we could allow disabling trapping at compile or runtime so they get the old behaviour. > > Cheers, > Merijn > > > On 7 Feb 2019, at 03:43, Carter Schonwald > wrote: > > > > We cant add laws at the moment unless we change how the Ord instances for Float and Double are defined. (which i think SHOULd happen, but needs some care and has lots of implications) > > > > there are several possible semantics we can choose that act as we expect on +/- infity and finite floats, but differ in the handling of nans > > > > option 1) use the total order defined in floating point standard 2008, section 5.10, which defines negative nans below -infity, positive nans above +infty > > (this has the nice property that you could check for not nan by -infty <= x && x <= infty) > > > > option 2) shift haskell/ GHC to having signalling NAN semantics by default, so the only "fully evaluated" floating point values are in the interval from negative to positive infinity , > > > > option 3) some mixture of the above > > > > I am slowly doing some patches to improve floating point bits in ghc (and pave the way towards doing something like one of the above), though theres still much to do > > > > also: the current definitions of min/max via compare aren't commutative if either argument is nan (they become right biased or left biased, i forget which) > > > > http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a copy of ieee floating point 2008 (easy to google up a copy if that link doesnt work) > > > > > > > > > > On Wed, Feb 6, 2019 at 4:31 PM chessai . > wrote: > > Sure. There are no explicit mention of the laws of Ord. I think they > > should be explicitly stated in the report, perhaps like so: > > > > ---------- start proposed change > > class (Eq a) => Ord a where > > compare :: a -> a -> Ordering > > (<), (<=), (>), (>=) :: a -> a -> Bool > > max, min :: a -> a -> a > > > > compare x y = if x == y then EQ > > else if x <= y then LT > > else GT > > > > x < y = case compare x y of { LT -> True; _ -> False } > > x <= y = case compare x y of { GT -> False; _ -> True } > > x > y = case compare x y of { GT -> True; _ -> False } > > x >= y = case compare x y of { LT -> False; _ -> True } > > > > max x y = if x <= y then y else x > > min x y = if x <= y then x else y > > {-# MINIMAL compare | (<=) #-} > > > > The `Ord` class is used for totally ordered datatypes. Instances of > > 'Ord' can be derived for any user-defined datatype whose constituent > > types are in 'Ord'. The declared order of the constructors in the data > > declaration determines the ordering in the derived 'Ord' instances. > > The 'Ordering' datatype allows a single comparison to determine the > > precise ordering of two objects. > > > > A minimal instance of 'Ord' implements either 'compare' or '<=', and > > is expected to adhere to the following laws: > > > > Antisymmetry (a <= b && b <= a = a == b) > > Transitivity (a <= b && b <= c = a <= c) > > Totality (a <= b || b <= a = True) > > > > An additional law, Reflexity, is implied by Totality. It states (x <= x = True). > > ---------- end proposed change > > > > I don't particularly like the bit in the current documentation about > > (<=) implementing a non-strict partial ordering, because if (<=) > > constitutes a minimal definition of Ord and is required only to be a > > partial ordering on the type parameterised by Ord, then why is Ord > > required to be a total ordering? That seems sort of confusing. It > > seems to me that the current documentation leans more toward 'Ord' > > implementing a partial order than a total order. I can't speak for > > others, but when I think of 'Ord' I usually think of a total ordering. > > > > Additionally, Reflexity is strictly weaker than Totality, so > > specifying their relationship (Reflexivity is implied by Totality) and > > also writing out what Totality means in the context of Ord makes sense > > to me. > > > > For Eq, the report currently states: > > > > ----------begin report quote > > class Eq a where > > (==), (/=) :: a -> a -> Bool > > > > x /= y = not (x == y) > > x == y = not (x /= y) > > > > The Eq class provides equality (==) and inequality (/=) methods. All > > basic datatypes except for functions and IO are instances of this > > class. Instances of Eq can be derived for any user-defined datatype > > whose constituents are also instances of Eq. > > > > This declaration gives default method declarations for both /= and ==, > > each being defined in terms of the other. If an instance declaration > > for Eq defines neither == nor /=, then both will loop. If one is > > defined, the default method for the other will make use of the one > > that is defined. If both are defined, neither default method is used. > > ----------end report quote > > > > I think the following changes make sense: > > > > ---------- begin proposed changes > > > > class Eq a where > > (==), (/=) :: a -> a -> Bool > > x /= y = not (x == y) > > x == y = not (x /= y) > > > > The 'Eq' class defines equality ('==') and inequality ('/='). > > All the basic datatypes exported by the "Prelude" are instances of 'Eq', > > and 'Eq' may be derived for any datatype whose constituents are also > > instances of 'Eq'. > > > > '==' implements an equivalence relationship where two values comparing equal > > are considered indistinguishable. A minimal instance of 'Eq' > > implements either '==' or '/=', and must adhere to the following laws: > > > > Reflexivity (x == x = True) > > Symmetry (x == y = y == x) > > Transitivity (x == y && y == z = x == z) > > Substitutivity (x == y = f x == f y) > > Negation (x /= y = not (x = y) > > ---------- end proposed changes > > > > On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Feb 6, 2019 at 9:43 PM chessai . > wrote: > > >> > > >> Per GHC.Classes (haddock-viewable from Data.Ord) > > >> > > >> "The Haskell Report defines no laws for Ord. However, <= is > > >> customarily expected to implement a non-strict partial order and have > > >> the following properties:" > > >> > > >> I propose that in the next report that the expected typeclass laws for > > >> Ord be added. They're generally agreed upon/understood. > > > > > > > > > > > > Can you spell out the concrete change to the report wording you're suggesting? For reference, the current wording used in the 2010 Haskell Report is quoted below. While at it, you might also want to take into account the `Eq` class definition in the report. > > > > > > > > > 6.3.2 The Ord Class > > > > > > class (Eq a) => Ord a where > > > compare :: a -> a -> Ordering > > > (<), (<=), (>=), (>) :: a -> a -> Bool > > > max, min :: a -> a -> a > > > > > > compare x y | x == y = EQ > > > | x <= y = LT > > > | otherwise = GT > > > > > > x <= y = compare x y /= GT > > > x < y = compare x y == LT > > > x >= y = compare x y /= LT > > > x > y = compare x y == GT > > > > > > -- Note that (min x y, max x y) = (x,y) or (y,x) > > > max x y | x <= y = y > > > | otherwise = x > > > min x y | x <= y = x > > > | otherwise = y > > > > > > The Ord class is used for totally ordered datatypes. All basic datatypes except for functions, IO, and IOError, are instances of this class. Instances of Ord can be derived for any user-defined datatype whose constituent types are in Ord. The declared order of the constructors in the data declaration determines the ordering in derived Ord instances. The Ordering datatype allows a single comparison to determine the precise ordering of two objects. > > > > > > The default declarations allow a user to create an Ord instance either with a type-specific compare function or with type-specific == and <= functions. > > > > > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero at TCD, Head of Foundations & Methods Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Feb 7 21:41:32 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 7 Feb 2019 16:41:32 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: Even if Ord becomes lawful for floating point, there will still be massive problems reasoning about it because the Num instances can't support the ring laws, let alone the ordered ring laws. What should `compare NaN n` be? If it's an exception, then the ordering is not total, you can't store NaN in a Set, etc. If it's LT or GT, then you get a total ordering, but a rather weird one. So yeah, you'd be able to store NaN in a Set and have an NaN key in a Map, but then as soon as you start looking at where these are coming from and where they're going, everything goes weird and you need type-specific code anyway. On Thu, Feb 7, 2019, 4:29 PM Carter Schonwald to further add weight, i'm still doing preliminary hackery on the > signalling approach, but the signalling for FP state stuff seems to be OS > thread local, so it can be treated as an exception perfectly well! > > On Thu, Feb 7, 2019 at 4:27 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> @sven and @henning : >> i'm actually doing some preliminary work to add save and restore for FPU >> state to the GHC RTS, at the green/haskell thread layer. after first >> ripping out x87 code gen, which just needs some more docs written out >> before its merged in. note that i'm speaking specifically of the MXCSR >> register save and restore, not the more hefty operations you might be >> thinking. >> >> FPU mode state save and restore is done already on EVERY OS when >> switching threads/processes, and in the agner fog latency tables the cost >> of manipulating mxcsr registers is pretty small! >> https://www.agner.org/optimize/instruction_tables.pdf >> >> LDMXCSR (restore) and STMXCSR (save) have cpu latencies at like 5-20 >> cycles (more often 8-15), so having the current C ffi calls set the >> default C FPU environment (as we currently have ordinarily) is super doable >> to ensure no breakage of existing C bindings, plus have a new ccall variant >> that inherits the host haskell thread FPU state. we're talking sub 10 >> nanosecond overhead on x86 and x86_64 platforms (and either way, on those >> platforms soon ghc will only be using the sse2 or higher ). >> >> point being: aside from like AMD piledriver micro architecture and some >> stuff from VIA, the performance of the CPU instruction for the signalling >> nans state setup and related rounding mode etc, should work perfectly well, >> >> @Daniel Cartwright I do not support documenting >> false laws in any enshrined way, it will result in broken code. (Also i'm >> actually working to do some fixes, if you reread my remarks and merijn's, >> and i think we can have our cake and eat it, with the finest floats). Lets >> fix stuff and then document true laws! >> >> >> >> On Thu, Feb 7, 2019 at 12:05 PM Sven Panne wrote: >> >>> Am Do., 7. Feb. 2019 um 17:22 Uhr schrieb Henning Thielemann < >>> lemming at henning-thielemann.de>: >>> >>>> [...] What about calling into foreign code? If I call a BLAS routine >>>> and one >>>> element of the result vector is NaN, shall this be trapped? Or shall it >>>> be >>>> trapped once I access the NaN element? >>>> >>> >>> IMHO this is the biggest show stopper for some exotic NaN handling, as >>> correct as it may be mathematically or aesthetically: The floating point >>> environment is a thread-local (i.e. basically global) entity on most >>> platforms, and most programming language runtimes expect a "default" >>> environment, i.e. no traps when NaNs are encountered. So if Haskell wants >>> to do things differently, the FPE has to be set/reset around foreign calls >>> and for around every Haskell callback. I am not sure if this is really >>> worth the trouble and the performance loss. For some special applications >>> it might be OK or even important, but my gut feeling is that trapping NaNs >>> is the wrong default in our current world... >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 21:41:40 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Feb 2019 16:41:40 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: hey Andrew B, agreed, partial orders aren't covered by Ord, and we are discussing only Ord here. theres a lot of good approaches to partial ords, but thats outside of scope for now :) On Thu, Feb 7, 2019 at 4:37 PM Andrew Butterfield < Andrew.Butterfield at scss.tcd.ie> wrote: > Given that compare :: ... -> Ordering and Ordering = LT | EQ | GT, > then the current Ord class has to support *total* orders, as there is no > way to indicate when two elements are incomparable. > > Imagine trying to define the obvious partial ordering on sets - i.e. > subset-or-equal using the Ord class. > What should be the result, for Instance Ord (Set Int) of > > compare (fromList [1]) (fromList [2]) or fromList [2] <= fromList [1] ? > > > Cheers, Andrew > > On 7 Feb 2019, at 16:21, Elliot Cameron wrote: > > While I'm sure it would be a lot of churn, couldn't we introduce a > `TotalOrd` class and guard it more carefully? > > On Thu, Feb 7, 2019 at 10:45 AM Merijn Verstraaten > wrote: > >> I was discussing this with Carter on IRC, so to chime in with my two >> cents: >> >> I think the default behaviour for Float/Double should use a trapping NaN. >> The current value NaN is as if every Double value has an implicit >> "fromJust" and finding out which part of larger computations/pipelines >> introduced the NaNs in your output is a pain. >> >> Trapping NaN would also eliminate the brokenness of Ord. If some people >> are really attached to value NaNs (why?!? What's wrong with you?) we could >> allow disabling trapping at compile or runtime so they get the old >> behaviour. >> >> Cheers, >> Merijn >> >> > On 7 Feb 2019, at 03:43, Carter Schonwald >> wrote: >> > >> > We cant add laws at the moment unless we change how the Ord instances >> for Float and Double are defined. (which i think SHOULd happen, but needs >> some care and has lots of implications) >> > >> > there are several possible semantics we can choose that act as we >> expect on +/- infity and finite floats, but differ in the handling of nans >> > >> > option 1) use the total order defined in floating point standard 2008, >> section 5.10, which defines negative nans below -infity, positive nans >> above +infty >> > (this has the nice property that you could check for not nan by >> -infty <= x && x <= infty) >> > >> > option 2) shift haskell/ GHC to having signalling NAN semantics by >> default, so the only "fully evaluated" floating point values are in the >> interval from negative to positive infinity , >> > >> > option 3) some mixture of the above >> > >> > I am slowly doing some patches to improve floating point bits in ghc >> (and pave the way towards doing something like one of the above), though >> theres still much to do >> > >> > also: the current definitions of min/max via compare aren't commutative >> if either argument is nan (they become right biased or left biased, i >> forget which) >> > >> > http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf is a >> copy of ieee floating point 2008 (easy to google up a copy if that link >> doesnt work) >> > >> > >> > >> > >> > On Wed, Feb 6, 2019 at 4:31 PM chessai . wrote: >> > Sure. There are no explicit mention of the laws of Ord. I think they >> > should be explicitly stated in the report, perhaps like so: >> > >> > ---------- start proposed change >> > class (Eq a) => Ord a where >> > compare :: a -> a -> Ordering >> > (<), (<=), (>), (>=) :: a -> a -> Bool >> > max, min :: a -> a -> a >> > >> > compare x y = if x == y then EQ >> > else if x <= y then LT >> > else GT >> > >> > x < y = case compare x y of { LT -> True; _ -> False } >> > x <= y = case compare x y of { GT -> False; _ -> True } >> > x > y = case compare x y of { GT -> True; _ -> False } >> > x >= y = case compare x y of { LT -> False; _ -> True } >> > >> > max x y = if x <= y then y else x >> > min x y = if x <= y then x else y >> > {-# MINIMAL compare | (<=) #-} >> > >> > The `Ord` class is used for totally ordered datatypes. Instances of >> > 'Ord' can be derived for any user-defined datatype whose constituent >> > types are in 'Ord'. The declared order of the constructors in the data >> > declaration determines the ordering in the derived 'Ord' instances. >> > The 'Ordering' datatype allows a single comparison to determine the >> > precise ordering of two objects. >> > >> > A minimal instance of 'Ord' implements either 'compare' or '<=', and >> > is expected to adhere to the following laws: >> > >> > Antisymmetry (a <= b && b <= a = a == b) >> > Transitivity (a <= b && b <= c = a <= c) >> > Totality (a <= b || b <= a = True) >> > >> > An additional law, Reflexity, is implied by Totality. It states (x <= x >> = True). >> > ---------- end proposed change >> > >> > I don't particularly like the bit in the current documentation about >> > (<=) implementing a non-strict partial ordering, because if (<=) >> > constitutes a minimal definition of Ord and is required only to be a >> > partial ordering on the type parameterised by Ord, then why is Ord >> > required to be a total ordering? That seems sort of confusing. It >> > seems to me that the current documentation leans more toward 'Ord' >> > implementing a partial order than a total order. I can't speak for >> > others, but when I think of 'Ord' I usually think of a total ordering. >> > >> > Additionally, Reflexity is strictly weaker than Totality, so >> > specifying their relationship (Reflexivity is implied by Totality) and >> > also writing out what Totality means in the context of Ord makes sense >> > to me. >> > >> > For Eq, the report currently states: >> > >> > ----------begin report quote >> > class Eq a where >> > (==), (/=) :: a -> a -> Bool >> > >> > x /= y = not (x == y) >> > x == y = not (x /= y) >> > >> > The Eq class provides equality (==) and inequality (/=) methods. All >> > basic datatypes except for functions and IO are instances of this >> > class. Instances of Eq can be derived for any user-defined datatype >> > whose constituents are also instances of Eq. >> > >> > This declaration gives default method declarations for both /= and ==, >> > each being defined in terms of the other. If an instance declaration >> > for Eq defines neither == nor /=, then both will loop. If one is >> > defined, the default method for the other will make use of the one >> > that is defined. If both are defined, neither default method is used. >> > ----------end report quote >> > >> > I think the following changes make sense: >> > >> > ---------- begin proposed changes >> > >> > class Eq a where >> > (==), (/=) :: a -> a -> Bool >> > x /= y = not (x == y) >> > x == y = not (x /= y) >> > >> > The 'Eq' class defines equality ('==') and inequality ('/='). >> > All the basic datatypes exported by the "Prelude" are instances of 'Eq', >> > and 'Eq' may be derived for any datatype whose constituents are also >> > instances of 'Eq'. >> > >> > '==' implements an equivalence relationship where two values comparing >> equal >> > are considered indistinguishable. A minimal instance of 'Eq' >> > implements either '==' or '/=', and must adhere to the following laws: >> > >> > Reflexivity (x == x = True) >> > Symmetry (x == y = y == x) >> > Transitivity (x == y && y == z = x == z) >> > Substitutivity (x == y = f x == f y) >> > Negation (x /= y = not (x = y) >> > ---------- end proposed changes >> > >> > On Wed, Feb 6, 2019 at 3:52 PM Herbert Valerio Riedel >> > wrote: >> > > >> > > >> > > >> > > >> > > >> > > On Wed, Feb 6, 2019 at 9:43 PM chessai . >> wrote: >> > >> >> > >> Per GHC.Classes (haddock-viewable from Data.Ord) >> > >> >> > >> "The Haskell Report defines no laws for Ord. However, <= is >> > >> customarily expected to implement a non-strict partial order and have >> > >> the following properties:" >> > >> >> > >> I propose that in the next report that the expected typeclass laws >> for >> > >> Ord be added. They're generally agreed upon/understood. >> > > >> > > >> > > >> > > Can you spell out the concrete change to the report wording you're >> suggesting? For reference, the current wording used in the 2010 Haskell >> Report is quoted below. While at it, you might also want to take into >> account the `Eq` class definition in the report. >> > > >> > > >> > > 6.3.2 The Ord Class >> > > >> > > class (Eq a) => Ord a where >> > > compare :: a -> a -> Ordering >> > > (<), (<=), (>=), (>) :: a -> a -> Bool >> > > max, min :: a -> a -> a >> > > >> > > compare x y | x == y = EQ >> > > | x <= y = LT >> > > | otherwise = GT >> > > >> > > x <= y = compare x y /= GT >> > > x < y = compare x y == LT >> > > x >= y = compare x y /= LT >> > > x > y = compare x y == GT >> > > >> > > -- Note that (min x y, max x y) = (x,y) or (y,x) >> > > max x y | x <= y = y >> > > | otherwise = x >> > > min x y | x <= y = x >> > > | otherwise = y >> > > >> > > The Ord class is used for totally ordered datatypes. All basic >> datatypes except for functions, IO, and IOError, are instances of this >> class. Instances of Ord can be derived for any user-defined datatype whose >> constituent types are in Ord. The declared order of the constructors in the >> data declaration determines the ordering in derived Ord instances. The >> Ordering datatype allows a single comparison to determine the precise >> ordering of two objects. >> > > >> > > The default declarations allow a user to create an Ord instance >> either with a type-specific compare function or with type-specific == and >> <= functions. >> > > >> > > >> > > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > -------------------------------------------------------------------- > Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 > Lero at TCD, Head of Foundations & Methods Research Group > School of Computer Science and Statistics, > Room G.39, O'Reilly Institute, Trinity College, University of Dublin > http://www.scss.tcd.ie/Andrew.Butterfield/ > -------------------------------------------------------------------- > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 7 22:04:15 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Feb 2019 17:04:15 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: David, We aren't talking about Ring laws here, so lets not pull that in yet please :) as Merijn also noted, one possible semantics is have signalling Nans, so that any haskell calculation that yields a Nan instead triggers an exception via cpu stuff. Or the next FP instruction that touches the nan will trigger in the case of it coming from C land (I just reread all the relevant sections of the intel architecture manual, its quite explicit on this corner, and still be superbly IEEE float compliant, AND place nice with code that DOES want nan via stateful stuff if need be) on the matter of Nan, in a quiet nan universe, theres a whole universe of Nans, and they're all different, and in fact the iEEE standard is quite clear that a language could pick different nans for different errors (eg have all the bits form a bit set of possible errors). Or one of several other approaches. point being, we can have nice things. mind you, i'm still doing this hackery over time. But I genuinely see a path thats thread safe, makes the MXCSR register state act local per haskell thread, doesn't change the default semantics for C ffi calls, and still allows those who want quiet NANs to do whatever they want if they really really want to. I do agree that any such changes can't break code in the wild that depends on FPU state stuff, nor those who like Quiet Nans more than exceptional/signalling ones. And thats a burden on me / any collaborators for successful execution. *punchline* Lawful Ord and NanFree Float for all, with no leaky breakages, Every Num has Div By Zero error already, lets recognize all NAN computations as being similarly exceptional by default. :) On Thu, Feb 7, 2019 at 4:41 PM David Feuer wrote: > Even if Ord becomes lawful for floating point, there will still be massive > problems reasoning about it because the Num instances can't support the > ring laws, let alone the ordered ring laws. What should `compare NaN n` be? > If it's an exception, then the ordering is not total, you can't store NaN > in a Set, etc. If it's LT or GT, then you get a total ordering, but a > rather weird one. So yeah, you'd be able to store NaN in a Set and have an > NaN key in a Map, but then as soon as you start looking at where these are > coming from and where they're going, everything goes weird and you need > type-specific code anyway. > > On Thu, Feb 7, 2019, 4:29 PM Carter Schonwald wrote: > >> to further add weight, i'm still doing preliminary hackery on the >> signalling approach, but the signalling for FP state stuff seems to be OS >> thread local, so it can be treated as an exception perfectly well! >> >> On Thu, Feb 7, 2019 at 4:27 PM Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> @sven and @henning : >>> i'm actually doing some preliminary work to add save and restore for FPU >>> state to the GHC RTS, at the green/haskell thread layer. after first >>> ripping out x87 code gen, which just needs some more docs written out >>> before its merged in. note that i'm speaking specifically of the MXCSR >>> register save and restore, not the more hefty operations you might be >>> thinking. >>> >>> FPU mode state save and restore is done already on EVERY OS when >>> switching threads/processes, and in the agner fog latency tables the cost >>> of manipulating mxcsr registers is pretty small! >>> https://www.agner.org/optimize/instruction_tables.pdf >>> >>> LDMXCSR (restore) and STMXCSR (save) have cpu latencies at like 5-20 >>> cycles (more often 8-15), so having the current C ffi calls set the >>> default C FPU environment (as we currently have ordinarily) is super doable >>> to ensure no breakage of existing C bindings, plus have a new ccall variant >>> that inherits the host haskell thread FPU state. we're talking sub 10 >>> nanosecond overhead on x86 and x86_64 platforms (and either way, on those >>> platforms soon ghc will only be using the sse2 or higher ). >>> >>> point being: aside from like AMD piledriver micro architecture and some >>> stuff from VIA, the performance of the CPU instruction for the signalling >>> nans state setup and related rounding mode etc, should work perfectly well, >>> >>> @Daniel Cartwright I do not support >>> documenting false laws in any enshrined way, it will result in broken code. >>> (Also i'm actually working to do some fixes, if you reread my remarks and >>> merijn's, and i think we can have our cake and eat it, with the finest >>> floats). Lets fix stuff and then document true laws! >>> >>> >>> >>> On Thu, Feb 7, 2019 at 12:05 PM Sven Panne wrote: >>> >>>> Am Do., 7. Feb. 2019 um 17:22 Uhr schrieb Henning Thielemann < >>>> lemming at henning-thielemann.de>: >>>> >>>>> [...] What about calling into foreign code? If I call a BLAS routine >>>>> and one >>>>> element of the result vector is NaN, shall this be trapped? Or shall >>>>> it be >>>>> trapped once I access the NaN element? >>>>> >>>> >>>> IMHO this is the biggest show stopper for some exotic NaN handling, as >>>> correct as it may be mathematically or aesthetically: The floating point >>>> environment is a thread-local (i.e. basically global) entity on most >>>> platforms, and most programming language runtimes expect a "default" >>>> environment, i.e. no traps when NaNs are encountered. So if Haskell wants >>>> to do things differently, the FPE has to be set/reset around foreign calls >>>> and for around every Haskell callback. I am not sure if this is really >>>> worth the trouble and the performance loss. For some special applications >>>> it might be OK or even important, but my gut feeling is that trapping NaNs >>>> is the wrong default in our current world... >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merijn at inconsistent.nl Thu Feb 7 22:31:02 2019 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Thu, 7 Feb 2019 23:31:02 +0100 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> > On 7 Feb 2019, at 22:41, David Feuer wrote: > > Even if Ord becomes lawful for floating point, there will still be massive problems reasoning about it because the Num instances can't support the ring laws, let alone the ordered ring laws. What should `compare NaN n` be? Our goal is to make "compare NaN n" impossible to happen. You can only (try) to compare with NaN if you can *get* a NaN value. But IEEE-754 pretty clearly does *NOT* require computations that evaluate to NaN to be represented as values. "Trap representations" (i.e., anything vaguely exception like) are an acceptable IEEE-754 compliant way of implementing NaN. All the major CPU platforms support trapping floating point exceptions, not many languages make use of this. > If it's an exception, then the ordering is not total, you can't store NaN in a Set, etc. I think this argument is without merit. Yes, it would mean you can't store NaN in a Set anymore (because you wouldn't even be able to have a NaN value...). But that's like complaining Int is broken because I can't store "(5 `div` 0)" in a Set. So far everyone seems perfectly ok with the exception raised by division by zero, so why not NaN? > If it's LT or GT, then you get a total ordering, but a rather weird one. So yeah, you'd be able to store NaN in a Set and have an NaN key in a Map, but then as soon as you start looking at where these are coming from and where they're going, everything goes weird and you need type-specific code anyway. If we accept value NaN's (as opposed to trapping NaNs) then we can't have Ord anyway, at least not without giving up on IEEE-754 compliance, as IEEE-754 demands "NaN" compares unequal with itself, which breaks any sort of ordering based function (even simple things like sort, as I painfully discovered in Python...) Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From carter.schonwald at gmail.com Thu Feb 7 22:33:52 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Feb 2019 17:33:52 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> Message-ID: additionally (for posterity), merjin pointed out to me that we do want x/0 to not be an exception when abs(x)!= 0, because +/- infinity are perfectly valid and useful mathematical objects On Thu, Feb 7, 2019 at 5:31 PM Merijn Verstraaten wrote: > > > On 7 Feb 2019, at 22:41, David Feuer wrote: > > > > Even if Ord becomes lawful for floating point, there will still be > massive problems reasoning about it because the Num instances can't support > the ring laws, let alone the ordered ring laws. What should `compare NaN n` > be? > > Our goal is to make "compare NaN n" impossible to happen. You can only > (try) to compare with NaN if you can *get* a NaN value. But IEEE-754 pretty > clearly does *NOT* require computations that evaluate to NaN to be > represented as values. > > "Trap representations" (i.e., anything vaguely exception like) are an > acceptable IEEE-754 compliant way of implementing NaN. All the major CPU > platforms support trapping floating point exceptions, not many languages > make use of this. > > > If it's an exception, then the ordering is not total, you can't store > NaN in a Set, etc. > > I think this argument is without merit. Yes, it would mean you can't store > NaN in a Set anymore (because you wouldn't even be able to have a NaN > value...). But that's like complaining Int is broken because I can't store > "(5 `div` 0)" in a Set. So far everyone seems perfectly ok with the > exception raised by division by zero, so why not NaN? > > > If it's LT or GT, then you get a total ordering, but a rather weird one. > So yeah, you'd be able to store NaN in a Set and have an NaN key in a Map, > but then as soon as you start looking at where these are coming from and > where they're going, everything goes weird and you need type-specific code > anyway. > > If we accept value NaN's (as opposed to trapping NaNs) then we can't have > Ord anyway, at least not without giving up on IEEE-754 compliance, as > IEEE-754 demands "NaN" compares unequal with itself, which breaks any sort > of ordering based function (even simple things like sort, as I painfully > discovered in Python...) > > Cheers, > Merijn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george at wils.online Thu Feb 7 22:43:21 2019 From: george at wils.online (George Wilson) Date: Fri, 8 Feb 2019 08:43:21 +1000 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> Message-ID: I think we've gotten a bit off-track here. Certainly we have disagreements about what should be done regarding floating-point values in GHC over the longer term, but that shouldn't hold up the report. I would prefer to see the total order laws added as Daniel suggested, while documenting that Float and Double have non-lawful instances due to NaNs. If the handling of doubles is later improved we can simply delete that line of documentation. On Fri, 8 Feb 2019 at 08:34, Carter Schonwald wrote: > > additionally (for posterity), merjin pointed out to me that we do want x/0 to not be an exception when abs(x)!= 0, because +/- infinity are perfectly valid and useful mathematical objects > > On Thu, Feb 7, 2019 at 5:31 PM Merijn Verstraaten wrote: >> >> >> > On 7 Feb 2019, at 22:41, David Feuer wrote: >> > >> > Even if Ord becomes lawful for floating point, there will still be massive problems reasoning about it because the Num instances can't support the ring laws, let alone the ordered ring laws. What should `compare NaN n` be? >> >> Our goal is to make "compare NaN n" impossible to happen. You can only (try) to compare with NaN if you can *get* a NaN value. But IEEE-754 pretty clearly does *NOT* require computations that evaluate to NaN to be represented as values. >> >> "Trap representations" (i.e., anything vaguely exception like) are an acceptable IEEE-754 compliant way of implementing NaN. All the major CPU platforms support trapping floating point exceptions, not many languages make use of this. >> >> > If it's an exception, then the ordering is not total, you can't store NaN in a Set, etc. >> >> I think this argument is without merit. Yes, it would mean you can't store NaN in a Set anymore (because you wouldn't even be able to have a NaN value...). But that's like complaining Int is broken because I can't store "(5 `div` 0)" in a Set. So far everyone seems perfectly ok with the exception raised by division by zero, so why not NaN? >> >> > If it's LT or GT, then you get a total ordering, but a rather weird one. So yeah, you'd be able to store NaN in a Set and have an NaN key in a Map, but then as soon as you start looking at where these are coming from and where they're going, everything goes weird and you need type-specific code anyway. >> >> If we accept value NaN's (as opposed to trapping NaNs) then we can't have Ord anyway, at least not without giving up on IEEE-754 compliance, as IEEE-754 demands "NaN" compares unequal with itself, which breaks any sort of ordering based function (even simple things like sort, as I painfully discovered in Python...) >> >> Cheers, >> Merijn > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From carter.schonwald at gmail.com Thu Feb 7 23:09:44 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Feb 2019 18:09:44 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> Message-ID: true enough Another cool thing that was pointed out to me, is that for NanFree Floats, the Projective reals (err, floats) with a single infinity become a new type over float/double (subject to how reals and floats) release. (thanks to Wren for that point ) On Thu, Feb 7, 2019 at 5:43 PM George Wilson wrote: > I think we've gotten a bit off-track here. Certainly we have > disagreements about what should be done regarding floating-point > values in GHC over the longer term, but that shouldn't hold up the > report. > I would prefer to see the total order laws added as Daniel suggested, > while documenting that Float and Double have non-lawful instances due > to NaNs. If the handling of doubles is later improved we can simply > delete that line of documentation. > > On Fri, 8 Feb 2019 at 08:34, Carter Schonwald > wrote: > > > > additionally (for posterity), merjin pointed out to me that we do want > x/0 to not be an exception when abs(x)!= 0, because +/- infinity are > perfectly valid and useful mathematical objects > > > > On Thu, Feb 7, 2019 at 5:31 PM Merijn Verstraaten < > merijn at inconsistent.nl> wrote: > >> > >> > >> > On 7 Feb 2019, at 22:41, David Feuer wrote: > >> > > >> > Even if Ord becomes lawful for floating point, there will still be > massive problems reasoning about it because the Num instances can't support > the ring laws, let alone the ordered ring laws. What should `compare NaN n` > be? > >> > >> Our goal is to make "compare NaN n" impossible to happen. You can only > (try) to compare with NaN if you can *get* a NaN value. But IEEE-754 pretty > clearly does *NOT* require computations that evaluate to NaN to be > represented as values. > >> > >> "Trap representations" (i.e., anything vaguely exception like) are an > acceptable IEEE-754 compliant way of implementing NaN. All the major CPU > platforms support trapping floating point exceptions, not many languages > make use of this. > >> > >> > If it's an exception, then the ordering is not total, you can't store > NaN in a Set, etc. > >> > >> I think this argument is without merit. Yes, it would mean you can't > store NaN in a Set anymore (because you wouldn't even be able to have a NaN > value...). But that's like complaining Int is broken because I can't store > "(5 `div` 0)" in a Set. So far everyone seems perfectly ok with the > exception raised by division by zero, so why not NaN? > >> > >> > If it's LT or GT, then you get a total ordering, but a rather weird > one. So yeah, you'd be able to store NaN in a Set and have an NaN key in a > Map, but then as soon as you start looking at where these are coming from > and where they're going, everything goes weird and you need type-specific > code anyway. > >> > >> If we accept value NaN's (as opposed to trapping NaNs) then we can't > have Ord anyway, at least not without giving up on IEEE-754 compliance, as > IEEE-754 demands "NaN" compares unequal with itself, which breaks any sort > of ordering based function (even simple things like sort, as I painfully > discovered in Python...) > >> > >> Cheers, > >> Merijn > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Feb 8 00:19:48 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 8 Feb 2019 01:19:48 +0100 (CET) Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: On Thu, 7 Feb 2019, Andrew Butterfield wrote: > Imagine trying to define the obvious partial ordering on sets - i.e. > subset-or-equal using the Ord class. What should be the result, for > Instance Ord (Set Int) of > > compare (fromList [1]) (fromList [2])    or  fromList [2] <= fromList [1] ? Partial ordering means to me that the comparison function is partial. I.e. fromList [2] <= fromList [1] would be "undefined". From chessai1996 at gmail.com Fri Feb 8 01:04:02 2019 From: chessai1996 at gmail.com (chessai .) Date: Thu, 7 Feb 2019 20:04:02 -0500 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> Message-ID: Yes, quite. This is only about clarifications to the report. All this other stuff seems mostly tangential, and should probably be another thread. On Thu, Feb 7, 2019, 5:44 PM George Wilson I think we've gotten a bit off-track here. Certainly we have > disagreements about what should be done regarding floating-point > values in GHC over the longer term, but that shouldn't hold up the > report. > I would prefer to see the total order laws added as Daniel suggested, > while documenting that Float and Double have non-lawful instances due > to NaNs. If the handling of doubles is later improved we can simply > delete that line of documentation. > > On Fri, 8 Feb 2019 at 08:34, Carter Schonwald > wrote: > > > > additionally (for posterity), merjin pointed out to me that we do want > x/0 to not be an exception when abs(x)!= 0, because +/- infinity are > perfectly valid and useful mathematical objects > > > > On Thu, Feb 7, 2019 at 5:31 PM Merijn Verstraaten < > merijn at inconsistent.nl> wrote: > >> > >> > >> > On 7 Feb 2019, at 22:41, David Feuer wrote: > >> > > >> > Even if Ord becomes lawful for floating point, there will still be > massive problems reasoning about it because the Num instances can't support > the ring laws, let alone the ordered ring laws. What should `compare NaN n` > be? > >> > >> Our goal is to make "compare NaN n" impossible to happen. You can only > (try) to compare with NaN if you can *get* a NaN value. But IEEE-754 pretty > clearly does *NOT* require computations that evaluate to NaN to be > represented as values. > >> > >> "Trap representations" (i.e., anything vaguely exception like) are an > acceptable IEEE-754 compliant way of implementing NaN. All the major CPU > platforms support trapping floating point exceptions, not many languages > make use of this. > >> > >> > If it's an exception, then the ordering is not total, you can't store > NaN in a Set, etc. > >> > >> I think this argument is without merit. Yes, it would mean you can't > store NaN in a Set anymore (because you wouldn't even be able to have a NaN > value...). But that's like complaining Int is broken because I can't store > "(5 `div` 0)" in a Set. So far everyone seems perfectly ok with the > exception raised by division by zero, so why not NaN? > >> > >> > If it's LT or GT, then you get a total ordering, but a rather weird > one. So yeah, you'd be able to store NaN in a Set and have an NaN key in a > Map, but then as soon as you start looking at where these are coming from > and where they're going, everything goes weird and you need type-specific > code anyway. > >> > >> If we accept value NaN's (as opposed to trapping NaNs) then we can't > have Ord anyway, at least not without giving up on IEEE-754 compliance, as > IEEE-754 demands "NaN" compares unequal with itself, which breaks any sort > of ordering based function (even simple things like sort, as I painfully > discovered in Python...) > >> > >> Cheers, > >> Merijn > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Fri Feb 8 09:48:01 2019 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 8 Feb 2019 09:48:01 +0000 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: On Fri, 8 Feb 2019, 12:20 am Henning Thielemann, < lemming at henning-thielemann.de> wrote: > > On Thu, 7 Feb 2019, Andrew Butterfield wrote: > > > Imagine trying to define the obvious partial ordering on sets - i.e. > > subset-or-equal using the Ord class. What should be the result, for > > Instance Ord (Set Int) of > > > > compare (fromList [1]) (fromList [2]) or fromList [2] <= fromList > [1] ? > > Partial ordering means to me that the comparison function is partial. > I.e. fromList [2] <= fromList [1] would be "undefined".__________________ Oh heavens no! It's very useful to ask whether two elements are comparable, that's a nightmare with this approach. > _____________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Feb 8 09:54:29 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 8 Feb 2019 10:54:29 +0100 (CET) Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: On Fri, 8 Feb 2019, Oliver Charles wrote: > On Fri, 8 Feb 2019, 12:20 am Henning Thielemann, wrote: > > On Thu, 7 Feb 2019, Andrew Butterfield wrote: > > > Imagine trying to define the obvious partial ordering on sets - i.e. > > subset-or-equal using the Ord class. What should be the result, for > > Instance Ord (Set Int) of > > > > compare (fromList [1]) (fromList [2])    or  fromList [2] <= fromList [1] ? > > Partial ordering means to me that the comparison function is partial. > I.e. fromList [2] <= fromList [1] would be "undefined".__________________ > > > Oh heavens no! It's very useful to ask whether two elements are comparable, that's  a nightmare with this > approach. With the signature of 'compare' we can hardly do it better. That's why it is certainly better to leave Ord for total orderings and define class PartialOrd a where maybeCompare :: a -> a -> Maybe Ordering From svenpanne at gmail.com Fri Feb 8 09:57:29 2019 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 8 Feb 2019 10:57:29 +0100 Subject: Add Ord Laws to next Haskell Report In-Reply-To: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> Message-ID: Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < merijn at inconsistent.nl>: > Our goal is to make "compare NaN n" impossible to happen. [...] Well, what is supposed to happen then when you *do* see a NaN, e.g. one produced from a foreign call? You *will* see NaNs in Haskell if you interact with other languages, most of them take a far less religious approach to floating points calculations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Fri Feb 8 10:17:22 2019 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 8 Feb 2019 10:17:22 +0000 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: Message-ID: On Fri, 8 Feb 2019, 9:54 am Henning Thielemann, < lemming at henning-thielemann.de> wrote: > With the signature of 'compare' we can hardly do it better. That's why it > is certainly better to leave Ord for total orderings and define > > class PartialOrd a where > maybeCompare :: a -> a -> Maybe Ordering Yes, precisely. For a moment I thought you were suggesting we should use Ord for partial orders. -------------- next part -------------- An HTML attachment was scrubbed... URL: From merijn at inconsistent.nl Fri Feb 8 10:21:16 2019 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Fri, 8 Feb 2019 11:21:16 +0100 Subject: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> Message-ID: <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> > On 8 Feb 2019, at 10:57, Sven Panne wrote: > > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten : > Our goal is to make "compare NaN n" impossible to happen. [...] > > Well, what is supposed to happen then when you *do* see a NaN, e.g. one produced from a foreign call? You *will* see NaNs in Haskell if you interact with other languages, most of them take a far less religious approach to floating points calculations. This is not true. As Carter pointed out we can setup the CPU to trap NaNs *even in foreign calls*. So, in theory we CAN rule this out safely. Doing this we can simply convert the trap into an exception at the FFI boundary. Now, there are cases were this is problematic, so as said before we will probably need to allow people to optionally switch on 'value NaNs', because the foreign code isn't exception safe or for other reasons, but this is manageable. Via, for example having an annotation on foreign imports whether you want to trap or not. In the scenario where someone switches to value NaNs, we are *still* not worse off than we are now. The things you suggest already happen *now*, so the only thing we're advocating is making it possible to have more sane behaviour in the future. Any IEEE-754 compliant implementation of Double that doesn't use trapping NaN can, by definition, never ever be a sane implementation of Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't apply to NaNs and there is *no* safe way to sort/order data containing NaNs. I've run into several nasty issues of trying to sort lists containing NaNs (not just Haskell, also Python and C) and it's *not* just the NaNs that are affected, entire subsequences end up getting sorted wrong based on the comparison with NaN and you end up with completely garbled and unsorted data. In other words, there are only two ways to get sane behaviour from Double with regards to ordering: 1. Trapping NaN represenation 2. Deviate from IEEE-754 semantics To me, option 2 is out of the question, it's the one consistent thing across language we have when it comes to floating point. I understand that *always* using trap representation isn't feasible, but allowing people to optionally switch to value NaNs leaves us no worse off than we are *right now*, and per above, there is literally no way to improve the situation wrt value NaNs without sacrificing IEEE-754 compliance. Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From carter.schonwald at gmail.com Fri Feb 8 15:34:23 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 10:34:23 -0500 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: Thanks for eloquently summarizing , better than I would , what I thought I had laid out. Ieee floating point has fantastic hardware support . May as well be the first real language to actually use it correctly. :) On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten wrote: > > > > On 8 Feb 2019, at 10:57, Sven Panne wrote: > > > > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < > merijn at inconsistent.nl>: > > Our goal is to make "compare NaN n" impossible to happen. [...] > > > > Well, what is supposed to happen then when you *do* see a NaN, e.g. one > produced from a foreign call? You *will* see NaNs in Haskell if you > interact with other languages, most of them take a far less religious > approach to floating points calculations. > > This is not true. As Carter pointed out we can setup the CPU to trap NaNs > *even in foreign calls*. So, in theory we CAN rule this out safely. Doing > this we can simply convert the trap into an exception at the FFI boundary. > > Now, there are cases were this is problematic, so as said before we will > probably need to allow people to optionally switch on 'value NaNs', because > the foreign code isn't exception safe or for other reasons, but this is > manageable. Via, for example having an annotation on foreign imports > whether you want to trap or not. > > In the scenario where someone switches to value NaNs, we are *still* not > worse off than we are now. The things you suggest already happen *now*, so > the only thing we're advocating is making it possible to have more sane > behaviour in the future. > > Any IEEE-754 compliant implementation of Double that doesn't use trapping > NaN can, by definition, never ever be a sane implementation of Ord. As > IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't apply to > NaNs and there is *no* safe way to sort/order data containing NaNs. > > I've run into several nasty issues of trying to sort lists containing NaNs > (not just Haskell, also Python and C) and it's *not* just the NaNs that are > affected, entire subsequences end up getting sorted wrong based on the > comparison with NaN and you end up with completely garbled and unsorted > data. > > In other words, there are only two ways to get sane behaviour from Double > with regards to ordering: > > 1. Trapping NaN represenation > 2. Deviate from IEEE-754 semantics > > To me, option 2 is out of the question, it's the one consistent thing > across language we have when it comes to floating point. I understand that > *always* using trap representation isn't feasible, but allowing people to > optionally switch to value NaNs leaves us no worse off than we are *right > now*, and per above, there is literally no way to improve the situation wrt > value NaNs without sacrificing IEEE-754 compliance. > > Cheers, > Merijn > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 8 17:04:10 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 12:04:10 -0500 Subject: add concatMapM to base in control.monad Message-ID: friend asked me to raise this previously https://ghc.haskell.org/trac/ghc/ticket/2042 seems like it iddn't happen last time because base lived outside of ghc? -- | The 'concatMapM' function generalizes 'concatMap' to arbitrary monads. concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] concatMapM f xs = liftM concat (mapM f xs) -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 8 17:06:53 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 12:06:53 -0500 Subject: add map back to Functor Message-ID: harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"- strange to not have our lovely maps be functorial by default. I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 8 17:13:24 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 12:13:24 -0500 Subject: add concatMapM to base in control.monad In-Reply-To: References: Message-ID: it should be noted that this can be viewed as a special case of the witherable packages lovely interfaces http://hackage.haskell.org/package/witherable-0.3 , which has related things like witherM :: Monad m => (a -> m (Maybe b)) -> t a -> m (t b) On Fri, Feb 8, 2019 at 12:04 PM Carter Schonwald wrote: > friend asked me to raise this > > previously https://ghc.haskell.org/trac/ghc/ticket/2042 > seems like it iddn't happen last time because base lived outside of ghc? > > -- | The 'concatMapM' function generalizes 'concatMap' to arbitrary monads. > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > concatMapM f xs = liftM concat (mapM f xs) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Fri Feb 8 17:57:36 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Fri, 8 Feb 2019 09:57:36 -0800 Subject: add concatMapM to base in control.monad In-Reply-To: References: Message-ID: As long as we're playing the permutation game, I also frequently use mconcatMap, and mconcatMapM. Actually, my concatMapM is secretly '(Monad m, Monoid b) => (a -> m b) -> [a] -> m b', but I suppose you could argue that's inconsistent with the existing naming scheme. I guess I don't mind it because unlike the generalization of [a] to Foldable a, I haven't had ambiguity problems with generalizing [a] to Monoid a. Just personal experience though. On Fri, Feb 8, 2019 at 9:04 AM Carter Schonwald wrote: > > friend asked me to raise this > > previously https://ghc.haskell.org/trac/ghc/ticket/2042 > seems like it iddn't happen last time because base lived outside of ghc? > > -- | The 'concatMapM' function generalizes 'concatMap' to arbitrary monads. > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > concatMapM f xs = liftM concat (mapM f xs) > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From carter.schonwald at gmail.com Fri Feb 8 18:41:53 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 13:41:53 -0500 Subject: add concatMapM to base in control.monad In-Reply-To: References: Message-ID: That does seem nice. I don’t actually have a horse in this race mind you , I was merely relaying a privately communicated from a friend proposal for feedback about its merits etc. On Fri, Feb 8, 2019 at 12:57 PM Evan Laforge wrote: > As long as we're playing the permutation game, I also frequently use > mconcatMap, and mconcatMapM. Actually, my concatMapM is secretly > '(Monad m, Monoid b) => (a -> m b) -> [a] -> m b', but I suppose you > could argue that's inconsistent with the existing naming scheme. > > I guess I don't mind it because unlike the generalization of [a] to > Foldable a, I haven't had ambiguity problems with generalizing [a] to > Monoid a. Just personal experience though. > > On Fri, Feb 8, 2019 at 9:04 AM Carter Schonwald > wrote: > > > > friend asked me to raise this > > > > previously https://ghc.haskell.org/trac/ghc/ticket/2042 > > seems like it iddn't happen last time because base lived outside of ghc? > > > > -- | The 'concatMapM' function generalizes 'concatMap' to arbitrary > monads. > > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > > concatMapM f xs = liftM concat (mapM f xs) > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Feb 8 18:45:49 2019 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 8 Feb 2019 13:45:49 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: The real problem with this sketch of a proposal is the lack of a nice migration plan. If it is top level and just calls fmap, then the distinction requires random rote memorization of which one you can define. On the other hand, say you put it in Functor today as an extra member. Currently everybody has definitions in terms of `fmap`, so you'd need to make the two definitions mutual. This would mean enlarging the dictionaries for one of the most common structures in Haskell for a rather far flung removal that breaks everyone. If we had a way (say a pragma or other syntactic form) to say that fmap and map were somehow the 'same name' or something and so that defining one was the same as defining the other, so that this tax didn't exist, I could see how we might get there. That sort of "magic" might be useful for making migration plans to get sequenceA to be sequence and mapM and traverse without requiring folks to memorize which one is in the class and which is a top level definition. Without something like that, I'd remain somewhat inclined against concocting a complicated migration plan to save one letter. -Edward On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald wrote: > harkening back to the old Haskell 1.5 days, Lets have map back in functor. > it "F"- strange to not have our lovely maps be functorial by default. > > I think it would be a genuine boon for old and new haskellers alike, and > those who disagree with this change already use alt-preludes for pedagogy > reasons anyways > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Feb 8 19:01:38 2019 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 8 Feb 2019 14:01:38 -0500 Subject: add concatMapM to base in control.monad In-Reply-To: References: Message-ID: I'm neutral to slightly negative on the proposal, but if one is going to put it forth, this is a pretty crippled version of what the combinator could be. Switching liftM to fmap, and mapM to traverse gets you Applicative m. There is no reason to limit this to Monad. -Edward On Fri, Feb 8, 2019 at 12:04 PM Carter Schonwald wrote: > friend asked me to raise this > > previously https://ghc.haskell.org/trac/ghc/ticket/2042 > seems like it iddn't happen last time because base lived outside of ghc? > > -- | The 'concatMapM' function generalizes 'concatMap' to arbitrary monads. > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > concatMapM f xs = liftM concat (mapM f xs) > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Feb 8 19:05:21 2019 From: david.feuer at gmail.com (David Feuer) Date: Fri, 8 Feb 2019 14:05:21 -0500 Subject: add concatMapM to base in control.monad In-Reply-To: References: Message-ID: I really don't see why we need this. On Fri, Feb 8, 2019, 12:04 PM Carter Schonwald friend asked me to raise this > > previously https://ghc.haskell.org/trac/ghc/ticket/2042 > seems like it iddn't happen last time because base lived outside of ghc? > > -- | The 'concatMapM' function generalizes 'concatMap' to arbitrary monads. > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > concatMapM f xs = liftM concat (mapM f xs) > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lennart at augustsson.net Fri Feb 8 19:07:22 2019 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri, 8 Feb 2019 12:07:22 -0700 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: I would *hate* to lose quiet NaNs. They can be very useful. But I’d be fine having them as a separate type. And while we’re at it, why not make Int overflow and underflow cause a trap as well? With a different type if you want to wrap. On Fri, Feb 8, 2019 at 08:34 Carter Schonwald wrote: > Thanks for eloquently summarizing , better than I would , what I thought I > had laid out. > > Ieee floating point has fantastic hardware support . May as well be the > first real language to actually use it correctly. :) > > On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten > wrote: > >> >> >> > On 8 Feb 2019, at 10:57, Sven Panne wrote: >> > >> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < >> merijn at inconsistent.nl>: >> > Our goal is to make "compare NaN n" impossible to happen. [...] >> > >> > Well, what is supposed to happen then when you *do* see a NaN, e.g. one >> produced from a foreign call? You *will* see NaNs in Haskell if you >> interact with other languages, most of them take a far less religious >> approach to floating points calculations. >> >> This is not true. As Carter pointed out we can setup the CPU to trap NaNs >> *even in foreign calls*. So, in theory we CAN rule this out safely. Doing >> this we can simply convert the trap into an exception at the FFI boundary. >> >> Now, there are cases were this is problematic, so as said before we will >> probably need to allow people to optionally switch on 'value NaNs', because >> the foreign code isn't exception safe or for other reasons, but this is >> manageable. Via, for example having an annotation on foreign imports >> whether you want to trap or not. >> >> In the scenario where someone switches to value NaNs, we are *still* not >> worse off than we are now. The things you suggest already happen *now*, so >> the only thing we're advocating is making it possible to have more sane >> behaviour in the future. >> >> Any IEEE-754 compliant implementation of Double that doesn't use trapping >> NaN can, by definition, never ever be a sane implementation of Ord. As >> IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't apply to >> NaNs and there is *no* safe way to sort/order data containing NaNs. >> >> I've run into several nasty issues of trying to sort lists containing >> NaNs (not just Haskell, also Python and C) and it's *not* just the NaNs >> that are affected, entire subsequences end up getting sorted wrong based on >> the comparison with NaN and you end up with completely garbled and unsorted >> data. >> >> In other words, there are only two ways to get sane behaviour from Double >> with regards to ordering: >> >> 1. Trapping NaN represenation >> 2. Deviate from IEEE-754 semantics >> >> To me, option 2 is out of the question, it's the one consistent thing >> across language we have when it comes to floating point. I understand that >> *always* using trap representation isn't feasible, but allowing people to >> optionally switch to value NaNs leaves us no worse off than we are *right >> now*, and per above, there is literally no way to improve the situation wrt >> value NaNs without sacrificing IEEE-754 compliance. >> >> Cheers, >> Merijn >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Feb 8 19:12:43 2019 From: david.feuer at gmail.com (David Feuer) Date: Fri, 8 Feb 2019 14:12:43 -0500 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: No, no, no. Int and Word are *rings*, which let's us apply a ton of mathematical reasoning to their arithmetic. Trapping overflow would throw all that completely out the window. If you want to trap overflow, please use different types! On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson I would *hate* to lose quiet NaNs. They can be very useful. But I’d be > fine having them as a separate type. > > And while we’re at it, why not make Int overflow and underflow cause a > trap as well? With a different type if you want to wrap. > > > On Fri, Feb 8, 2019 at 08:34 Carter Schonwald > wrote: > >> Thanks for eloquently summarizing , better than I would , what I thought >> I had laid out. >> >> Ieee floating point has fantastic hardware support . May as well be the >> first real language to actually use it correctly. :) >> >> On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten >> wrote: >> >>> >>> >>> > On 8 Feb 2019, at 10:57, Sven Panne wrote: >>> > >>> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < >>> merijn at inconsistent.nl>: >>> > Our goal is to make "compare NaN n" impossible to happen. [...] >>> > >>> > Well, what is supposed to happen then when you *do* see a NaN, e.g. >>> one produced from a foreign call? You *will* see NaNs in Haskell if you >>> interact with other languages, most of them take a far less religious >>> approach to floating points calculations. >>> >>> This is not true. As Carter pointed out we can setup the CPU to trap >>> NaNs *even in foreign calls*. So, in theory we CAN rule this out safely. >>> Doing this we can simply convert the trap into an exception at the FFI >>> boundary. >>> >>> Now, there are cases were this is problematic, so as said before we will >>> probably need to allow people to optionally switch on 'value NaNs', because >>> the foreign code isn't exception safe or for other reasons, but this is >>> manageable. Via, for example having an annotation on foreign imports >>> whether you want to trap or not. >>> >>> In the scenario where someone switches to value NaNs, we are *still* not >>> worse off than we are now. The things you suggest already happen *now*, so >>> the only thing we're advocating is making it possible to have more sane >>> behaviour in the future. >>> >>> Any IEEE-754 compliant implementation of Double that doesn't use >>> trapping NaN can, by definition, never ever be a sane implementation of >>> Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't >>> apply to NaNs and there is *no* safe way to sort/order data containing NaNs. >>> >>> I've run into several nasty issues of trying to sort lists containing >>> NaNs (not just Haskell, also Python and C) and it's *not* just the NaNs >>> that are affected, entire subsequences end up getting sorted wrong based on >>> the comparison with NaN and you end up with completely garbled and unsorted >>> data. >>> >>> In other words, there are only two ways to get sane behaviour from >>> Double with regards to ordering: >>> >>> 1. Trapping NaN represenation >>> 2. Deviate from IEEE-754 semantics >>> >>> To me, option 2 is out of the question, it's the one consistent thing >>> across language we have when it comes to floating point. I understand that >>> *always* using trap representation isn't feasible, but allowing people to >>> optionally switch to value NaNs leaves us no worse off than we are *right >>> now*, and per above, there is literally no way to improve the situation wrt >>> value NaNs without sacrificing IEEE-754 compliance. >>> >>> Cheers, >>> Merijn >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 8 19:23:55 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 14:23:55 -0500 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: I absolutely agree. Before any user visible stuff happens the first step would be rts support for better managing floating point flags / rounding mode / trap bits. Could you list some contexts / examples where you want quiet or signaling nans respectively? The more examples written down and shared the better! :) On Fri, Feb 8, 2019 at 2:07 PM Lennart Augustsson wrote: > I would *hate* to lose quiet NaNs. They can be very useful. But I’d be > fine having them as a separate type. > > And while we’re at it, why not make Int overflow and underflow cause a > trap as well? With a different type if you want to wrap. > > > On Fri, Feb 8, 2019 at 08:34 Carter Schonwald > wrote: > >> Thanks for eloquently summarizing , better than I would , what I thought >> I had laid out. >> >> Ieee floating point has fantastic hardware support . May as well be the >> first real language to actually use it correctly. :) >> >> On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten >> wrote: >> >>> >>> >>> > On 8 Feb 2019, at 10:57, Sven Panne wrote: >>> > >>> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < >>> merijn at inconsistent.nl>: >>> > Our goal is to make "compare NaN n" impossible to happen. [...] >>> > >>> > Well, what is supposed to happen then when you *do* see a NaN, e.g. >>> one produced from a foreign call? You *will* see NaNs in Haskell if you >>> interact with other languages, most of them take a far less religious >>> approach to floating points calculations. >>> >>> This is not true. As Carter pointed out we can setup the CPU to trap >>> NaNs *even in foreign calls*. So, in theory we CAN rule this out safely. >>> Doing this we can simply convert the trap into an exception at the FFI >>> boundary. >>> >>> Now, there are cases were this is problematic, so as said before we will >>> probably need to allow people to optionally switch on 'value NaNs', because >>> the foreign code isn't exception safe or for other reasons, but this is >>> manageable. Via, for example having an annotation on foreign imports >>> whether you want to trap or not. >>> >>> In the scenario where someone switches to value NaNs, we are *still* not >>> worse off than we are now. The things you suggest already happen *now*, so >>> the only thing we're advocating is making it possible to have more sane >>> behaviour in the future. >>> >>> Any IEEE-754 compliant implementation of Double that doesn't use >>> trapping NaN can, by definition, never ever be a sane implementation of >>> Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't >>> apply to NaNs and there is *no* safe way to sort/order data containing NaNs. >>> >>> I've run into several nasty issues of trying to sort lists containing >>> NaNs (not just Haskell, also Python and C) and it's *not* just the NaNs >>> that are affected, entire subsequences end up getting sorted wrong based on >>> the comparison with NaN and you end up with completely garbled and unsorted >>> data. >>> >>> In other words, there are only two ways to get sane behaviour from >>> Double with regards to ordering: >>> >>> 1. Trapping NaN represenation >>> 2. Deviate from IEEE-754 semantics >>> >>> To me, option 2 is out of the question, it's the one consistent thing >>> across language we have when it comes to floating point. I understand that >>> *always* using trap representation isn't feasible, but allowing people to >>> optionally switch to value NaNs leaves us no worse off than we are *right >>> now*, and per above, there is literally no way to improve the situation wrt >>> value NaNs without sacrificing IEEE-754 compliance. >>> >>> Cheers, >>> Merijn >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 8 19:27:30 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 14:27:30 -0500 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: I’m not sure if they currently have full ring structure , but I do agree that trapping and non trapping int and word are useful. Simple example where all the finite signed ints work wrong today : There’s no proper additive inverse for minBound :: int Likewise , what’s our current definition of negate on finite word types? On Fri, Feb 8, 2019 at 2:12 PM David Feuer wrote: > No, no, no. Int and Word are *rings*, which let's us apply a ton of > mathematical reasoning to their arithmetic. Trapping overflow would throw > all that completely out the window. If you want to trap overflow, please > use different types! > > On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson wrote: > >> I would *hate* to lose quiet NaNs. They can be very useful. But I’d be >> fine having them as a separate type. >> >> And while we’re at it, why not make Int overflow and underflow cause a >> trap as well? With a different type if you want to wrap. >> >> >> On Fri, Feb 8, 2019 at 08:34 Carter Schonwald >> wrote: >> >>> Thanks for eloquently summarizing , better than I would , what I thought >>> I had laid out. >>> >>> Ieee floating point has fantastic hardware support . May as well be the >>> first real language to actually use it correctly. :) >>> >>> On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten < >>> merijn at inconsistent.nl> wrote: >>> >>>> >>>> >>>> > On 8 Feb 2019, at 10:57, Sven Panne wrote: >>>> > >>>> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < >>>> merijn at inconsistent.nl>: >>>> > Our goal is to make "compare NaN n" impossible to happen. [...] >>>> > >>>> > Well, what is supposed to happen then when you *do* see a NaN, e.g. >>>> one produced from a foreign call? You *will* see NaNs in Haskell if you >>>> interact with other languages, most of them take a far less religious >>>> approach to floating points calculations. >>>> >>>> This is not true. As Carter pointed out we can setup the CPU to trap >>>> NaNs *even in foreign calls*. So, in theory we CAN rule this out safely. >>>> Doing this we can simply convert the trap into an exception at the FFI >>>> boundary. >>>> >>>> Now, there are cases were this is problematic, so as said before we >>>> will probably need to allow people to optionally switch on 'value NaNs', >>>> because the foreign code isn't exception safe or for other reasons, but >>>> this is manageable. Via, for example having an annotation on foreign >>>> imports whether you want to trap or not. >>>> >>>> In the scenario where someone switches to value NaNs, we are *still* >>>> not worse off than we are now. The things you suggest already happen *now*, >>>> so the only thing we're advocating is making it possible to have more sane >>>> behaviour in the future. >>>> >>>> Any IEEE-754 compliant implementation of Double that doesn't use >>>> trapping NaN can, by definition, never ever be a sane implementation of >>>> Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't >>>> apply to NaNs and there is *no* safe way to sort/order data containing NaNs. >>>> >>>> I've run into several nasty issues of trying to sort lists containing >>>> NaNs (not just Haskell, also Python and C) and it's *not* just the NaNs >>>> that are affected, entire subsequences end up getting sorted wrong based on >>>> the comparison with NaN and you end up with completely garbled and unsorted >>>> data. >>>> >>>> In other words, there are only two ways to get sane behaviour from >>>> Double with regards to ordering: >>>> >>>> 1. Trapping NaN represenation >>>> 2. Deviate from IEEE-754 semantics >>>> >>>> To me, option 2 is out of the question, it's the one consistent thing >>>> across language we have when it comes to floating point. I understand that >>>> *always* using trap representation isn't feasible, but allowing people to >>>> optionally switch to value NaNs leaves us no worse off than we are *right >>>> now*, and per above, there is literally no way to improve the situation wrt >>>> value NaNs without sacrificing IEEE-754 compliance. >>>> >>>> Cheers, >>>> Merijn >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Fri Feb 8 19:32:35 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Fri, 8 Feb 2019 13:32:35 -0600 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: <01f1d5e9-b532-2078-6534-2734e5702c49@iohk.io> Most of the arguments for making them rings feel kind of pedantic, in any case. I can't think of a time I've ever used actual ring theory to reason about Ints/Words. On 2/8/19 1:27 PM, Carter Schonwald wrote: > I’m not sure if they currently have full ring structure , but  I do > agree that trapping and non trapping int and word are useful.  > > Simple example where all the finite signed ints work wrong today :  > > There’s no proper additive inverse for minBound :: int  > > Likewise , what’s our current definition of negate on finite word types? > > On Fri, Feb 8, 2019 at 2:12 PM David Feuer > wrote: > > No, no, no. Int and Word are *rings*, which let's us apply a ton > of mathematical reasoning to their arithmetic. Trapping overflow > would throw all that completely out the window. If you want to > trap overflow, please use different types! > > On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson > wrote: > > I would *hate* to lose quiet NaNs.  They can be very useful.  > But I’d be fine having them as a separate type. > > And while we’re at it, why not make Int overflow and underflow > cause a trap as well?  With a different type if you want to wrap.  > > > On Fri, Feb 8, 2019 at 08:34 Carter Schonwald > > wrote: > > Thanks for eloquently summarizing , better than I would , > what I thought I had laid out.  > > Ieee floating point has fantastic hardware support .  May > as well be the first real language to actually use it > correctly. :) > > On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten > > > wrote: > > > > > On 8 Feb 2019, at 10:57, Sven Panne > > wrote: > > > > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn > Verstraaten >: > > Our goal is to make "compare NaN n" impossible to > happen. [...] > > > > Well, what is supposed to happen then when you *do* > see a NaN, e.g. one produced from a foreign call? You > *will* see NaNs in Haskell if you interact with other > languages, most of them take a far less religious > approach to floating points calculations. > > This is not true. As Carter pointed out we can setup > the CPU to trap NaNs *even in foreign calls*. So, in > theory we CAN rule this out safely. Doing this we can > simply convert the trap into an exception at the FFI > boundary. > > Now, there are cases were this is problematic, so as > said before we will probably need to allow people to > optionally switch on 'value NaNs', because the foreign > code isn't exception safe or for other reasons, but > this is manageable. Via, for example having an > annotation on foreign imports whether you want to trap > or not. > > In the scenario where someone switches to value NaNs, > we are *still* not worse off than we are now. The > things you suggest already happen *now*, so the only > thing we're advocating is making it possible to have > more sane behaviour in the future. > > Any IEEE-754 compliant implementation of Double that > doesn't use trapping NaN can, by definition, never > ever be a sane implementation of Ord. As IEEE-754 > *requires* "NaN /= NaN", so equality symmetry doesn't > apply to NaNs and there is *no* safe way to sort/order > data containing NaNs. > > I've run into several nasty issues of trying to sort > lists containing NaNs (not just Haskell, also Python > and C) and it's *not* just the NaNs that are affected, > entire subsequences end up getting sorted wrong based > on the comparison with NaN and you end up with > completely garbled and unsorted data. > > In other words, there are only two ways to get sane > behaviour from Double with regards to ordering: > > 1. Trapping NaN represenation > 2. Deviate from IEEE-754 semantics > > To me, option 2 is out of the question, it's the one > consistent thing across language we have when it comes > to floating point. I understand that *always* using > trap representation isn't feasible, but allowing > people to optionally switch to value NaNs leaves us no > worse off than we are *right now*, and per above, > there is literally no way to improve the situation wrt > value NaNs without sacrificing IEEE-754 compliance. > > Cheers, > Merijn > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From carter.schonwald at gmail.com Fri Feb 8 19:33:19 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 14:33:19 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: You make a good point, we should cook up this desired magic pragma! Could you sketch out 1-2 examples of what you’d want this pragma to do? Something like {-# method_synonym_of fmap map #-} ? This would sort of be like a sort of duplicate record field for how names are mapped to definitions? This example would be “fmap is an alias of map” On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett wrote: > The real problem with this sketch of a proposal is the lack of a nice > migration plan. > > If it is top level and just calls fmap, then the distinction requires > random rote memorization of which one you can define. > > On the other hand, say you put it in Functor today as an extra member. > Currently everybody has definitions in terms of `fmap`, so you'd need to > make the two definitions mutual. This would mean enlarging the dictionaries > for one of the most common structures in Haskell for a rather far flung > removal that breaks everyone. > > If we had a way (say a pragma or other syntactic form) to say that fmap > and map were somehow the 'same name' or something and so that defining one > was the same as defining the other, so that this tax didn't exist, I could > see how we might get there. > > That sort of "magic" might be useful for making migration plans to get > sequenceA to be sequence and mapM and traverse without requiring folks to > memorize which one is in the class and which is a top level definition. > > Without something like that, I'd remain somewhat inclined against > concocting a complicated migration plan to save one letter. > > -Edward > > On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> harkening back to the old Haskell 1.5 days, Lets have map back in >> functor. it "F"- strange to not have our lovely maps be functorial by >> default. >> >> I think it would be a genuine boon for old and new haskellers alike, and >> those who disagree with this change already use alt-preludes for pedagogy >> reasons anyways >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.blanck at gmail.com Fri Feb 8 19:53:30 2019 From: jens.blanck at gmail.com (Jens Blanck) Date: Fri, 8 Feb 2019 19:53:30 +0000 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: > minBound + minBound :: Int 0 > negate minBound == (minBound :: Int) True > 42 + negate 17 :: Word 25 Int and Word are currently rings. What proportion actually uses them as such would be interesting to know but I guess it is very small. I wouldn't dare to reason about Int and Word as rings as there is no guarantee on which ring they are. Int64 and Word64 and so on; yes, those can be reasoned about. I'd be very happy to see a separate type for signalling integral types. Personally, I'd make them the default choice. On Fri, 8 Feb 2019 at 19:27, Carter Schonwald wrote: > I’m not sure if they currently have full ring structure , but I do agree > that trapping and non trapping int and word are useful. > > Simple example where all the finite signed ints work wrong today : > > There’s no proper additive inverse for minBound :: int > > Likewise , what’s our current definition of negate on finite word types? > > On Fri, Feb 8, 2019 at 2:12 PM David Feuer wrote: > >> No, no, no. Int and Word are *rings*, which let's us apply a ton of >> mathematical reasoning to their arithmetic. Trapping overflow would throw >> all that completely out the window. If you want to trap overflow, please >> use different types! >> >> On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson > wrote: >> >>> I would *hate* to lose quiet NaNs. They can be very useful. But I’d be >>> fine having them as a separate type. >>> >>> And while we’re at it, why not make Int overflow and underflow cause a >>> trap as well? With a different type if you want to wrap. >>> >>> >>> On Fri, Feb 8, 2019 at 08:34 Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> Thanks for eloquently summarizing , better than I would , what I >>>> thought I had laid out. >>>> >>>> Ieee floating point has fantastic hardware support . May as well be >>>> the first real language to actually use it correctly. :) >>>> >>>> On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten < >>>> merijn at inconsistent.nl> wrote: >>>> >>>>> >>>>> >>>>> > On 8 Feb 2019, at 10:57, Sven Panne wrote: >>>>> > >>>>> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < >>>>> merijn at inconsistent.nl>: >>>>> > Our goal is to make "compare NaN n" impossible to happen. [...] >>>>> > >>>>> > Well, what is supposed to happen then when you *do* see a NaN, e.g. >>>>> one produced from a foreign call? You *will* see NaNs in Haskell if you >>>>> interact with other languages, most of them take a far less religious >>>>> approach to floating points calculations. >>>>> >>>>> This is not true. As Carter pointed out we can setup the CPU to trap >>>>> NaNs *even in foreign calls*. So, in theory we CAN rule this out safely. >>>>> Doing this we can simply convert the trap into an exception at the FFI >>>>> boundary. >>>>> >>>>> Now, there are cases were this is problematic, so as said before we >>>>> will probably need to allow people to optionally switch on 'value NaNs', >>>>> because the foreign code isn't exception safe or for other reasons, but >>>>> this is manageable. Via, for example having an annotation on foreign >>>>> imports whether you want to trap or not. >>>>> >>>>> In the scenario where someone switches to value NaNs, we are *still* >>>>> not worse off than we are now. The things you suggest already happen *now*, >>>>> so the only thing we're advocating is making it possible to have more sane >>>>> behaviour in the future. >>>>> >>>>> Any IEEE-754 compliant implementation of Double that doesn't use >>>>> trapping NaN can, by definition, never ever be a sane implementation of >>>>> Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't >>>>> apply to NaNs and there is *no* safe way to sort/order data containing NaNs. >>>>> >>>>> I've run into several nasty issues of trying to sort lists containing >>>>> NaNs (not just Haskell, also Python and C) and it's *not* just the NaNs >>>>> that are affected, entire subsequences end up getting sorted wrong based on >>>>> the comparison with NaN and you end up with completely garbled and unsorted >>>>> data. >>>>> >>>>> In other words, there are only two ways to get sane behaviour from >>>>> Double with regards to ordering: >>>>> >>>>> 1. Trapping NaN represenation >>>>> 2. Deviate from IEEE-754 semantics >>>>> >>>>> To me, option 2 is out of the question, it's the one consistent thing >>>>> across language we have when it comes to floating point. I understand that >>>>> *always* using trap representation isn't feasible, but allowing people to >>>>> optionally switch to value NaNs leaves us no worse off than we are *right >>>>> now*, and per above, there is literally no way to improve the situation wrt >>>>> value NaNs without sacrificing IEEE-754 compliance. >>>>> >>>>> Cheers, >>>>> Merijn >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 8 20:03:57 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 15:03:57 -0500 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: No. A ring can’t have 2x=0 for x not zero. Thus int can’t be And by ring I mean an algebraic structure where you have a multiplicative group that doesn’t generate zero from products of nonzero elements ... Phrased differently: Int doesn’t have a multiplicative group structure on the nonzero elements. That makes it a pretty nasty ring. Negate on minBound should be an overflow exception so you can have actual sane semantics. This is an old dead horse with lots of blood written about it. https://ghc.haskell.org/trac/ghc/ticket/8695 has some related discussions On Fri, Feb 8, 2019 at 2:53 PM Jens Blanck wrote: > > minBound + minBound :: Int > 0 > > negate minBound == (minBound :: Int) > True > > 42 + negate 17 :: Word > 25 > > Int and Word are currently rings. What proportion actually uses them as > such would be interesting to know but I guess it is very small. I wouldn't > dare to reason about Int and Word as rings as there is no guarantee on > which ring they are. Int64 and Word64 and so on; yes, those can be reasoned > about. > > I'd be very happy to see a separate type for signalling integral types. > Personally, I'd make them the default choice. > > On Fri, 8 Feb 2019 at 19:27, Carter Schonwald > wrote: > >> I’m not sure if they currently have full ring structure , but I do agree >> that trapping and non trapping int and word are useful. >> >> Simple example where all the finite signed ints work wrong today : >> >> There’s no proper additive inverse for minBound :: int >> >> Likewise , what’s our current definition of negate on finite word types? >> >> On Fri, Feb 8, 2019 at 2:12 PM David Feuer wrote: >> >>> No, no, no. Int and Word are *rings*, which let's us apply a ton of >>> mathematical reasoning to their arithmetic. Trapping overflow would throw >>> all that completely out the window. If you want to trap overflow, please >>> use different types! >>> >>> On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson >> wrote: >>> >>>> I would *hate* to lose quiet NaNs. They can be very useful. But I’d >>>> be fine having them as a separate type. >>>> >>>> And while we’re at it, why not make Int overflow and underflow cause a >>>> trap as well? With a different type if you want to wrap. >>>> >>>> >>>> On Fri, Feb 8, 2019 at 08:34 Carter Schonwald < >>>> carter.schonwald at gmail.com> wrote: >>>> >>>>> Thanks for eloquently summarizing , better than I would , what I >>>>> thought I had laid out. >>>>> >>>>> Ieee floating point has fantastic hardware support . May as well be >>>>> the first real language to actually use it correctly. :) >>>>> >>>>> On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten < >>>>> merijn at inconsistent.nl> wrote: >>>>> >>>>>> >>>>>> >>>>>> > On 8 Feb 2019, at 10:57, Sven Panne wrote: >>>>>> > >>>>>> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < >>>>>> merijn at inconsistent.nl>: >>>>>> > Our goal is to make "compare NaN n" impossible to happen. [...] >>>>>> > >>>>>> > Well, what is supposed to happen then when you *do* see a NaN, e.g. >>>>>> one produced from a foreign call? You *will* see NaNs in Haskell if you >>>>>> interact with other languages, most of them take a far less religious >>>>>> approach to floating points calculations. >>>>>> >>>>>> This is not true. As Carter pointed out we can setup the CPU to trap >>>>>> NaNs *even in foreign calls*. So, in theory we CAN rule this out safely. >>>>>> Doing this we can simply convert the trap into an exception at the FFI >>>>>> boundary. >>>>>> >>>>>> Now, there are cases were this is problematic, so as said before we >>>>>> will probably need to allow people to optionally switch on 'value NaNs', >>>>>> because the foreign code isn't exception safe or for other reasons, but >>>>>> this is manageable. Via, for example having an annotation on foreign >>>>>> imports whether you want to trap or not. >>>>>> >>>>>> In the scenario where someone switches to value NaNs, we are *still* >>>>>> not worse off than we are now. The things you suggest already happen *now*, >>>>>> so the only thing we're advocating is making it possible to have more sane >>>>>> behaviour in the future. >>>>>> >>>>>> Any IEEE-754 compliant implementation of Double that doesn't use >>>>>> trapping NaN can, by definition, never ever be a sane implementation of >>>>>> Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't >>>>>> apply to NaNs and there is *no* safe way to sort/order data containing NaNs. >>>>>> >>>>>> I've run into several nasty issues of trying to sort lists containing >>>>>> NaNs (not just Haskell, also Python and C) and it's *not* just the NaNs >>>>>> that are affected, entire subsequences end up getting sorted wrong based on >>>>>> the comparison with NaN and you end up with completely garbled and unsorted >>>>>> data. >>>>>> >>>>>> In other words, there are only two ways to get sane behaviour from >>>>>> Double with regards to ordering: >>>>>> >>>>>> 1. Trapping NaN represenation >>>>>> 2. Deviate from IEEE-754 semantics >>>>>> >>>>>> To me, option 2 is out of the question, it's the one consistent thing >>>>>> across language we have when it comes to floating point. I understand that >>>>>> *always* using trap representation isn't feasible, but allowing people to >>>>>> optionally switch to value NaNs leaves us no worse off than we are *right >>>>>> now*, and per above, there is literally no way to improve the situation wrt >>>>>> value NaNs without sacrificing IEEE-754 compliance. >>>>>> >>>>>> Cheers, >>>>>> Merijn >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 8 20:05:24 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Feb 2019 15:05:24 -0500 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: I think the algebraic property we usually want for nice integer ish things is intergral domain. Which is a stronger property than ring. Pardon the confusion On Fri, Feb 8, 2019 at 3:03 PM Carter Schonwald wrote: > No. A ring can’t have 2x=0 for x not zero. Thus int can’t be > > And by ring I mean an algebraic structure where you have a multiplicative > group that doesn’t generate zero from products of nonzero elements ... > > Phrased differently: Int doesn’t have a multiplicative group structure on > the nonzero elements. That makes it a pretty nasty ring. Negate on minBound > should be an overflow exception so you can have actual sane semantics. > This is an old dead horse with lots of blood written about it. > > https://ghc.haskell.org/trac/ghc/ticket/8695 has some related discussions > > > On Fri, Feb 8, 2019 at 2:53 PM Jens Blanck wrote: > >> > minBound + minBound :: Int >> 0 >> > negate minBound == (minBound :: Int) >> True >> > 42 + negate 17 :: Word >> 25 >> >> Int and Word are currently rings. What proportion actually uses them as >> such would be interesting to know but I guess it is very small. I wouldn't >> dare to reason about Int and Word as rings as there is no guarantee on >> which ring they are. Int64 and Word64 and so on; yes, those can be reasoned >> about. >> >> I'd be very happy to see a separate type for signalling integral types. >> Personally, I'd make them the default choice. >> >> On Fri, 8 Feb 2019 at 19:27, Carter Schonwald >> wrote: >> >>> I’m not sure if they currently have full ring structure , but I do >>> agree that trapping and non trapping int and word are useful. >>> >>> Simple example where all the finite signed ints work wrong today : >>> >>> There’s no proper additive inverse for minBound :: int >>> >>> Likewise , what’s our current definition of negate on finite word types? >>> >>> On Fri, Feb 8, 2019 at 2:12 PM David Feuer >>> wrote: >>> >>>> No, no, no. Int and Word are *rings*, which let's us apply a ton of >>>> mathematical reasoning to their arithmetic. Trapping overflow would throw >>>> all that completely out the window. If you want to trap overflow, please >>>> use different types! >>>> >>>> On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson >>> wrote: >>>> >>>>> I would *hate* to lose quiet NaNs. They can be very useful. But I’d >>>>> be fine having them as a separate type. >>>>> >>>>> And while we’re at it, why not make Int overflow and underflow cause a >>>>> trap as well? With a different type if you want to wrap. >>>>> >>>>> >>>>> On Fri, Feb 8, 2019 at 08:34 Carter Schonwald < >>>>> carter.schonwald at gmail.com> wrote: >>>>> >>>>>> Thanks for eloquently summarizing , better than I would , what I >>>>>> thought I had laid out. >>>>>> >>>>>> Ieee floating point has fantastic hardware support . May as well be >>>>>> the first real language to actually use it correctly. :) >>>>>> >>>>>> On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten < >>>>>> merijn at inconsistent.nl> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> > On 8 Feb 2019, at 10:57, Sven Panne wrote: >>>>>>> > >>>>>>> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < >>>>>>> merijn at inconsistent.nl>: >>>>>>> > Our goal is to make "compare NaN n" impossible to happen. [...] >>>>>>> > >>>>>>> > Well, what is supposed to happen then when you *do* see a NaN, >>>>>>> e.g. one produced from a foreign call? You *will* see NaNs in Haskell if >>>>>>> you interact with other languages, most of them take a far less religious >>>>>>> approach to floating points calculations. >>>>>>> >>>>>>> This is not true. As Carter pointed out we can setup the CPU to trap >>>>>>> NaNs *even in foreign calls*. So, in theory we CAN rule this out safely. >>>>>>> Doing this we can simply convert the trap into an exception at the FFI >>>>>>> boundary. >>>>>>> >>>>>>> Now, there are cases were this is problematic, so as said before we >>>>>>> will probably need to allow people to optionally switch on 'value NaNs', >>>>>>> because the foreign code isn't exception safe or for other reasons, but >>>>>>> this is manageable. Via, for example having an annotation on foreign >>>>>>> imports whether you want to trap or not. >>>>>>> >>>>>>> In the scenario where someone switches to value NaNs, we are *still* >>>>>>> not worse off than we are now. The things you suggest already happen *now*, >>>>>>> so the only thing we're advocating is making it possible to have more sane >>>>>>> behaviour in the future. >>>>>>> >>>>>>> Any IEEE-754 compliant implementation of Double that doesn't use >>>>>>> trapping NaN can, by definition, never ever be a sane implementation of >>>>>>> Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't >>>>>>> apply to NaNs and there is *no* safe way to sort/order data containing NaNs. >>>>>>> >>>>>>> I've run into several nasty issues of trying to sort lists >>>>>>> containing NaNs (not just Haskell, also Python and C) and it's *not* just >>>>>>> the NaNs that are affected, entire subsequences end up getting sorted wrong >>>>>>> based on the comparison with NaN and you end up with completely garbled and >>>>>>> unsorted data. >>>>>>> >>>>>>> In other words, there are only two ways to get sane behaviour from >>>>>>> Double with regards to ordering: >>>>>>> >>>>>>> 1. Trapping NaN represenation >>>>>>> 2. Deviate from IEEE-754 semantics >>>>>>> >>>>>>> To me, option 2 is out of the question, it's the one consistent >>>>>>> thing across language we have when it comes to floating point. I understand >>>>>>> that *always* using trap representation isn't feasible, but allowing people >>>>>>> to optionally switch to value NaNs leaves us no worse off than we are >>>>>>> *right now*, and per above, there is literally no way to improve the >>>>>>> situation wrt value NaNs without sacrificing IEEE-754 compliance. >>>>>>> >>>>>>> Cheers, >>>>>>> Merijn >>>>>>> _______________________________________________ >>>>>>> Libraries mailing list >>>>>>> Libraries at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>> >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Feb 8 20:26:15 2019 From: david.feuer at gmail.com (David Feuer) Date: Fri, 8 Feb 2019 15:26:15 -0500 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: Yes, but a ring is sufficient for lots of very basic and important manipulations. When I'm writing code with Int and Word, I don't even think about whether the associative and distributive laws apply--I just use them to simplify my definitions. With trapping overflow, I need to watch for ranges every time I apply one. Horrible! On Fri, Feb 8, 2019, 3:05 PM Carter Schonwald I think the algebraic property we usually want for nice integer ish things > is intergral domain. Which is a stronger property than ring. Pardon the > confusion > > On Fri, Feb 8, 2019 at 3:03 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> No. A ring can’t have 2x=0 for x not zero. Thus int can’t be >> >> And by ring I mean an algebraic structure where you have a multiplicative >> group that doesn’t generate zero from products of nonzero elements ... >> >> Phrased differently: Int doesn’t have a multiplicative group structure on >> the nonzero elements. That makes it a pretty nasty ring. Negate on minBound >> should be an overflow exception so you can have actual sane semantics. >> This is an old dead horse with lots of blood written about it. >> >> https://ghc.haskell.org/trac/ghc/ticket/8695 has some related >> discussions >> >> >> On Fri, Feb 8, 2019 at 2:53 PM Jens Blanck wrote: >> >>> > minBound + minBound :: Int >>> 0 >>> > negate minBound == (minBound :: Int) >>> True >>> > 42 + negate 17 :: Word >>> 25 >>> >>> Int and Word are currently rings. What proportion actually uses them as >>> such would be interesting to know but I guess it is very small. I wouldn't >>> dare to reason about Int and Word as rings as there is no guarantee on >>> which ring they are. Int64 and Word64 and so on; yes, those can be reasoned >>> about. >>> >>> I'd be very happy to see a separate type for signalling integral types. >>> Personally, I'd make them the default choice. >>> >>> On Fri, 8 Feb 2019 at 19:27, Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> I’m not sure if they currently have full ring structure , but I do >>>> agree that trapping and non trapping int and word are useful. >>>> >>>> Simple example where all the finite signed ints work wrong today : >>>> >>>> There’s no proper additive inverse for minBound :: int >>>> >>>> Likewise , what’s our current definition of negate on finite word types? >>>> >>>> On Fri, Feb 8, 2019 at 2:12 PM David Feuer >>>> wrote: >>>> >>>>> No, no, no. Int and Word are *rings*, which let's us apply a ton of >>>>> mathematical reasoning to their arithmetic. Trapping overflow would throw >>>>> all that completely out the window. If you want to trap overflow, please >>>>> use different types! >>>>> >>>>> On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson < >>>>> lennart at augustsson.net wrote: >>>>> >>>>>> I would *hate* to lose quiet NaNs. They can be very useful. But I’d >>>>>> be fine having them as a separate type. >>>>>> >>>>>> And while we’re at it, why not make Int overflow and underflow cause >>>>>> a trap as well? With a different type if you want to wrap. >>>>>> >>>>>> >>>>>> On Fri, Feb 8, 2019 at 08:34 Carter Schonwald < >>>>>> carter.schonwald at gmail.com> wrote: >>>>>> >>>>>>> Thanks for eloquently summarizing , better than I would , what I >>>>>>> thought I had laid out. >>>>>>> >>>>>>> Ieee floating point has fantastic hardware support . May as well be >>>>>>> the first real language to actually use it correctly. :) >>>>>>> >>>>>>> On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten < >>>>>>> merijn at inconsistent.nl> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > On 8 Feb 2019, at 10:57, Sven Panne wrote: >>>>>>>> > >>>>>>>> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten < >>>>>>>> merijn at inconsistent.nl>: >>>>>>>> > Our goal is to make "compare NaN n" impossible to happen. [...] >>>>>>>> > >>>>>>>> > Well, what is supposed to happen then when you *do* see a NaN, >>>>>>>> e.g. one produced from a foreign call? You *will* see NaNs in Haskell if >>>>>>>> you interact with other languages, most of them take a far less religious >>>>>>>> approach to floating points calculations. >>>>>>>> >>>>>>>> This is not true. As Carter pointed out we can setup the CPU to >>>>>>>> trap NaNs *even in foreign calls*. So, in theory we CAN rule this out >>>>>>>> safely. Doing this we can simply convert the trap into an exception at the >>>>>>>> FFI boundary. >>>>>>>> >>>>>>>> Now, there are cases were this is problematic, so as said before we >>>>>>>> will probably need to allow people to optionally switch on 'value NaNs', >>>>>>>> because the foreign code isn't exception safe or for other reasons, but >>>>>>>> this is manageable. Via, for example having an annotation on foreign >>>>>>>> imports whether you want to trap or not. >>>>>>>> >>>>>>>> In the scenario where someone switches to value NaNs, we are >>>>>>>> *still* not worse off than we are now. The things you suggest already >>>>>>>> happen *now*, so the only thing we're advocating is making it possible to >>>>>>>> have more sane behaviour in the future. >>>>>>>> >>>>>>>> Any IEEE-754 compliant implementation of Double that doesn't use >>>>>>>> trapping NaN can, by definition, never ever be a sane implementation of >>>>>>>> Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't >>>>>>>> apply to NaNs and there is *no* safe way to sort/order data containing NaNs. >>>>>>>> >>>>>>>> I've run into several nasty issues of trying to sort lists >>>>>>>> containing NaNs (not just Haskell, also Python and C) and it's *not* just >>>>>>>> the NaNs that are affected, entire subsequences end up getting sorted wrong >>>>>>>> based on the comparison with NaN and you end up with completely garbled and >>>>>>>> unsorted data. >>>>>>>> >>>>>>>> In other words, there are only two ways to get sane behaviour from >>>>>>>> Double with regards to ordering: >>>>>>>> >>>>>>>> 1. Trapping NaN represenation >>>>>>>> 2. Deviate from IEEE-754 semantics >>>>>>>> >>>>>>>> To me, option 2 is out of the question, it's the one consistent >>>>>>>> thing across language we have when it comes to floating point. I understand >>>>>>>> that *always* using trap representation isn't feasible, but allowing people >>>>>>>> to optionally switch to value NaNs leaves us no worse off than we are >>>>>>>> *right now*, and per above, there is literally no way to improve the >>>>>>>> situation wrt value NaNs without sacrificing IEEE-754 compliance. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Merijn >>>>>>>> _______________________________________________ >>>>>>>> Libraries mailing list >>>>>>>> Libraries at haskell.org >>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Libraries mailing list >>>>>>> Libraries at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>> >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> >>>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Fri Feb 8 20:53:00 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Fri, 8 Feb 2019 14:53:00 -0600 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: Wouldn't both versions throw an exception in that case? Am I missing something? On 2/8/19 2:26 PM, David Feuer wrote: > Yes, but a ring is sufficient for lots of very basic and important > manipulations. When I'm writing code with Int and Word, I don't even > think about whether the associative and distributive laws apply--I > just use them to simplify my definitions. With trapping overflow, I > need to watch for ranges every time I apply one. Horrible! > > On Fri, Feb 8, 2019, 3:05 PM Carter Schonwald > wrote: > > I think the algebraic property we usually want for nice integer > ish things is intergral domain. Which is a stronger property than > ring. Pardon the confusion  > > On Fri, Feb 8, 2019 at 3:03 PM Carter Schonwald > > > wrote: > > No.  A ring can’t have 2x=0 for x not zero.  Thus int can’t  be  > > And by ring I mean an algebraic structure where you have a > multiplicative group that doesn’t generate zero from products > of nonzero elements ...  > > Phrased differently: Int doesn’t have a multiplicative group > structure on the nonzero elements. That makes it a pretty > nasty ring. Negate on minBound should be an overflow exception > so you can have actual sane semantics.  This is an old dead > horse with lots of blood written about it.  > > https://ghc.haskell.org/trac/ghc/ticket/8695 has some related > discussions  > > > On Fri, Feb 8, 2019 at 2:53 PM Jens Blanck > > wrote: > > > minBound + minBound :: Int > 0 > > negate minBound == (minBound :: Int) > True > > 42 + negate 17 :: Word > 25 > > Int and Word are currently rings. What proportion actually > uses them as such would be interesting to know but I guess > it is very small. I wouldn't dare to reason about Int and > Word as rings as there is no guarantee on which ring they > are. Int64 and Word64 and so on; yes, those can be > reasoned about. > > I'd be very happy to see a separate type for signalling > integral types. Personally, I'd make them the default choice. > > On Fri, 8 Feb 2019 at 19:27, Carter Schonwald > > wrote: > > I’m not sure if they currently have full ring > structure , but  I do agree that trapping and non > trapping int and word are useful.  > > Simple example where all the finite signed ints work > wrong today :  > > There’s no proper additive inverse for minBound :: int  > > Likewise , what’s our current definition of negate on > finite word types? > > On Fri, Feb 8, 2019 at 2:12 PM David Feuer > > > wrote: > > No, no, no. Int and Word are *rings*, which let's > us apply a ton of mathematical reasoning to their > arithmetic. Trapping overflow would throw all that > completely out the window. If you want to trap > overflow, please use different types! > > On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson > wrote: > > I would *hate* to lose quiet NaNs.  They can > be very useful.  But I’d be fine having them > as a separate type. > > And while we’re at it, why not make Int > overflow and underflow cause a trap as well?  > With a different type if you want to wrap.  > > > On Fri, Feb 8, 2019 at 08:34 Carter Schonwald > > wrote: > > Thanks for eloquently summarizing , better > than I would , what I thought I had laid out.  > > Ieee floating point has fantastic hardware > support .  May as well be the first real > language to actually use it correctly. :) > > On Fri, Feb 8, 2019 at 5:21 AM Merijn > Verstraaten > wrote: > > > > > On 8 Feb 2019, at 10:57, Sven Panne > > wrote: > > > > Am Do., 7. Feb. 2019 um 23:31 Uhr > schrieb Merijn Verstraaten > >: > > Our goal is to make "compare NaN n" > impossible to happen. [...] > > > > Well, what is supposed to happen > then when you *do* see a NaN, e.g. one > produced from a foreign call? You > *will* see NaNs in Haskell if you > interact with other languages, most of > them take a far less religious > approach to floating points calculations. > > This is not true. As Carter pointed > out we can setup the CPU to trap NaNs > *even in foreign calls*. So, in theory > we CAN rule this out safely. Doing > this we can simply convert the trap > into an exception at the FFI boundary. > > Now, there are cases were this is > problematic, so as said before we will > probably need to allow people to > optionally switch on 'value NaNs', > because the foreign code isn't > exception safe or for other reasons, > but this is manageable. Via, for > example having an annotation on > foreign imports whether you want to > trap or not. > > In the scenario where someone switches > to value NaNs, we are *still* not > worse off than we are now. The things > you suggest already happen *now*, so > the only thing we're advocating is > making it possible to have more sane > behaviour in the future. > > Any IEEE-754 compliant implementation > of Double that doesn't use trapping > NaN can, by definition, never ever be > a sane implementation of Ord. As > IEEE-754 *requires* "NaN /= NaN", so > equality symmetry doesn't apply to > NaNs and there is *no* safe way to > sort/order data containing NaNs. > > I've run into several nasty issues of > trying to sort lists containing NaNs > (not just Haskell, also Python and C) > and it's *not* just the NaNs that are > affected, entire subsequences end up > getting sorted wrong based on the > comparison with NaN and you end up > with completely garbled and unsorted data. > > In other words, there are only two > ways to get sane behaviour from Double > with regards to ordering: > > 1. Trapping NaN represenation > 2. Deviate from IEEE-754 semantics > > To me, option 2 is out of the > question, it's the one consistent > thing across language we have when it > comes to floating point. I understand > that *always* using trap > representation isn't feasible, but > allowing people to optionally switch > to value NaNs leaves us no worse off > than we are *right now*, and per > above, there is literally no way to > improve the situation wrt value NaNs > without sacrificing IEEE-754 compliance. > > Cheers, > Merijn > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- *Vanessa McHale* Functional Compiler Engineer | Chicago, IL Website: www.iohk.io Twitter: @vamchale PGP Key ID: 4209B7B5 Input Output Twitter Github LinkedIn This e-mail and any file transmitted with it are confidential and intended solely for the use of the recipient(s) to whom it is addressed. Dissemination, distribution, and/or copying of the transmission by anyone other than the intended recipient(s) is prohibited. If you have received this transmission in error please notify IOHK immediately and delete it from your system. E-mail transmissions cannot be guaranteed to be secure or error free. We do not accept liability for any loss, damage, or error arising from this transmission -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam at scientician.net Fri Feb 8 21:41:52 2019 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 8 Feb 2019 22:41:52 +0100 Subject: add map back to Functor In-Reply-To: References: Message-ID: On 08/02/2019 19.45, Edward Kmett wrote: > If we had a way (say a pragma or other syntactic form) to say that fmap > and map were somehow the 'same name' or something and so that defining > one was the same as defining the other, so that this tax didn't exist, I > could see how we might get there. > +1 for "the way" Most of these 'migrations' which are mostly syntactic should be automatable and really should be *automated* via some sort of tool support. I still haven't experienced a language where this sort of thing "just works", but IMO gofix and scalafix have sort of the right idea. (In Haskell we have the luxury of 'only' having to guarantee source compatibility.) If people are worried about having to add CPP sections, then I would submit it's very possible to convert diffs (between pre-fix to post-fix) to CPP. That, or one can usually create a *-compat library which contains the CPP and just use that as a dependency. Ugly, yes, but in practical terms it seems to be quite simple. Regards, From spam at scientician.net Fri Feb 8 21:54:39 2019 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 8 Feb 2019 22:54:39 +0100 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: On 08/02/2019 21.53, Vanessa McHale wrote: > Wouldn't both versions throw an exception in that case? Am I missing > something? Not necessarily, the classic example would be the Binary Search bug https://thebittheories.com/the-curious-case-of-binary-search-the-famous-bug-that-remained-undetected-for-20-years-973e89fc212 (it could be argued that you really want a *trap* in this case as it would surface the bug, but I'm just confirming that there *can* be different behavior.) Generally: I think it's fine to expect WordNN to do wrap-around arithmetic (and it does form a proper ring), but IntNN is kind of weird because there is that edge case[1] of minBound (as Carter mentioned ITT). IME, usually Word-like types are used for things like crypto, etc. -- not just when you want to enforce "not negative", but that may just be my little bubble. [1] In two's complement which even C++20 is set to mandate! From spam at scientician.net Fri Feb 8 21:57:00 2019 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 8 Feb 2019 22:57:00 +0100 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: On 08/02/2019 20.07, Lennart Augustsson wrote: > I would *hate* to lose quiet NaNs. This is just getting further off-topic. Nobody is suggesting this, AFACIT. +1 to the original suggestion to just specify totality for Ord (how could it *not* be?) and mention that Double/Float instances are not currently lawful. From gmemawdavis at aol.com Sat Feb 9 00:31:55 2019 From: gmemawdavis at aol.com (Bev) Date: Sat, 9 Feb 2019 00:31:55 +0000 (UTC) Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report References: <1583960180.695360.1549672315132.ref@mail.yahoo.com> Message-ID: <1583960180.695360.1549672315132@mail.yahoo.com> Please delete me. Thank you On Friday, February 8, 2019 Vanessa McHale wrote: Most of the arguments for making them rings feel kind of pedantic, in any case. I can't think of a time I've ever used actual ring theory to reason about Ints/Words. On 2/8/19 1:27 PM, Carter Schonwald wrote: I’m not sure if they currently have full ring structure , but  I do agree that trapping and non trapping int and word are useful.  Simple example where all the finite signed ints work wrong today :  There’s no proper additive inverse for minBound :: int  Likewise , what’s our current definition of negate on finite word types? On Fri, Feb 8, 2019 at 2:12 PM David Feuer wrote: No, no, no. Int and Word are *rings*, which let's us apply a ton of mathematical reasoning to their arithmetic. Trapping overflow would throw all that completely out the window. If you want to trap overflow, please use different types! On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson wrote: Thanks for eloquently summarizing , better than I would , what I thought I had laid out.  Ieee floating point has fantastic hardware support .  May as well be the first real language to actually use it correctly. :) On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten wrote: > On 8 Feb 2019, at 10:57, Sven Panne wrote: > > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten : > Our goal is to make "compare NaN n" impossible to happen. [...] > > Well, what is supposed to happen then when you *do* see a NaN, e.g. one produced from a foreign call? You *will* see NaNs in Haskell if you interact with other languages, most of them take a far less religious approach to floating points calculations. This is not true. As Carter pointed out we can setup the CPU to trap NaNs *even in foreign calls*. So, in theory we CAN rule this out safely. Doing this we can simply convert the trap into an exception at the FFI boundary. Now, there are cases were this is problematic, so as said before we will probably need to allow people to optionally switch on 'value NaNs', because the foreign code isn't exception safe or for other reasons, but this is manageable. Via, for example having an annotation on foreign imports whether you want to trap or not. In the scenario where someone switches to value NaNs, we are *still* not worse off than we are now. The things you suggest already happen *now*, so the only thing we're advocating is making it possible to have more sane behaviour in the future. Any IEEE-754 compliant implementation of Double that doesn't use trapping NaN can, by definition, never ever be a sane implementation of Ord. As IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't apply to NaNs and there is *no* safe way to sort/order data containing NaNs. I've run into several nasty issues of trying to sort lists containing NaNs (not just Haskell, also Python and C) and it's *not* just the NaNs that are affected, entire subsequences end up getting sorted wrong based on the comparison with NaN and you end up with completely garbled and unsorted data. In other words, there are only two ways to get sane behaviour from Double with regards to ordering: 1. Trapping NaN represenation 2. Deviate from IEEE-754 semantics To me, option 2 is out of the question, it's the one consistent thing across language we have when it comes to floating point. I understand that *always* using trap representation isn't feasible, but allowing people to optionally switch to value NaNs leaves us no worse off than we are *right now*, and per above, there is literally no way to improve the situation wrt value NaNs without sacrificing IEEE-754 compliance. Cheers, Merijn _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From eacameron at gmail.com Sat Feb 9 13:07:16 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Sat, 9 Feb 2019 08:07:16 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: Even with a tool to automate it I know many authors would be very disturbed by such a huge diff in their code. On larger teams with many active branches this kind of sweeping change is quite difficult to maneuver. On Fri, Feb 8, 2019, 4:42 PM Bardur Arantsson On 08/02/2019 19.45, Edward Kmett wrote: > > If we had a way (say a pragma or other syntactic form) to say that fmap > > and map were somehow the 'same name' or something and so that defining > > one was the same as defining the other, so that this tax didn't exist, I > > could see how we might get there. > > > > +1 for "the way" > > Most of these 'migrations' which are mostly syntactic should be > automatable and really should be *automated* via some sort of tool > support. I still haven't experienced a language where this sort of thing > "just works", but IMO gofix and scalafix have sort of the right idea. > > (In Haskell we have the luxury of 'only' having to guarantee source > compatibility.) > > If people are worried about having to add CPP sections, then I would > submit it's very possible to convert diffs (between pre-fix to post-fix) > to CPP. That, or one can usually create a *-compat library which > contains the CPP and just use that as a dependency. Ugly, yes, but in > practical terms it seems to be quite simple. > > Regards, > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Feb 9 19:56:27 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 9 Feb 2019 14:56:27 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: No... the point of such an extension would be that no code that already works would need to change. Except to the extent If I’m not understanding your misapprehension, Could you lay out a specific micro example ? On Sat, Feb 9, 2019 at 8:07 AM Elliot Cameron wrote: > Even with a tool to automate it I know many authors would be very > disturbed by such a huge diff in their code. On larger teams with many > active branches this kind of sweeping change is quite difficult to maneuver. > > On Fri, Feb 8, 2019, 4:42 PM Bardur Arantsson >> On 08/02/2019 19.45, Edward Kmett wrote: >> > If we had a way (say a pragma or other syntactic form) to say that fmap >> > and map were somehow the 'same name' or something and so that defining >> > one was the same as defining the other, so that this tax didn't exist, I >> > could see how we might get there. >> > >> >> +1 for "the way" >> >> Most of these 'migrations' which are mostly syntactic should be >> automatable and really should be *automated* via some sort of tool >> support. I still haven't experienced a language where this sort of thing >> "just works", but IMO gofix and scalafix have sort of the right idea. >> >> (In Haskell we have the luxury of 'only' having to guarantee source >> compatibility.) >> >> If people are worried about having to add CPP sections, then I would >> submit it's very possible to convert diffs (between pre-fix to post-fix) >> to CPP. That, or one can usually create a *-compat library which >> contains the CPP and just use that as a dependency. Ugly, yes, but in >> practical terms it seems to be quite simple. >> >> Regards, >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Feb 9 22:16:48 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 9 Feb 2019 17:16:48 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: All good :) , complicated stuff is hard to communicate. I and likely others always benefit from more practice and folks comfortably asking questions spurred by ambiguity By migration in this context I think we all mean / desire a way to change a name / definition in such a way that the new name / interface works, but also that all previous code still works, as well as code that’s a combination of both old and new also works. Such a mechanism or set of such tools (vaguely described as they are here ), is what I mean. So we mean migration of meaning or underlying language spec, while not breaking perfectly great code On Sat, Feb 9, 2019 at 3:19 PM Elliot Cameron wrote: > In that case I must have misunderstood what the automatic migration would > be. > > On Sat, Feb 9, 2019, 2:56 PM Carter Schonwald wrote: > >> No... the point of such an extension would be that no code that already >> works would need to change. Except to the extent >> >> >> If I’m not understanding your misapprehension, >> Could you lay out a specific micro example ? >> >> On Sat, Feb 9, 2019 at 8:07 AM Elliot Cameron >> wrote: >> >>> Even with a tool to automate it I know many authors would be very >>> disturbed by such a huge diff in their code. On larger teams with many >>> active branches this kind of sweeping change is quite difficult to maneuver. >>> >>> On Fri, Feb 8, 2019, 4:42 PM Bardur Arantsson >> wrote: >>> >>>> On 08/02/2019 19.45, Edward Kmett wrote: >>>> > If we had a way (say a pragma or other syntactic form) to say that >>>> fmap >>>> > and map were somehow the 'same name' or something and so that defining >>>> > one was the same as defining the other, so that this tax didn't >>>> exist, I >>>> > could see how we might get there. >>>> > >>>> >>>> +1 for "the way" >>>> >>>> Most of these 'migrations' which are mostly syntactic should be >>>> automatable and really should be *automated* via some sort of tool >>>> support. I still haven't experienced a language where this sort of thing >>>> "just works", but IMO gofix and scalafix have sort of the right idea. >>>> >>>> (In Haskell we have the luxury of 'only' having to guarantee source >>>> compatibility.) >>>> >>>> If people are worried about having to add CPP sections, then I would >>>> submit it's very possible to convert diffs (between pre-fix to post-fix) >>>> to CPP. That, or one can usually create a *-compat library which >>>> contains the CPP and just use that as a dependency. Ugly, yes, but in >>>> practical terms it seems to be quite simple. >>>> >>>> Regards, >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sat Feb 9 22:43:57 2019 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 9 Feb 2019 17:43:57 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: <95061C01-36EE-4D85-A056-E7F18149DE9F@gmail.com> > El 8 feb 2019, a las 12:06 PM, Carter Schonwald escribió: > > harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"- strange to not have our lovely maps be functorial by default. > > I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways I'm personally -1 on this even if we had a nice migration plan. (Even though I'm not someone who uses an alternative prelude!). "map" is a simple, helpful function. "fmap" is a nice generalized version. It's not costly in readability or typing to keep them separate. Also, nearly every module I've written in Haskell has used "map," under the assumption it meant one thing, and changing it to mean something else (even if only generalized) will have more implications than I can go through and inspect. This is similar to how generalizing "length" in the BBP indirectly caused hard-to-track-down bugs. Lastly, I don't think "pedagogy" can be entirely relegated to "use an alternative prelude". If when I was first evaluating _whether_ to use Haskell I had been told to use "-fno-implicit-prelude" and "import FakePrelude", I'd chafe at essentially being told "pay no attention to the man behind the curtain." If I'd been told that if I wanted to (+1) every element of a list I had to learn a small bit of category theory, I'd have thought "wow, it really is just a language for mathematicians" and likely thought the language wasn't for me. In my view this proposal will make Haskell more intimidating, when we should be trying as much as we can to make it less! Tom From blamario at ciktel.net Sun Feb 10 01:52:49 2019 From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Sat, 9 Feb 2019 20:52:49 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: On 2019-02-08 1:45 p.m., Edward Kmett wrote: > > That sort of "magic" might be useful for making migration plans to get > sequenceA to be sequence and mapM and traverse without requiring folks > to memorize which one is in the class and which is a top level definition. A similar sort of magic could be used for MonadOfNoReturn: we want to end up with a `return = pure` definition, not a method of any class, while all the existing code still compiles. Or is that migration plan already fully covered by existing magic tricks? From ryan.reich at gmail.com Sun Feb 10 04:15:30 2019 From: ryan.reich at gmail.com (Ryan Reich) Date: Sat, 9 Feb 2019 20:15:30 -0800 Subject: add map back to Functor In-Reply-To: References: Message-ID: This pragma needs to have a type inference guarantee that the old signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting `fmap :: (Functor f) => (a -> b) -> f a -> f b`. There must be approximately one zillion ad-hoc functions out there written without type signatures that implicitly depend on inferring a list. On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald wrote: > You make a good point, we should cook up this desired magic pragma! > > Could you sketch out 1-2 examples of what you’d want this pragma to do? > > Something like > {-# method_synonym_of fmap map #-} > ? > This would sort of be like a sort of duplicate record field for how names > are mapped to definitions? > This example would be “fmap is an alias of map” > > > On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett wrote: > >> The real problem with this sketch of a proposal is the lack of a nice >> migration plan. >> >> If it is top level and just calls fmap, then the distinction requires >> random rote memorization of which one you can define. >> >> On the other hand, say you put it in Functor today as an extra member. >> Currently everybody has definitions in terms of `fmap`, so you'd need to >> make the two definitions mutual. This would mean enlarging the dictionaries >> for one of the most common structures in Haskell for a rather far flung >> removal that breaks everyone. >> >> If we had a way (say a pragma or other syntactic form) to say that fmap >> and map were somehow the 'same name' or something and so that defining one >> was the same as defining the other, so that this tax didn't exist, I could >> see how we might get there. >> >> That sort of "magic" might be useful for making migration plans to get >> sequenceA to be sequence and mapM and traverse without requiring folks to >> memorize which one is in the class and which is a top level definition. >> >> Without something like that, I'd remain somewhat inclined against >> concocting a complicated migration plan to save one letter. >> >> -Edward >> >> On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> harkening back to the old Haskell 1.5 days, Lets have map back in >>> functor. it "F"- strange to not have our lovely maps be functorial by >>> default. >>> >>> I think it would be a genuine boon for old and new haskellers alike, and >>> those who disagree with this change already use alt-preludes for pedagogy >>> reasons anyways >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.reich at gmail.com Sun Feb 10 04:27:55 2019 From: ryan.reich at gmail.com (Ryan Reich) Date: Sat, 9 Feb 2019 20:27:55 -0800 Subject: add map back to Functor In-Reply-To: References: Message-ID: ...which is a problem, because you can't distinguish code that was written (either before or after the pragma is introduced) with the assumption of a list in mind from code (written after the pragma is introduced) that intends to use the generalized type signature. This is different from the situation created by `instance Functor [] where {fmap = map}`, which introduces a specialization of `fmap` rather than a generalization of `map`. On Sat, Feb 9, 2019 at 8:15 PM Ryan Reich wrote: > This pragma needs to have a type inference guarantee that the old > signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting > `fmap :: (Functor f) => (a -> b) -> f a -> f b`. There must be > approximately one zillion ad-hoc functions out there written without type > signatures that implicitly depend on inferring a list. > > On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> You make a good point, we should cook up this desired magic pragma! >> >> Could you sketch out 1-2 examples of what you’d want this pragma to do? >> >> Something like >> {-# method_synonym_of fmap map #-} >> ? >> This would sort of be like a sort of duplicate record field for how names >> are mapped to definitions? >> This example would be “fmap is an alias of map” >> >> >> On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett wrote: >> >>> The real problem with this sketch of a proposal is the lack of a nice >>> migration plan. >>> >>> If it is top level and just calls fmap, then the distinction requires >>> random rote memorization of which one you can define. >>> >>> On the other hand, say you put it in Functor today as an extra member. >>> Currently everybody has definitions in terms of `fmap`, so you'd need to >>> make the two definitions mutual. This would mean enlarging the dictionaries >>> for one of the most common structures in Haskell for a rather far flung >>> removal that breaks everyone. >>> >>> If we had a way (say a pragma or other syntactic form) to say that fmap >>> and map were somehow the 'same name' or something and so that defining one >>> was the same as defining the other, so that this tax didn't exist, I could >>> see how we might get there. >>> >>> That sort of "magic" might be useful for making migration plans to get >>> sequenceA to be sequence and mapM and traverse without requiring folks to >>> memorize which one is in the class and which is a top level definition. >>> >>> Without something like that, I'd remain somewhat inclined against >>> concocting a complicated migration plan to save one letter. >>> >>> -Edward >>> >>> On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> harkening back to the old Haskell 1.5 days, Lets have map back in >>>> functor. it "F"- strange to not have our lovely maps be functorial by >>>> default. >>>> >>>> I think it would be a genuine boon for old and new haskellers alike, >>>> and those who disagree with this change already use alt-preludes for >>>> pedagogy reasons anyways >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Sun Feb 10 18:12:57 2019 From: chessai1996 at gmail.com (chessai .) Date: Sun, 10 Feb 2019 13:12:57 -0500 Subject: Proposal: transformers/mtl Applicative Relaxation Message-ID: I think given AMP that transformers should use CPP to relax Monad constraints to Applicative on newer versions of base. As an example: except :: (Monad m) => Either e a -> ExceptT e m a except m = ExceptT (return m) could become except :: (Applicative m) => Either e a -> ExceptT e m a except m = ExceptT (pure m) Similarly some typeclasses in mtl could do with some relaxation. A related issue: https://github.com/haskell/mtl/issues/35 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Sun Feb 10 21:16:43 2019 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun, 10 Feb 2019 21:16:43 +0000 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> Message-ID: <660a1e5e-bece-6199-bd87-96b408c729c9@earth.li> Wouldn't having both quiet and signalling NaN types imply wrapping all the primitive operations for one or other type in a CPU state switch? Maybe the compiler could then optimise some away. On 08/02/2019 19:07, Lennart Augustsson wrote: > I would *hate* to lose quiet NaNs.  They can be very useful.  But I’d be > fine having them as a separate type. > > And while we’re at it, why not make Int overflow and underflow cause a > trap as well?  With a different type if you want to wrap.  > > > On Fri, Feb 8, 2019 at 08:34 Carter Schonwald > > wrote: > > Thanks for eloquently summarizing , better than I would , what I > thought I had laid out.  > > Ieee floating point has fantastic hardware support .  May as well be > the first real language to actually use it correctly. :) > > On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten > > wrote: > > > > > On 8 Feb 2019, at 10:57, Sven Panne > wrote: > > > > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten > >: > > Our goal is to make "compare NaN n" impossible to happen. [...] > > > > Well, what is supposed to happen then when you *do* see a NaN, > e.g. one produced from a foreign call? You *will* see NaNs in > Haskell if you interact with other languages, most of them take > a far less religious approach to floating points calculations. > > This is not true. As Carter pointed out we can setup the CPU to > trap NaNs *even in foreign calls*. So, in theory we CAN rule > this out safely. Doing this we can simply convert the trap into > an exception at the FFI boundary. > > Now, there are cases were this is problematic, so as said before > we will probably need to allow people to optionally switch on > 'value NaNs', because the foreign code isn't exception safe or > for other reasons, but this is manageable. Via, for example > having an annotation on foreign imports whether you want to trap > or not. > > In the scenario where someone switches to value NaNs, we are > *still* not worse off than we are now. The things you suggest > already happen *now*, so the only thing we're advocating is > making it possible to have more sane behaviour in the future. > > Any IEEE-754 compliant implementation of Double that doesn't use > trapping NaN can, by definition, never ever be a sane > implementation of Ord. As IEEE-754 *requires* "NaN /= NaN", so > equality symmetry doesn't apply to NaNs and there is *no* safe > way to sort/order data containing NaNs. > > I've run into several nasty issues of trying to sort lists > containing NaNs (not just Haskell, also Python and C) and it's > *not* just the NaNs that are affected, entire subsequences end > up getting sorted wrong based on the comparison with NaN and you > end up with completely garbled and unsorted data. > > In other words, there are only two ways to get sane behaviour > from Double with regards to ordering: > > 1. Trapping NaN represenation > 2. Deviate from IEEE-754 semantics > > To me, option 2 is out of the question, it's the one consistent > thing across language we have when it comes to floating point. I > understand that *always* using trap representation isn't > feasible, but allowing people to optionally switch to value NaNs > leaves us no worse off than we are *right now*, and per above, > there is literally no way to improve the situation wrt value > NaNs without sacrificing IEEE-754 compliance. > > Cheers, > Merijn > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From carter.schonwald at gmail.com Mon Feb 11 18:03:01 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 11 Feb 2019 13:03:01 -0500 Subject: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report In-Reply-To: <660a1e5e-bece-6199-bd87-96b408c729c9@earth.li> References: <2B9E12CD-F62B-41DE-9D38-F4DE37B6534F@inconsistent.nl> <27D8CD27-55E5-4B0E-9284-24B00EFDB7F2@inconsistent.nl> <660a1e5e-bece-6199-bd87-96b408c729c9@earth.li> Message-ID: Hey Ganesh, because of how float stuff works, the code generated will be the same either way. On Sun, Feb 10, 2019 at 4:17 PM Ganesh Sittampalam wrote: > Wouldn't having both quiet and signalling NaN types imply wrapping all > the primitive operations for one or other type in a CPU state switch? > Maybe the compiler could then optimise some away. > > On 08/02/2019 19:07, Lennart Augustsson wrote: > > I would *hate* to lose quiet NaNs. They can be very useful. But I’d be > > fine having them as a separate type. > > > > And while we’re at it, why not make Int overflow and underflow cause a > > trap as well? With a different type if you want to wrap. > > > > > > On Fri, Feb 8, 2019 at 08:34 Carter Schonwald > > > wrote: > > > > Thanks for eloquently summarizing , better than I would , what I > > thought I had laid out. > > > > Ieee floating point has fantastic hardware support . May as well be > > the first real language to actually use it correctly. :) > > > > On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten > > > wrote: > > > > > > > > > On 8 Feb 2019, at 10:57, Sven Panne > > wrote: > > > > > > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten > > >: > > > Our goal is to make "compare NaN n" impossible to happen. [...] > > > > > > Well, what is supposed to happen then when you *do* see a NaN, > > e.g. one produced from a foreign call? You *will* see NaNs in > > Haskell if you interact with other languages, most of them take > > a far less religious approach to floating points calculations. > > > > This is not true. As Carter pointed out we can setup the CPU to > > trap NaNs *even in foreign calls*. So, in theory we CAN rule > > this out safely. Doing this we can simply convert the trap into > > an exception at the FFI boundary. > > > > Now, there are cases were this is problematic, so as said before > > we will probably need to allow people to optionally switch on > > 'value NaNs', because the foreign code isn't exception safe or > > for other reasons, but this is manageable. Via, for example > > having an annotation on foreign imports whether you want to trap > > or not. > > > > In the scenario where someone switches to value NaNs, we are > > *still* not worse off than we are now. The things you suggest > > already happen *now*, so the only thing we're advocating is > > making it possible to have more sane behaviour in the future. > > > > Any IEEE-754 compliant implementation of Double that doesn't use > > trapping NaN can, by definition, never ever be a sane > > implementation of Ord. As IEEE-754 *requires* "NaN /= NaN", so > > equality symmetry doesn't apply to NaNs and there is *no* safe > > way to sort/order data containing NaNs. > > > > I've run into several nasty issues of trying to sort lists > > containing NaNs (not just Haskell, also Python and C) and it's > > *not* just the NaNs that are affected, entire subsequences end > > up getting sorted wrong based on the comparison with NaN and you > > end up with completely garbled and unsorted data. > > > > In other words, there are only two ways to get sane behaviour > > from Double with regards to ordering: > > > > 1. Trapping NaN represenation > > 2. Deviate from IEEE-754 semantics > > > > To me, option 2 is out of the question, it's the one consistent > > thing across language we have when it comes to floating point. I > > understand that *always* using trap representation isn't > > feasible, but allowing people to optionally switch to value NaNs > > leaves us no worse off than we are *right now*, and per above, > > there is literally no way to improve the situation wrt value > > NaNs without sacrificing IEEE-754 compliance. > > > > Cheers, > > Merijn > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Feb 11 18:14:54 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 11 Feb 2019 13:14:54 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: no, map should have the more general type :) On Sat, Feb 9, 2019 at 11:28 PM Ryan Reich wrote: > ...which is a problem, because you can't distinguish code that was written > (either before or after the pragma is introduced) with the assumption of a > list in mind from code (written after the pragma is introduced) that > intends to use the generalized type signature. This is different from the > situation created by `instance Functor [] where {fmap = map}`, which > introduces a specialization of `fmap` rather than a generalization of `map`. > > On Sat, Feb 9, 2019 at 8:15 PM Ryan Reich wrote: > >> This pragma needs to have a type inference guarantee that the old >> signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting >> `fmap :: (Functor f) => (a -> b) -> f a -> f b`. There must be >> approximately one zillion ad-hoc functions out there written without type >> signatures that implicitly depend on inferring a list. >> >> On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> You make a good point, we should cook up this desired magic pragma! >>> >>> Could you sketch out 1-2 examples of what you’d want this pragma to do? >>> >>> Something like >>> {-# method_synonym_of fmap map #-} >>> ? >>> This would sort of be like a sort of duplicate record field for how >>> names are mapped to definitions? >>> This example would be “fmap is an alias of map” >>> >>> >>> On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett wrote: >>> >>>> The real problem with this sketch of a proposal is the lack of a nice >>>> migration plan. >>>> >>>> If it is top level and just calls fmap, then the distinction requires >>>> random rote memorization of which one you can define. >>>> >>>> On the other hand, say you put it in Functor today as an extra member. >>>> Currently everybody has definitions in terms of `fmap`, so you'd need to >>>> make the two definitions mutual. This would mean enlarging the dictionaries >>>> for one of the most common structures in Haskell for a rather far flung >>>> removal that breaks everyone. >>>> >>>> If we had a way (say a pragma or other syntactic form) to say that fmap >>>> and map were somehow the 'same name' or something and so that defining one >>>> was the same as defining the other, so that this tax didn't exist, I could >>>> see how we might get there. >>>> >>>> That sort of "magic" might be useful for making migration plans to get >>>> sequenceA to be sequence and mapM and traverse without requiring folks to >>>> memorize which one is in the class and which is a top level definition. >>>> >>>> Without something like that, I'd remain somewhat inclined against >>>> concocting a complicated migration plan to save one letter. >>>> >>>> -Edward >>>> >>>> On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald < >>>> carter.schonwald at gmail.com> wrote: >>>> >>>>> harkening back to the old Haskell 1.5 days, Lets have map back in >>>>> functor. it "F"- strange to not have our lovely maps be functorial by >>>>> default. >>>>> >>>>> I think it would be a genuine boon for old and new haskellers alike, >>>>> and those who disagree with this change already use alt-preludes for >>>>> pedagogy reasons anyways >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Feb 11 18:15:33 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 11 Feb 2019 13:15:33 -0500 Subject: add map back to Functor In-Reply-To: References: Message-ID: and the alluded extension / pragma idea would be for equi typed names,not for anyting fancy about type subsumption On Mon, Feb 11, 2019 at 1:14 PM Carter Schonwald wrote: > no, map should have the more general type :) > > On Sat, Feb 9, 2019 at 11:28 PM Ryan Reich wrote: > >> ...which is a problem, because you can't distinguish code that was >> written (either before or after the pragma is introduced) with the >> assumption of a list in mind from code (written after the pragma is >> introduced) that intends to use the generalized type signature. This is >> different from the situation created by `instance Functor [] where {fmap = >> map}`, which introduces a specialization of `fmap` rather than a >> generalization of `map`. >> >> On Sat, Feb 9, 2019 at 8:15 PM Ryan Reich wrote: >> >>> This pragma needs to have a type inference guarantee that the old >>> signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting >>> `fmap :: (Functor f) => (a -> b) -> f a -> f b`. There must be >>> approximately one zillion ad-hoc functions out there written without type >>> signatures that implicitly depend on inferring a list. >>> >>> On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> You make a good point, we should cook up this desired magic pragma! >>>> >>>> Could you sketch out 1-2 examples of what you’d want this pragma to do? >>>> >>>> Something like >>>> {-# method_synonym_of fmap map #-} >>>> ? >>>> This would sort of be like a sort of duplicate record field for how >>>> names are mapped to definitions? >>>> This example would be “fmap is an alias of map” >>>> >>>> >>>> On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett wrote: >>>> >>>>> The real problem with this sketch of a proposal is the lack of a nice >>>>> migration plan. >>>>> >>>>> If it is top level and just calls fmap, then the distinction requires >>>>> random rote memorization of which one you can define. >>>>> >>>>> On the other hand, say you put it in Functor today as an extra member. >>>>> Currently everybody has definitions in terms of `fmap`, so you'd need to >>>>> make the two definitions mutual. This would mean enlarging the dictionaries >>>>> for one of the most common structures in Haskell for a rather far flung >>>>> removal that breaks everyone. >>>>> >>>>> If we had a way (say a pragma or other syntactic form) to say that >>>>> fmap and map were somehow the 'same name' or something and so that defining >>>>> one was the same as defining the other, so that this tax didn't exist, I >>>>> could see how we might get there. >>>>> >>>>> That sort of "magic" might be useful for making migration plans to get >>>>> sequenceA to be sequence and mapM and traverse without requiring folks to >>>>> memorize which one is in the class and which is a top level definition. >>>>> >>>>> Without something like that, I'd remain somewhat inclined against >>>>> concocting a complicated migration plan to save one letter. >>>>> >>>>> -Edward >>>>> >>>>> On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald < >>>>> carter.schonwald at gmail.com> wrote: >>>>> >>>>>> harkening back to the old Haskell 1.5 days, Lets have map back in >>>>>> functor. it "F"- strange to not have our lovely maps be functorial by >>>>>> default. >>>>>> >>>>>> I think it would be a genuine boon for old and new haskellers alike, >>>>>> and those who disagree with this change already use alt-preludes for >>>>>> pedagogy reasons anyways >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> >>>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Mon Feb 11 22:35:04 2019 From: danburton.email at gmail.com (Dan Burton) Date: Mon, 11 Feb 2019 17:35:04 -0500 Subject: Taking over haskell-src-meta Message-ID: I, Dan Burton, intend to take over maintenance of haskell-src-meta. -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: From theindigamer15 at gmail.com Sat Feb 16 00:04:43 2019 From: theindigamer15 at gmail.com (theindigamer) Date: Fri, 15 Feb 2019 19:04:43 -0500 Subject: Add newtype for Alternative using QuantifiedConstraints in base-4.13 Message-ID: Thoughts on adding a newtype with the following Alternative instance? (The name chosen is a placeholder, I don't have any particular preference). newtype Mon f a = Mon { unMon :: f a } instance (forall a. Monoid (f a)) => Alternative (Mon f) where empty = Mon mempty (<|>) (Mon m1) (Mon m2) = Mon (m1 <> m2) -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Feb 16 00:11:35 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 15 Feb 2019 19:11:35 -0500 Subject: Add newtype for Alternative using QuantifiedConstraints in base-4.13 In-Reply-To: References: Message-ID: this looks quite pretty, though I must admit that im not the most savvy at quantified constraints yet wouldn't this newtype also benefit from a semigroup and monoid instance too? (or am I overlooking some reason why you can't do them too?) On Fri, Feb 15, 2019 at 7:05 PM theindigamer wrote: > Thoughts on adding a newtype with the following Alternative instance? > > (The name chosen is a placeholder, I don't have any particular preference). > > newtype Mon f a = Mon { unMon :: f a } > > instance (forall a. Monoid (f a)) => Alternative (Mon f) where > empty = Mon mempty > (<|>) (Mon m1) (Mon m2) = Mon (m1 <> m2) > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theindigamer15 at gmail.com Sat Feb 16 00:20:16 2019 From: theindigamer15 at gmail.com (theindigamer) Date: Fri, 15 Feb 2019 19:20:16 -0500 Subject: Add newtype for Alternative using QuantifiedConstraints in base-4.13 In-Reply-To: References: Message-ID: I'm not sure which implementation you have in mind - the newtype one? I suppose that it would be harmless to add it in, although I don't immediately see the use case. On Fri, Feb 15, 2019 at 7:11 PM Carter Schonwald wrote: > this looks quite pretty, though I must admit that im not the most savvy at > quantified constraints yet > > wouldn't this newtype also benefit from a semigroup and monoid instance > too? (or am I overlooking some reason why you can't do them too?) > > On Fri, Feb 15, 2019 at 7:05 PM theindigamer > wrote: > >> Thoughts on adding a newtype with the following Alternative instance? >> >> (The name chosen is a placeholder, I don't have any particular preference). >> >> newtype Mon f a = Mon { unMon :: f a } >> >> instance (forall a. Monoid (f a)) => Alternative (Mon f) where >> empty = Mon mempty >> (<|>) (Mon m1) (Mon m2) = Mon (m1 <> m2) >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Sun Feb 17 05:13:44 2019 From: chessai1996 at gmail.com (chessai .) Date: Sun, 17 Feb 2019 00:13:44 -0500 Subject: Add 'e' to Floating typeclass Message-ID: We have the 'pi' constant in the floating typeclass and some trigonometric functions, as well as things like exp/log/expm1/log1p. Why not provide an 'e' constant? A default implementation could just be 'exp 1'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From byorgey at gmail.com Sun Feb 17 15:30:46 2019 From: byorgey at gmail.com (Brent Yorgey) Date: Sun, 17 Feb 2019 09:30:46 -0600 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: Because it would cause a shadowing warning with every program that ever used the variable name 'e'. This doesn't really seem worth it. On Sat, Feb 16, 2019 at 11:14 PM chessai . wrote: > We have the 'pi' constant in the floating typeclass and some trigonometric > functions, as well as things like exp/log/expm1/log1p. > > Why not provide an 'e' constant? > > A default implementation could just be 'exp 1'. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Feb 17 15:39:52 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 17 Feb 2019 10:39:52 -0500 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: There’s at least two reasons why I think this would be a bad idea 1) everyone uses e as a local variable name, or at least it happens often enough. This would breaklots of code 2 ) I’m not sure if there’s ever a better definition than exp 1. Is there? 3) more strongly , does every instance in the Wild give a full ish precision exact up to representation limits answer at exp 1,? I only thought of the name space issue after I stated writing this email , but I think that kills it.. but I am genuinely curious : can we treat exp 1 as being the actual definition for any all quality instances ? On Sun, Feb 17, 2019 at 12:14 AM chessai . wrote: > We have the 'pi' constant in the floating typeclass and some trigonometric > functions, as well as things like exp/log/expm1/log1p. > > Why not provide an 'e' constant? > > A default implementation could just be 'exp 1'. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Feb 17 15:40:44 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 17 Feb 2019 10:40:44 -0500 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: I meant shaddowing warning. As Brent more correctly said. On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald < carter.schonwald at gmail.com> wrote: > There’s at least two reasons why I think this would be a bad idea > > 1) everyone uses e as a local variable name, or at least it happens often > enough. This would breaklots of code > > 2 ) I’m not sure if there’s ever a better definition than exp 1. Is > there? > > 3) more strongly , does every instance in the Wild give a full ish > precision exact up to representation limits answer at exp 1,? > > I only thought of the name space issue after I stated writing this email , > but I think that kills it.. but I am genuinely curious : can we treat exp 1 > as being the actual definition for any all quality instances ? > > On Sun, Feb 17, 2019 at 12:14 AM chessai . wrote: > >> We have the 'pi' constant in the floating typeclass and some >> trigonometric functions, as well as things like exp/log/expm1/log1p. >> >> Why not provide an 'e' constant? >> >> A default implementation could just be 'exp 1'. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Sun Feb 17 19:34:07 2019 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 17 Feb 2019 21:34:07 +0200 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: Shaddowing of 'e' is not a reason not to do this - it's only a reason not to call it 'e'. There has never been a shortage of bikeshedding skills in this community. I'm sure we could come up with something if we decide to do it. At least as good as things like "GHC.Float.log1mexp" that have already been added to this typeclass. I think Carter's remarks about exp 1 are more to the point. Can we assume that every implentation special cases exp 1, or is computing exp 1 once and sharing it really satisfactory? And if so - then what's so much worse about 2 * asin 1? On Sun, Feb 17, 2019 at 5:41 PM Carter Schonwald wrote: > > I meant shaddowing warning. As Brent more correctly said. > > On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald wrote: >> >> There’s at least two reasons why I think this would be a bad idea >> >> 1) everyone uses e as a local variable name, or at least it happens often enough. This would breaklots of code >> >> 2 ) I’m not sure if there’s ever a better definition than exp 1. Is there? >> >> 3) more strongly , does every instance in the Wild give a full ish precision exact up to representation limits answer at exp 1,? >> >> I only thought of the name space issue after I stated writing this email , but I think that kills it.. but I am genuinely curious : can we treat exp 1 as being the actual definition for any all quality instances ? >> >> On Sun, Feb 17, 2019 at 12:14 AM chessai . wrote: >>> >>> We have the 'pi' constant in the floating typeclass and some trigonometric functions, as well as things like exp/log/expm1/log1p. >>> >>> Why not provide an 'e' constant? >>> >>> A default implementation could just be 'exp 1'. >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From carter.schonwald at gmail.com Sun Feb 17 20:11:38 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 17 Feb 2019 15:11:38 -0500 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: While I understand the intent of your point yitzchak, inverse sine is less intrinsically uniquely defined than exp. in at least the sense that it’s not uniquely defined in two senses 1)inverse sine and inverse cosine only are defined over the interval -1 through +1, a domain restriction that can’t be modeled all that well 2) we are usually talking about the “branch cut” of solutions in the closed/open interval [0,2pi), but the set of numbers pi *(1+2n), for n an integer are all valid solutions. A similar issue comes up with the natural logarithm when we look at things over the complex numbers There’s no such holes or gaps in relating e and exp. You do raise a good point about computing ... and the answer I think depends on whether the data type of interest has a static or dynamic character to its precision in representation. And or the precision / compute tradeoffs thereof. Let alone anything with explicit support for computer algebra fun! On Sun, Feb 17, 2019 at 2:34 PM Yitzchak Gale wrote: > Shaddowing of 'e' is not a reason not to do this - it's only a reason > not to call it 'e'. There has never been a shortage of bikeshedding > skills in this community. I'm sure we could come up with something if > we decide to do it. At least as good as things like > "GHC.Float.log1mexp" that have already been added to this typeclass. > > I think Carter's remarks about exp 1 are more to the point. Can we > assume that every implentation special cases exp 1, or is computing > exp 1 once and sharing it really satisfactory? And if so - then what's > so much worse about 2 * asin 1? > > On Sun, Feb 17, 2019 at 5:41 PM Carter Schonwald > wrote: > > > > I meant shaddowing warning. As Brent more correctly said. > > > > On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> > >> There’s at least two reasons why I think this would be a bad idea > >> > >> 1) everyone uses e as a local variable name, or at least it happens > often enough. This would breaklots of code > >> > >> 2 ) I’m not sure if there’s ever a better definition than exp 1. Is > there? > >> > >> 3) more strongly , does every instance in the Wild give a full ish > precision exact up to representation limits answer at exp 1,? > >> > >> I only thought of the name space issue after I stated writing this > email , but I think that kills it.. but I am genuinely curious : can we > treat exp 1 as being the actual definition for any all quality instances ? > >> > >> On Sun, Feb 17, 2019 at 12:14 AM chessai . > wrote: > >>> > >>> We have the 'pi' constant in the floating typeclass and some > trigonometric functions, as well as things like exp/log/expm1/log1p. > >>> > >>> Why not provide an 'e' constant? > >>> > >>> A default implementation could just be 'exp 1'. > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lennart at augustsson.net Sun Feb 17 20:15:08 2019 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun, 17 Feb 2019 12:15:08 -0800 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: Is it really worth it? How frequent are uses of e, except used like exp? On the other hand, pi has more frequent standalone use cases. Also, e has a simple definition (exp 1), whereas pi is somewhat more involved. The logp1 and expm1 functions where added for good numerical reasons. The same would not be true for e. On Sat, Feb 16, 2019 at 21:14 chessai . wrote: > We have the 'pi' constant in the floating typeclass and some trigonometric > functions, as well as things like exp/log/expm1/log1p. > > Why not provide an 'e' constant? > > A default implementation could just be 'exp 1'. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george at wils.online Sun Feb 17 23:56:24 2019 From: george at wils.online (George Wilson) Date: Mon, 18 Feb 2019 09:56:24 +1000 Subject: Add newtype for Alternative using QuantifiedConstraints in base-4.13 In-Reply-To: References: Message-ID: It'll have to use the underlying Functor and Applicative to get an Alternative. Could you give some examples where you'd like to use this? I don't like the name but don't have a better one off the top of my head. AltMonoid or something? On Sat, 16 Feb 2019 at 10:20, theindigamer wrote: > > I'm not sure which implementation you have in mind - the newtype one? > I suppose that it would be harmless to add it in, although I don't immediately > see the use case. > > > On Fri, Feb 15, 2019 at 7:11 PM Carter Schonwald wrote: >> >> this looks quite pretty, though I must admit that im not the most savvy at quantified constraints yet >> >> wouldn't this newtype also benefit from a semigroup and monoid instance too? (or am I overlooking some reason why you can't do them too?) >> >> On Fri, Feb 15, 2019 at 7:05 PM theindigamer wrote: >>> >>> Thoughts on adding a newtype with the following Alternative instance? >>> >>> (The name chosen is a placeholder, I don't have any particular preference). >>> >>> newtype Mon f a = Mon { unMon :: f a } >>> >>> instance (forall a. Monoid (f a)) => Alternative (Mon f) where >>> empty = Mon mempty >>> (<|>) (Mon m1) (Mon m2) = Mon (m1 <> m2) >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From ruben.astud at gmail.com Mon Feb 18 00:29:24 2019 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Sun, 17 Feb 2019 21:29:24 -0300 Subject: Fwd: Add newtype for Alternative using QuantifiedConstraints in base-4.13 In-Reply-To: References: Message-ID: <0cbe8084-d01d-e6c0-6860-be0ae95a208f@gmail.com> Forwarding the replies sent incorrectly to -cafe. -------- Forwarded Message -------- Subject: Re: Add newtype for Alternative using QuantifiedConstraints in base-4.13 Date: Sun, 17 Feb 2019 21:05:12 -0300 From: Ruben Astudillo To: theindigamer , Haskell Cafe I wonder if it is useful at all. If `f a` already has a Monoid instance, you can use `(<>)` already instead of (<|>) with pretty much the same laws. Plus you don't have to import `(<>)` as it comes from the Prelude where `(<|>)` doesn't. Does this have an use case or is just for aesthetic completeness? -- -- Ruben -- pgp: 4EE9 28F7 932E F4AD -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4EE928F7932EF4AD.asc Type: application/pgp-keys Size: 13938 bytes Desc: not available URL: From wolfgang-it at jeltsch.info Mon Feb 18 20:19:13 2019 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Mon, 18 Feb 2019 22:19:13 +0200 Subject: Add newtype for Alternative using QuantifiedConstraints in base-4.13 In-Reply-To: References: Message-ID: <1550521153.14010.183.camel@jeltsch.info> Am Freitag, den 15.02.2019, 19:04 -0500 schrieb theindigamer: > Thoughts on adding a newtype with the following Alternative instance? > (The name chosen is a placeholder, I don't have any particular > preference). > >     newtype Mon f a = Mon { unMon :: f a } > >     instance (forall a. Monoid (f a)) => Alternative (Mon f) where > >         empty = Mon mempty > >         (<|>) (Mon m1) (Mon m2) = Mon (m1 <> m2) If I remember correctly, then something that is an `Applicative` and a `Monoid` isn’t necessarily an `Alternative` and something that is a `Monad` and a `Monoid` isn’t necessarily a `MonadPlus`. There are certain axioms that are supposed to hold, which link the `Applicative` or `Monad` structure to the `Monoid` structure. At least this is how it ought to be. For details see the paper [“From Monoids to Near-Semirings: The Essence of `MonadPlus` and `Alternative`”][*]. All the best, Wolfgang [*]:     https://usuarios.fceia.unr.edu.ar/~mauro/pubs/FromMonoidstoNearsemirings.pdf "From Monoids to Near-Semirings: The Essence of `MonadPlus` and `Alternative`" From haskell at marcelfourne.de Tue Feb 19 14:25:40 2019 From: haskell at marcelfourne.de (Marcel =?UTF-8?B?Rm91cm7DqQ==?=) Date: Tue, 19 Feb 2019 15:25:40 +0100 Subject: ANNOUNCE: eccrypto 0.1.0, timing attack safe cryptography in Haskell Message-ID: <20190219152540.05bcadb4@deck> Dear Haskell Community! I'd like to introduce some new cryptographic code, containing a verified[*] timing-attack safe pure Haskell[**] implementation of Ed25519 and as of yet unverified implementations of textbook ECDH and ECDSA on the NIST prime curves. Install it by $ cabal install eccrypto or download it from Hackage[0]. Also contained are test vectors, usable by the trusty $ cabal test as well as benchmarking code which you can invoke by $ cabal bench if you want to try my code before using it. Please note that this is a one person project, so there is still much room for optimization. The intended focus groups are implementors of cryptographic protocols as well as other cryptographers and interested third parties. My code uses no[**] embedded C code or assembly to achieve timing attack resistance, only careful Haskell constructions in the internal modules, the obligatory hackers footgun included only in those. ;-) Security sketch: The timing attack safety is built on the constant time criterion, namely, that no branches or memory access indices may be based on the content of the secret key bits. The name of this criterion is from the strict evaluation world of cryptography, but does not prohibit non-strict evaluation semantics per se. The API is only slightly different from contemporary libraries like "ed25519"[1], but the content of the signatures is just the same. The number of dependencies are also in the same ballpark, if you'd like to use the code for infrastructure - but in that case, please talk to me to not use unverified/insecure operations! Best of wishes to a thriving community, Marcel Fourné [*]: paper upcoming but as of now it only exists in my notes; analysis was done "by hand" on assembly generated by GHC 8.4.4, mechanization based on established proofs is planned [**]: using integer-gmp, might change in the future to low-level Haskell [0]: https://hackage.haskell.org/package/eccrypto-0.1.0 [1]: https://hackage.haskell.org/package/ed25519 From lysxia at gmail.com Tue Feb 19 15:20:17 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Tue, 19 Feb 2019 10:20:17 -0500 Subject: Add newtype for Alternative using QuantifiedConstraints in base-4.13 (Libraries Digest, Vol 186, Issue 17) In-Reply-To: <1550521153.14010.183.camel@jeltsch.info> References: <1550521153.14010.183.camel@jeltsch.info> Message-ID: On 2/18/19 3:19 PM, Wolfgang Jeltsch wrote: > If I remember correctly, then something that is an `Applicative` and a > `Monoid` isnt necessarily an `Alternative` and something that is a > `Monad` and a `Monoid` isnt necessarily a `MonadPlus`. There are > certain axioms that are supposed to hold, which link the `Applicative` > or `Monad` structure to the `Monoid` structure. At least this is how it > ought to be. For details see the paper [From Monoids to Near-Semirings: > The Essence of `MonadPlus` and `Alternative`][*]. > > [*]: > � � https://usuarios.fceia.unr.edu.ar/~mauro/pubs/FromMonoidstoNearsemirings.pdf > "From Monoids to Near-Semirings: The Essence of `MonadPlus` and `Alternative`" > > The laws studied by that paper are not universal to Alternative instances that occur in practice, and in fact I don't think it is possible to require anything more than a monoid structure from them. Having only skimmed the paper, the only extra law not guaranteed by the proposed newtype seems to be the distributivity of join/(>>=) over (<|>) (equations 10 and 12 on page 6): join (m1 <|> m2) = join m1 <|> join m2 or (m1 <|> m2) >>= k = (m1 >>= k) <|> (m2 >>= k) (I believe 9 and 11 must hold by parametricity (under reasonable conditions), hence they can be ignored.) These equations are not satisfied by existing instances like Maybe and most parser monads (as noted in the paper), because it requires too much backtracking. The paper mentions another, incompatible law (13 on page 7), that has also been studied elsewhere, and that one could push for: pure a <|> b = pure a But the ship has already sailed: there are plenty of Alternative instances in use that violate either (or possibly both) of these laws. Beyond a monoid structure, I don't know any other law that can be uncontroversially expected from Alternative instances. If indeed no other universal requirement can be found, the proposed newtype is acceptable from the point of view of laws. It might be better to document those extra laws in a non-prescriptive fashion, to tell users of Alternative that "it might be enlightening to consider whether your functor satisfies those laws". Regards, Li-yao From gale at sefer.org Wed Feb 20 13:30:07 2019 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 20 Feb 2019 15:30:07 +0200 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: Lennart's question "Is it really worth it?" is the most important one. And no, probably it isn't. But Chessai is correct that this is a weird asymmetry in the Floating class. My own experience is that I user neither e nor pi very much, but neither one more than the other. Branch cuts of inverse trig functions are not relevant. The report doesn't explicitly state this, but it's clear that these functions are expected to return the standard ranges of values as in other programming languages. You can be quite certain that acos (-1) is pi in Haskell. And in fact, we have (at least on my computer) Prelude> acos (-1) == pi True So there isn't any more or less reason to have e than pi as a separate class member. On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson wrote: > > Is it really worth it? How frequent are uses of e, except used like exp? On the other hand, pi has more frequent standalone use cases. > Also, e has a simple definition (exp 1), whereas pi is somewhat more involved. > > The logp1 and expm1 functions where added for good numerical reasons. The same would not be true for e. > > On Sat, Feb 16, 2019 at 21:14 chessai . wrote: >> >> We have the 'pi' constant in the floating typeclass and some trigonometric functions, as well as things like exp/log/expm1/log1p. >> >> Why not provide an 'e' constant? >> >> A default implementation could just be 'exp 1'. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From carter.schonwald at gmail.com Thu Feb 21 02:22:02 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 20 Feb 2019 21:22:02 -0500 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: either way, we're not gonna add e :) On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote: > Lennart's question "Is it really worth it?" is the most important one. > And no, probably it isn't. > > But Chessai is correct that this is a weird asymmetry in the Floating > class. My own experience is that I user neither e nor pi very much, > but neither one more than the other. > > Branch cuts of inverse trig functions are not relevant. The report > doesn't explicitly state this, but it's clear that these functions are > expected to return the standard ranges of values as in other > programming languages. You can be quite certain that acos (-1) is pi > in Haskell. And in fact, we have (at least on my computer) > > Prelude> acos (-1) == pi > True > > So there isn't any more or less reason to have e than pi as a separate > class member. > > On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson > wrote: > > > > Is it really worth it? How frequent are uses of e, except used like > exp? On the other hand, pi has more frequent standalone use cases. > > Also, e has a simple definition (exp 1), whereas pi is somewhat more > involved. > > > > The logp1 and expm1 functions where added for good numerical reasons. > The same would not be true for e. > > > > On Sat, Feb 16, 2019 at 21:14 chessai . wrote: > >> > >> We have the 'pi' constant in the floating typeclass and some > trigonometric functions, as well as things like exp/log/expm1/log1p. > >> > >> Why not provide an 'e' constant? > >> > >> A default implementation could just be 'exp 1'. > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Thu Feb 21 03:50:32 2019 From: chessai1996 at gmail.com (chessai .) Date: Wed, 20 Feb 2019 22:50:32 -0500 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: Yeah, I think it probably shouldn't be added to the typeclass then. The asymmetry should probably be mentioned in the report though. On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald wrote: > either way, we're not gonna add e :) > > On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote: > >> Lennart's question "Is it really worth it?" is the most important one. >> And no, probably it isn't. >> >> But Chessai is correct that this is a weird asymmetry in the Floating >> class. My own experience is that I user neither e nor pi very much, >> but neither one more than the other. >> >> Branch cuts of inverse trig functions are not relevant. The report >> doesn't explicitly state this, but it's clear that these functions are >> expected to return the standard ranges of values as in other >> programming languages. You can be quite certain that acos (-1) is pi >> in Haskell. And in fact, we have (at least on my computer) >> >> Prelude> acos (-1) == pi >> True >> >> So there isn't any more or less reason to have e than pi as a separate >> class member. >> >> On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson >> wrote: >> > >> > Is it really worth it? How frequent are uses of e, except used like >> exp? On the other hand, pi has more frequent standalone use cases. >> > Also, e has a simple definition (exp 1), whereas pi is somewhat more >> involved. >> > >> > The logp1 and expm1 functions where added for good numerical reasons. >> The same would not be true for e. >> > >> > On Sat, Feb 16, 2019 at 21:14 chessai . wrote: >> >> >> >> We have the 'pi' constant in the floating typeclass and some >> trigonometric functions, as well as things like exp/log/expm1/log1p. >> >> >> >> Why not provide an 'e' constant? >> >> >> >> A default implementation could just be 'exp 1'. >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 21 18:22:10 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 21 Feb 2019 13:22:10 -0500 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: i dont see it as an assymetry, theres a lot of very simple volume / area / probability /geometry calculations where pi comes up, i dont know any for e that aren't just exp. can you share some? On Wed, Feb 20, 2019 at 10:50 PM chessai . wrote: > Yeah, I think it probably shouldn't be added to the typeclass then. > > The asymmetry should probably be mentioned in the report though. > > > On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald > wrote: > >> either way, we're not gonna add e :) >> >> On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote: >> >>> Lennart's question "Is it really worth it?" is the most important one. >>> And no, probably it isn't. >>> >>> But Chessai is correct that this is a weird asymmetry in the Floating >>> class. My own experience is that I user neither e nor pi very much, >>> but neither one more than the other. >>> >>> Branch cuts of inverse trig functions are not relevant. The report >>> doesn't explicitly state this, but it's clear that these functions are >>> expected to return the standard ranges of values as in other >>> programming languages. You can be quite certain that acos (-1) is pi >>> in Haskell. And in fact, we have (at least on my computer) >>> >>> Prelude> acos (-1) == pi >>> True >>> >>> So there isn't any more or less reason to have e than pi as a separate >>> class member. >>> >>> On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson >>> wrote: >>> > >>> > Is it really worth it? How frequent are uses of e, except used like >>> exp? On the other hand, pi has more frequent standalone use cases. >>> > Also, e has a simple definition (exp 1), whereas pi is somewhat more >>> involved. >>> > >>> > The logp1 and expm1 functions where added for good numerical reasons. >>> The same would not be true for e. >>> > >>> > On Sat, Feb 16, 2019 at 21:14 chessai . wrote: >>> >> >>> >> We have the 'pi' constant in the floating typeclass and some >>> trigonometric functions, as well as things like exp/log/expm1/log1p. >>> >> >>> >> Why not provide an 'e' constant? >>> >> >>> >> A default implementation could just be 'exp 1'. >>> >> _______________________________________________ >>> >> Libraries mailing list >>> >> Libraries at haskell.org >>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> > >>> > _______________________________________________ >>> > Libraries mailing list >>> > Libraries at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Thu Feb 21 18:31:58 2019 From: chessai1996 at gmail.com (chessai .) Date: Thu, 21 Feb 2019 13:31:58 -0500 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: asymmetry in presence, not use. When I was first learning Haskell, the absence of e along with the presence of pi in Floating confused me. It is not a disservice to users to note this asymmetry in documentation and why it is not there. On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald wrote: > i dont see it as an assymetry, theres a lot of very simple volume / area / > probability /geometry calculations where pi comes up, > i dont know any for e that aren't just exp. can you share some? > > On Wed, Feb 20, 2019 at 10:50 PM chessai . wrote: > >> Yeah, I think it probably shouldn't be added to the typeclass then. >> >> The asymmetry should probably be mentioned in the report though. >> >> >> On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> either way, we're not gonna add e :) >>> >>> On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote: >>> >>>> Lennart's question "Is it really worth it?" is the most important one. >>>> And no, probably it isn't. >>>> >>>> But Chessai is correct that this is a weird asymmetry in the Floating >>>> class. My own experience is that I user neither e nor pi very much, >>>> but neither one more than the other. >>>> >>>> Branch cuts of inverse trig functions are not relevant. The report >>>> doesn't explicitly state this, but it's clear that these functions are >>>> expected to return the standard ranges of values as in other >>>> programming languages. You can be quite certain that acos (-1) is pi >>>> in Haskell. And in fact, we have (at least on my computer) >>>> >>>> Prelude> acos (-1) == pi >>>> True >>>> >>>> So there isn't any more or less reason to have e than pi as a separate >>>> class member. >>>> >>>> On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson >>>> wrote: >>>> > >>>> > Is it really worth it? How frequent are uses of e, except used like >>>> exp? On the other hand, pi has more frequent standalone use cases. >>>> > Also, e has a simple definition (exp 1), whereas pi is somewhat more >>>> involved. >>>> > >>>> > The logp1 and expm1 functions where added for good numerical >>>> reasons. The same would not be true for e. >>>> > >>>> > On Sat, Feb 16, 2019 at 21:14 chessai . >>>> wrote: >>>> >> >>>> >> We have the 'pi' constant in the floating typeclass and some >>>> trigonometric functions, as well as things like exp/log/expm1/log1p. >>>> >> >>>> >> Why not provide an 'e' constant? >>>> >> >>>> >> A default implementation could just be 'exp 1'. >>>> >> _______________________________________________ >>>> >> Libraries mailing list >>>> >> Libraries at haskell.org >>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> > >>>> > _______________________________________________ >>>> > Libraries mailing list >>>> > Libraries at haskell.org >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 21 18:35:12 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 21 Feb 2019 13:35:12 -0500 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: this is a math education problem, not a library design issue. i'm asking for examples for why you expected/wanted to use e, could you please share some? :) i'm genuinely confused about where its use rather than exp happens. On Thu, Feb 21, 2019 at 1:32 PM chessai . wrote: > asymmetry in presence, not use. > > When I was first learning Haskell, the absence of e along with the > presence of pi in Floating confused me. It is not a disservice to users to > note this asymmetry in documentation and why it is not there. > > On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald > wrote: > >> i dont see it as an assymetry, theres a lot of very simple volume / area >> / probability /geometry calculations where pi comes up, >> i dont know any for e that aren't just exp. can you share some? >> >> On Wed, Feb 20, 2019 at 10:50 PM chessai . wrote: >> >>> Yeah, I think it probably shouldn't be added to the typeclass then. >>> >>> The asymmetry should probably be mentioned in the report though. >>> >>> >>> On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> either way, we're not gonna add e :) >>>> >>>> On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote: >>>> >>>>> Lennart's question "Is it really worth it?" is the most important one. >>>>> And no, probably it isn't. >>>>> >>>>> But Chessai is correct that this is a weird asymmetry in the Floating >>>>> class. My own experience is that I user neither e nor pi very much, >>>>> but neither one more than the other. >>>>> >>>>> Branch cuts of inverse trig functions are not relevant. The report >>>>> doesn't explicitly state this, but it's clear that these functions are >>>>> expected to return the standard ranges of values as in other >>>>> programming languages. You can be quite certain that acos (-1) is pi >>>>> in Haskell. And in fact, we have (at least on my computer) >>>>> >>>>> Prelude> acos (-1) == pi >>>>> True >>>>> >>>>> So there isn't any more or less reason to have e than pi as a separate >>>>> class member. >>>>> >>>>> On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson >>>>> wrote: >>>>> > >>>>> > Is it really worth it? How frequent are uses of e, except used like >>>>> exp? On the other hand, pi has more frequent standalone use cases. >>>>> > Also, e has a simple definition (exp 1), whereas pi is somewhat more >>>>> involved. >>>>> > >>>>> > The logp1 and expm1 functions where added for good numerical >>>>> reasons. The same would not be true for e. >>>>> > >>>>> > On Sat, Feb 16, 2019 at 21:14 chessai . >>>>> wrote: >>>>> >> >>>>> >> We have the 'pi' constant in the floating typeclass and some >>>>> trigonometric functions, as well as things like exp/log/expm1/log1p. >>>>> >> >>>>> >> Why not provide an 'e' constant? >>>>> >> >>>>> >> A default implementation could just be 'exp 1'. >>>>> >> _______________________________________________ >>>>> >> Libraries mailing list >>>>> >> Libraries at haskell.org >>>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> > >>>>> > _______________________________________________ >>>>> > Libraries mailing list >>>>> > Libraries at haskell.org >>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From erkokl at gmail.com Thu Feb 21 18:42:20 2019 From: erkokl at gmail.com (Levent Erkok) Date: Thu, 21 Feb 2019 10:42:20 -0800 Subject: Add 'e' to Floating typeclass In-Reply-To: References: Message-ID: I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place. I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.) I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC? On Thu, Feb 21, 2019 at 10:32 AM chessai . wrote: > asymmetry in presence, not use. > > When I was first learning Haskell, the absence of e along with the > presence of pi in Floating confused me. It is not a disservice to users to > note this asymmetry in documentation and why it is not there. > > On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald > wrote: > >> i dont see it as an assymetry, theres a lot of very simple volume / area >> / probability /geometry calculations where pi comes up, >> i dont know any for e that aren't just exp. can you share some? >> >> On Wed, Feb 20, 2019 at 10:50 PM chessai . wrote: >> >>> Yeah, I think it probably shouldn't be added to the typeclass then. >>> >>> The asymmetry should probably be mentioned in the report though. >>> >>> >>> On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> either way, we're not gonna add e :) >>>> >>>> On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote: >>>> >>>>> Lennart's question "Is it really worth it?" is the most important one. >>>>> And no, probably it isn't. >>>>> >>>>> But Chessai is correct that this is a weird asymmetry in the Floating >>>>> class. My own experience is that I user neither e nor pi very much, >>>>> but neither one more than the other. >>>>> >>>>> Branch cuts of inverse trig functions are not relevant. The report >>>>> doesn't explicitly state this, but it's clear that these functions are >>>>> expected to return the standard ranges of values as in other >>>>> programming languages. You can be quite certain that acos (-1) is pi >>>>> in Haskell. And in fact, we have (at least on my computer) >>>>> >>>>> Prelude> acos (-1) == pi >>>>> True >>>>> >>>>> So there isn't any more or less reason to have e than pi as a separate >>>>> class member. >>>>> >>>>> On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson >>>>> wrote: >>>>> > >>>>> > Is it really worth it? How frequent are uses of e, except used like >>>>> exp? On the other hand, pi has more frequent standalone use cases. >>>>> > Also, e has a simple definition (exp 1), whereas pi is somewhat more >>>>> involved. >>>>> > >>>>> > The logp1 and expm1 functions where added for good numerical >>>>> reasons. The same would not be true for e. >>>>> > >>>>> > On Sat, Feb 16, 2019 at 21:14 chessai . >>>>> wrote: >>>>> >> >>>>> >> We have the 'pi' constant in the floating typeclass and some >>>>> trigonometric functions, as well as things like exp/log/expm1/log1p. >>>>> >> >>>>> >> Why not provide an 'e' constant? >>>>> >> >>>>> >> A default implementation could just be 'exp 1'. >>>>> >> _______________________________________________ >>>>> >> Libraries mailing list >>>>> >> Libraries at haskell.org >>>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> > >>>>> > _______________________________________________ >>>>> > Libraries mailing list >>>>> > Libraries at haskell.org >>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 21 19:04:13 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 21 Feb 2019 14:04:13 -0500 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: hey Levent, I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong) its definitely an interesting idea, and i certainly dont have clarity on what the implications would be On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote: > I think Carter outlined really good reasons for not including `e`; but > it's hard not to sympathize with the request. I often felt shy of adding > similar definitions in my libraries for fear that they would pollute the > name space. But their absence is rather annoying. The classic solution is > to put it in a library, internal module etc, and make a new class if > necessary; which is often overkill and misses the simplicity sought in the > first place. > > I often wonder if Haskell can have a "qualified export" feature for these > cases. Just like we can "import qualified," why not "export qualified" some > names, which means if you simply import the module the name will still be > available qualified. (You can of course always import qualified.) > > I haven't thought too much about the implications of this, but it might be > an easy solution to this problem. Would love to hear thoughts on this; is > there any language that has this feature? How costly would it be to add it > to GHC? > > On Thu, Feb 21, 2019 at 10:32 AM chessai . wrote: > >> asymmetry in presence, not use. >> >> When I was first learning Haskell, the absence of e along with the >> presence of pi in Floating confused me. It is not a disservice to users to >> note this asymmetry in documentation and why it is not there. >> >> On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> i dont see it as an assymetry, theres a lot of very simple volume / area >>> / probability /geometry calculations where pi comes up, >>> i dont know any for e that aren't just exp. can you share some? >>> >>> On Wed, Feb 20, 2019 at 10:50 PM chessai . >>> wrote: >>> >>>> Yeah, I think it probably shouldn't be added to the typeclass then. >>>> >>>> The asymmetry should probably be mentioned in the report though. >>>> >>>> >>>> On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald < >>>> carter.schonwald at gmail.com> wrote: >>>> >>>>> either way, we're not gonna add e :) >>>>> >>>>> On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote: >>>>> >>>>>> Lennart's question "Is it really worth it?" is the most important one. >>>>>> And no, probably it isn't. >>>>>> >>>>>> But Chessai is correct that this is a weird asymmetry in the Floating >>>>>> class. My own experience is that I user neither e nor pi very much, >>>>>> but neither one more than the other. >>>>>> >>>>>> Branch cuts of inverse trig functions are not relevant. The report >>>>>> doesn't explicitly state this, but it's clear that these functions are >>>>>> expected to return the standard ranges of values as in other >>>>>> programming languages. You can be quite certain that acos (-1) is pi >>>>>> in Haskell. And in fact, we have (at least on my computer) >>>>>> >>>>>> Prelude> acos (-1) == pi >>>>>> True >>>>>> >>>>>> So there isn't any more or less reason to have e than pi as a separate >>>>>> class member. >>>>>> >>>>>> On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson >>>>>> wrote: >>>>>> > >>>>>> > Is it really worth it? How frequent are uses of e, except used >>>>>> like exp? On the other hand, pi has more frequent standalone use cases. >>>>>> > Also, e has a simple definition (exp 1), whereas pi is somewhat >>>>>> more involved. >>>>>> > >>>>>> > The logp1 and expm1 functions where added for good numerical >>>>>> reasons. The same would not be true for e. >>>>>> > >>>>>> > On Sat, Feb 16, 2019 at 21:14 chessai . >>>>>> wrote: >>>>>> >> >>>>>> >> We have the 'pi' constant in the floating typeclass and some >>>>>> trigonometric functions, as well as things like exp/log/expm1/log1p. >>>>>> >> >>>>>> >> Why not provide an 'e' constant? >>>>>> >> >>>>>> >> A default implementation could just be 'exp 1'. >>>>>> >> _______________________________________________ >>>>>> >> Libraries mailing list >>>>>> >> Libraries at haskell.org >>>>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Libraries mailing list >>>>>> > Libraries at haskell.org >>>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Thu Feb 21 20:46:41 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 21 Feb 2019 12:46:41 -0800 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: > On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote: >> >> I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place. >> >> I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.) >> >> I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC? On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald wrote: > > hey Levent, > I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong) > > its definitely an interesting idea, and i certainly dont have clarity on what the implications would be If I interpret it correctly, I think what it becomes is that some symbols can never be imported unqualified. Or maybe that the default "import all unqualified" actually means "everything except these things." So it would just be an extra rule for what `import` brings into scope. Python has such a mechanism, if you have an `__all__ = [x, y, z]` then `from m import *` will just get you x, y, and z. That said, to me it seems like too many ways to do it. The user can already get a qualified import if they want it. When you write an unqualified "import *", the price you pay is losing control over your namespace, and that's a known cost. A bit more finesse on what exactly is imported won't change the basic tradeoff. From erkokl at gmail.com Thu Feb 21 21:13:37 2019 From: erkokl at gmail.com (Levent Erkok) Date: Thu, 21 Feb 2019 13:13:37 -0800 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: Evan: I liked how you put it: "A bit more finesse on what exactly is imported won't change the basic tradeoff." But still seems to me that Haskells exporting mechanism can be improved. (Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants. But that's a whole another can of worms.) I think there's design space here to be explored; in the end, it's the end-users who will have to judge what's useful and what's not. On Thu, Feb 21, 2019 at 12:46 PM Evan Laforge wrote: > > On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote: > >> > >> I think Carter outlined really good reasons for not including `e`; but > it's hard not to sympathize with the request. I often felt shy of adding > similar definitions in my libraries for fear that they would pollute the > name space. But their absence is rather annoying. The classic solution is > to put it in a library, internal module etc, and make a new class if > necessary; which is often overkill and misses the simplicity sought in the > first place. > >> > >> I often wonder if Haskell can have a "qualified export" feature for > these cases. Just like we can "import qualified," why not "export > qualified" some names, which means if you simply import the module the name > will still be available qualified. (You can of course always import > qualified.) > >> > >> I haven't thought too much about the implications of this, but it might > be an easy solution to this problem. Would love to hear thoughts on this; > is there any language that has this feature? How costly would it be to add > it to GHC? > > On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald > wrote: > > > > hey Levent, > > I can't claim to have thought about it that deeply, but naively, it > seems like a qualified export approach might not play nice with certain > approaches to seperate compilation (not that GHC does it that much), > because the names qualifications wouldn't match possible import modules, Or > at least the qualified names in scope wouldn't match what you see from the > import lines, and thus you'd have a harder time supporting good quality > error messages? (i could be totally wrong) > > > > its definitely an interesting idea, and i certainly dont have clarity on > what the implications would be > > If I interpret it correctly, I think what it becomes is that some > symbols can never be imported unqualified. Or maybe that the default > "import all unqualified" actually means "everything except these > things." So it would just be an extra rule for what `import` brings > into scope. Python has such a mechanism, if you have an `__all__ = > [x, y, z]` then `from m import *` will just get you x, y, and z. > > That said, to me it seems like too many ways to do it. The user can > already get a qualified import if they want it. When you write an > unqualified "import *", the price you pay is losing control over your > namespace, and that's a known cost. A bit more finesse on what > exactly is imported won't change the basic tradeoff. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Feb 21 23:23:40 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 Feb 2019 00:23:40 +0100 (CET) Subject: export control (Was: Add 'e' to Floating typeclass) In-Reply-To: References: Message-ID: On Thu, 21 Feb 2019, Levent Erkok wrote: > I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import > qualified," why not "export qualified" some names, which means if you simply import the module the name will > still be available qualified. (You can of course always import qualified.) > > I haven't thought too much about the implications of this, but it might be an easy solution to this problem. > Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add > it to GHC? Why not providing two modules: One that exports all identifiers and one that exports only identifiers that are likely not to clash with others. The first module would export 'e' and the second one would not. The first module would preferably be imported with qualification and the second one without. However, unrestricted unqualified imports (like for the second module) are most oftenly not what you want because you have to restrict the imported package to a specific minor version then (according to PVP). From lennart at augustsson.net Fri Feb 22 00:34:44 2019 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu, 21 Feb 2019 16:34:44 -0800 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: Qualified exports seem very unproblematic to me. And they should be easy to implement. It’s just an extra flag on each exported entity that tells compiler if the unqualified name should be entered into the symbol table or not. — Lennart On Thu, Feb 21, 2019 at 11:04 Carter Schonwald wrote: > hey Levent, > I can't claim to have thought about it that deeply, but naively, it seems > like a qualified export approach might not play nice with certain > approaches to seperate compilation (not that GHC does it that much), > because the names qualifications wouldn't match possible import modules, Or > at least the qualified names in scope wouldn't match what you see from the > import lines, and thus you'd have a harder time supporting good quality > error messages? (i could be totally wrong) > > its definitely an interesting idea, and i certainly dont have clarity on > what the implications would be > > On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote: > >> I think Carter outlined really good reasons for not including `e`; but >> it's hard not to sympathize with the request. I often felt shy of adding >> similar definitions in my libraries for fear that they would pollute the >> name space. But their absence is rather annoying. The classic solution is >> to put it in a library, internal module etc, and make a new class if >> necessary; which is often overkill and misses the simplicity sought in the >> first place. >> >> I often wonder if Haskell can have a "qualified export" feature for these >> cases. Just like we can "import qualified," why not "export qualified" some >> names, which means if you simply import the module the name will still be >> available qualified. (You can of course always import qualified.) >> >> I haven't thought too much about the implications of this, but it might >> be an easy solution to this problem. Would love to hear thoughts on this; >> is there any language that has this feature? How costly would it be to add >> it to GHC? >> >> On Thu, Feb 21, 2019 at 10:32 AM chessai . wrote: >> >>> asymmetry in presence, not use. >>> >>> When I was first learning Haskell, the absence of e along with the >>> presence of pi in Floating confused me. It is not a disservice to users to >>> note this asymmetry in documentation and why it is not there. >>> >>> On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> i dont see it as an assymetry, theres a lot of very simple volume / >>>> area / probability /geometry calculations where pi comes up, >>>> i dont know any for e that aren't just exp. can you share some? >>>> >>>> On Wed, Feb 20, 2019 at 10:50 PM chessai . >>>> wrote: >>>> >>>>> Yeah, I think it probably shouldn't be added to the typeclass then. >>>>> >>>>> The asymmetry should probably be mentioned in the report though. >>>>> >>>>> >>>>> On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald < >>>>> carter.schonwald at gmail.com> wrote: >>>>> >>>>>> either way, we're not gonna add e :) >>>>>> >>>>>> On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote: >>>>>> >>>>>>> Lennart's question "Is it really worth it?" is the most important >>>>>>> one. >>>>>>> And no, probably it isn't. >>>>>>> >>>>>>> But Chessai is correct that this is a weird asymmetry in the Floating >>>>>>> class. My own experience is that I user neither e nor pi very much, >>>>>>> but neither one more than the other. >>>>>>> >>>>>>> Branch cuts of inverse trig functions are not relevant. The report >>>>>>> doesn't explicitly state this, but it's clear that these functions >>>>>>> are >>>>>>> expected to return the standard ranges of values as in other >>>>>>> programming languages. You can be quite certain that acos (-1) is pi >>>>>>> in Haskell. And in fact, we have (at least on my computer) >>>>>>> >>>>>>> Prelude> acos (-1) == pi >>>>>>> True >>>>>>> >>>>>>> So there isn't any more or less reason to have e than pi as a >>>>>>> separate >>>>>>> class member. >>>>>>> >>>>>>> On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson >>>>>>> wrote: >>>>>>> > >>>>>>> > Is it really worth it? How frequent are uses of e, except used >>>>>>> like exp? On the other hand, pi has more frequent standalone use cases. >>>>>>> > Also, e has a simple definition (exp 1), whereas pi is somewhat >>>>>>> more involved. >>>>>>> > >>>>>>> > The logp1 and expm1 functions where added for good numerical >>>>>>> reasons. The same would not be true for e. >>>>>>> > >>>>>>> > On Sat, Feb 16, 2019 at 21:14 chessai . >>>>>>> wrote: >>>>>>> >> >>>>>>> >> We have the 'pi' constant in the floating typeclass and some >>>>>>> trigonometric functions, as well as things like exp/log/expm1/log1p. >>>>>>> >> >>>>>>> >> Why not provide an 'e' constant? >>>>>>> >> >>>>>>> >> A default implementation could just be 'exp 1'. >>>>>>> >> _______________________________________________ >>>>>>> >> Libraries mailing list >>>>>>> >> Libraries at haskell.org >>>>>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > Libraries mailing list >>>>>>> > Libraries at haskell.org >>>>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>> _______________________________________________ >>>>>>> Libraries mailing list >>>>>>> Libraries at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>> >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> >>>>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b at chreekat.net Fri Feb 22 05:28:45 2019 From: b at chreekat.net (Bryan Richter) Date: Fri, 22 Feb 2019 07:28:45 +0200 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: > Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants I believe you are in luck. Since 7.8.1, GHC supports "unidirectional pattern synonyms", as described somewhere in this section: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PatternSynonyms On Thu, 21 Feb 2019, 23.13 Levent Erkok, wrote: > Evan: I liked how you put it: "A bit more finesse on what exactly is > imported won't change the basic tradeoff." But still seems to me that > Haskells exporting mechanism can be improved. (Another pet peeve: Export > constructors but only for pattern matching purposes, i.e., elimination; not > for construction--we'd export smart constructors for the latter which would > ensure invariants. But that's a whole another can of worms.) > > I think there's design space here to be explored; in the end, it's the > end-users who will have to judge what's useful and what's not. > > On Thu, Feb 21, 2019 at 12:46 PM Evan Laforge wrote: > >> > On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote: >> >> >> >> I think Carter outlined really good reasons for not including `e`; but >> it's hard not to sympathize with the request. I often felt shy of adding >> similar definitions in my libraries for fear that they would pollute the >> name space. But their absence is rather annoying. The classic solution is >> to put it in a library, internal module etc, and make a new class if >> necessary; which is often overkill and misses the simplicity sought in the >> first place. >> >> >> >> I often wonder if Haskell can have a "qualified export" feature for >> these cases. Just like we can "import qualified," why not "export >> qualified" some names, which means if you simply import the module the name >> will still be available qualified. (You can of course always import >> qualified.) >> >> >> >> I haven't thought too much about the implications of this, but it >> might be an easy solution to this problem. Would love to hear thoughts on >> this; is there any language that has this feature? How costly would it be >> to add it to GHC? >> >> On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald >> wrote: >> > >> > hey Levent, >> > I can't claim to have thought about it that deeply, but naively, it >> seems like a qualified export approach might not play nice with certain >> approaches to seperate compilation (not that GHC does it that much), >> because the names qualifications wouldn't match possible import modules, Or >> at least the qualified names in scope wouldn't match what you see from the >> import lines, and thus you'd have a harder time supporting good quality >> error messages? (i could be totally wrong) >> > >> > its definitely an interesting idea, and i certainly dont have clarity >> on what the implications would be >> >> If I interpret it correctly, I think what it becomes is that some >> symbols can never be imported unqualified. Or maybe that the default >> "import all unqualified" actually means "everything except these >> things." So it would just be an extra rule for what `import` brings >> into scope. Python has such a mechanism, if you have an `__all__ = >> [x, y, z]` then `from m import *` will just get you x, y, and z. >> >> That said, to me it seems like too many ways to do it. The user can >> already get a qualified import if they want it. When you write an >> unqualified "import *", the price you pay is losing control over your >> namespace, and that's a known cost. A bit more finesse on what >> exactly is imported won't change the basic tradeoff. >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erkokl at gmail.com Fri Feb 22 06:05:12 2019 From: erkokl at gmail.com (Levent Erkok) Date: Thu, 21 Feb 2019 22:05:12 -0800 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: Thanks Bryan! I was completely unaware of unidirectional pattern synonyms. Very cool indeed! On Thu, Feb 21, 2019 at 9:28 PM Bryan Richter wrote: > > Another pet peeve: Export constructors but only for pattern matching > purposes, i.e., elimination; not for construction--we'd export smart > constructors for the latter which would ensure invariants > > I believe you are in luck. Since 7.8.1, GHC supports "unidirectional > pattern synonyms", as described somewhere in this section: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PatternSynonyms > > > On Thu, 21 Feb 2019, 23.13 Levent Erkok, wrote: > >> Evan: I liked how you put it: "A bit more finesse on what exactly is >> imported won't change the basic tradeoff." But still seems to me that >> Haskells exporting mechanism can be improved. (Another pet peeve: Export >> constructors but only for pattern matching purposes, i.e., elimination; not >> for construction--we'd export smart constructors for the latter which would >> ensure invariants. But that's a whole another can of worms.) >> >> I think there's design space here to be explored; in the end, it's the >> end-users who will have to judge what's useful and what's not. >> >> On Thu, Feb 21, 2019 at 12:46 PM Evan Laforge wrote: >> >>> > On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote: >>> >> >>> >> I think Carter outlined really good reasons for not including `e`; >>> but it's hard not to sympathize with the request. I often felt shy of >>> adding similar definitions in my libraries for fear that they would pollute >>> the name space. But their absence is rather annoying. The classic solution >>> is to put it in a library, internal module etc, and make a new class if >>> necessary; which is often overkill and misses the simplicity sought in the >>> first place. >>> >> >>> >> I often wonder if Haskell can have a "qualified export" feature for >>> these cases. Just like we can "import qualified," why not "export >>> qualified" some names, which means if you simply import the module the name >>> will still be available qualified. (You can of course always import >>> qualified.) >>> >> >>> >> I haven't thought too much about the implications of this, but it >>> might be an easy solution to this problem. Would love to hear thoughts on >>> this; is there any language that has this feature? How costly would it be >>> to add it to GHC? >>> >>> On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald >>> wrote: >>> > >>> > hey Levent, >>> > I can't claim to have thought about it that deeply, but naively, it >>> seems like a qualified export approach might not play nice with certain >>> approaches to seperate compilation (not that GHC does it that much), >>> because the names qualifications wouldn't match possible import modules, Or >>> at least the qualified names in scope wouldn't match what you see from the >>> import lines, and thus you'd have a harder time supporting good quality >>> error messages? (i could be totally wrong) >>> > >>> > its definitely an interesting idea, and i certainly dont have clarity >>> on what the implications would be >>> >>> If I interpret it correctly, I think what it becomes is that some >>> symbols can never be imported unqualified. Or maybe that the default >>> "import all unqualified" actually means "everything except these >>> things." So it would just be an extra rule for what `import` brings >>> into scope. Python has such a mechanism, if you have an `__all__ = >>> [x, y, z]` then `from m import *` will just get you x, y, and z. >>> >>> That said, to me it seems like too many ways to do it. The user can >>> already get a qualified import if they want it. When you write an >>> unqualified "import *", the price you pay is losing control over your >>> namespace, and that's a known cost. A bit more finesse on what >>> exactly is imported won't change the basic tradeoff. >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Feb 22 07:28:40 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 Feb 2019 08:28:40 +0100 (CET) Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: On Thu, 21 Feb 2019, Lennart Augustsson wrote: > Qualified exports seem very unproblematic to me.  And they should be > easy to implement. It’s just an extra flag on each exported entity that > tells compiler if the unqualified name should be entered into the symbol > table or not.  But it subverts the idea of disambiguation by renaming the module name at the import site. From lennart at augustsson.net Fri Feb 22 07:32:47 2019 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu, 21 Feb 2019 23:32:47 -0800 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: I don’t really see how it subverts anything. If you rename the module on import, then that’s the module name you have to use when accessing a qualified export. On Thu, Feb 21, 2019 at 23:28 Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Thu, 21 Feb 2019, Lennart Augustsson wrote: > > > Qualified exports seem very unproblematic to me. And they should be > > easy to implement. It’s just an extra flag on each exported entity that > > tells compiler if the unqualified name should be entered into the symbol > > table or not. > > But it subverts the idea of disambiguation by renaming the module name at > the import site. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Feb 22 07:36:03 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 Feb 2019 08:36:03 +0100 (CET) Subject: export constructors only for matching (Was: qualified exports) In-Reply-To: References: Message-ID: On Fri, 22 Feb 2019, Bryan Richter wrote: > > Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for > construction--we'd export smart constructors for the latter which would ensure invariants > > I believe you are in luck. Since 7.8.1, GHC supports "unidirectional pattern synonyms", as described somewhere in > this section: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PatternSynonyms In some cases you can even solve it in Haskell 98. If you have data T = Cons Char and you want to let users match Cons without exporting it, you may export a "destructor" like uncons :: T -> Char uncons (Cons a) = a or you export a continuation passing function: withT :: (Char -> a) -> T -> a withT f (Cons a) = f a and the user would no longer write g :: Int -> T -> Ordering -> Bool g x (Cons y) z = foo x y z but g :: Int -> T -> Ordering -> Bool g x = withT $ \y z -> foo x y z From lemming at henning-thielemann.de Fri Feb 22 07:38:23 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 Feb 2019 08:38:23 +0100 (CET) Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: On Thu, 21 Feb 2019, Lennart Augustsson wrote: > I don’t really see how it subverts anything.  If you rename the module > on import, then that’s the module name you have to use when accessing a > qualified export.  That is, "qualified export" is only a flag for each identifier and not a module name per identifier? From lennart at augustsson.net Fri Feb 22 07:40:47 2019 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu, 21 Feb 2019 23:40:47 -0800 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: Right. On Thu, Feb 21, 2019 at 23:38 Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Thu, 21 Feb 2019, Lennart Augustsson wrote: > > > I don’t really see how it subverts anything. If you rename the module > > on import, then that’s the module name you have to use when accessing a > > qualified export. > > That is, "qualified export" is only a flag for each identifier and not a > module name per identifier? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Feb 22 07:43:36 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 Feb 2019 08:43:36 +0100 (CET) Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: On Thu, 21 Feb 2019, Lennart Augustsson wrote: > Right. Then my suggestion of providing two modules would solve the problem, too. Right? From lennart at augustsson.net Fri Feb 22 07:50:33 2019 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu, 21 Feb 2019 23:50:33 -0800 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: Sure, but with a lot more overhead. I’m not a proponent of qualified export. I just think it would an unproblematic feature to add if we feel it’s important. On Thu, Feb 21, 2019 at 23:43 Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Thu, 21 Feb 2019, Lennart Augustsson wrote: > > > Right. > > Then my suggestion of providing two modules would solve the problem, too. > Right? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erkokl at gmail.com Fri Feb 22 07:54:48 2019 From: erkokl at gmail.com (Levent Erkok) Date: Thu, 21 Feb 2019 23:54:48 -0800 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: Two modules would indeed solve it, and I alluded to it in my original message. (I used the term "internal" module, but I see that it was confusing.) However, the whole point is that you want to avoid that. I'm not suggesting this has the biggest ROI; but I can see it would have a few use cases and would be an easy solution to an annoying problem as the original poster was arguing. (And Lennart says that'd be easy to implement, after quite a bit of bikeshedding on the precise syntax I suppose.) On Thu, Feb 21, 2019 at 11:43 PM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Thu, 21 Feb 2019, Lennart Augustsson wrote: > > > Right. > > Then my suggestion of providing two modules would solve the problem, too. > Right? > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Feb 22 07:58:46 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 Feb 2019 08:58:46 +0100 (CET) Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: On Thu, 21 Feb 2019, Lennart Augustsson wrote: > Sure, but with a lot more overhead. It would look like this: module Unqualified (...) where module Qualified ( module Unqualified, e, ) where If the list of qualified exports is long, then it might even be less to write than adding 'qualified' to many identifiers. I don't like to make the already complicated module system even more complicated for promoting a feature that has code smell anyway (namely, unrestricted unqualified imports). From adam at sandbergericsson.se Fri Feb 22 08:17:15 2019 From: adam at sandbergericsson.se (Adam Sandberg Eriksson) Date: Fri, 22 Feb 2019 08:17:15 +0000 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: There is a ghc proposal for among other things qualified exports: https://github.com/ghc-proposals/ghc-proposals/pull/205 —Adam > On 22 Feb 2019, at 07:58, Henning Thielemann wrote: > > >> On Thu, 21 Feb 2019, Lennart Augustsson wrote: >> >> Sure, but with a lot more overhead. > > It would look like this: > > > module Unqualified (...) where > > > module Qualified ( > module Unqualified, > e, > ) where > > > If the list of qualified exports is long, then it might even be less to write than adding 'qualified' to many identifiers. I don't like to make the already complicated module system even more complicated for promoting a feature that has code smell anyway (namely, unrestricted unqualified imports). > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Feb 22 08:30:23 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 22 Feb 2019 08:30:23 +0000 Subject: qualified exports , what would that mean Re: Add In-Reply-To: References: Message-ID: I believe you are in luck. Since 7.8.1, GHC supports "unidirectional pattern synonyms Yes, but a pattern synonym is a bit of heavyweight way to expose a data constructor for pattern matching but not for construction. The latter seems simpler somehow. I’ve wanted this too. And yet, and yet, it’s one more piece of complexity, at least the export list (and maybe an import list too!). And someone is sure to want to export it for construction but not pattern matching :-). For that we routinely make a term-level function for construction and don’t export the constructor at all. The pattern synonym is the natural dual of this. TL;DR: you can do both today but you have to write some boilerplate. Whether it’s worth abbreviating I’m not sure. Simon From: Libraries On Behalf Of Bryan Richter Sent: 22 February 2019 05:29 To: Levent Erkok Cc: libraries at haskell.org Subject: Re: qualified exports , what would that mean Re: Add > Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants I believe you are in luck. Since 7.8.1, GHC supports "unidirectional pattern synonyms", as described somewhere in this section: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PatternSynonyms On Thu, 21 Feb 2019, 23.13 Levent Erkok, > wrote: Evan: I liked how you put it: "A bit more finesse on what exactly is imported won't change the basic tradeoff." But still seems to me that Haskells exporting mechanism can be improved. (Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants. But that's a whole another can of worms.) I think there's design space here to be explored; in the end, it's the end-users who will have to judge what's useful and what's not. On Thu, Feb 21, 2019 at 12:46 PM Evan Laforge > wrote: > On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok > wrote: >> >> I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place. >> >> I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.) >> >> I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC? On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald > wrote: > > hey Levent, > I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong) > > its definitely an interesting idea, and i certainly dont have clarity on what the implications would be If I interpret it correctly, I think what it becomes is that some symbols can never be imported unqualified. Or maybe that the default "import all unqualified" actually means "everything except these things." So it would just be an extra rule for what `import` brings into scope. Python has such a mechanism, if you have an `__all__ = [x, y, z]` then `from m import *` will just get you x, y, and z. That said, to me it seems like too many ways to do it. The user can already get a qualified import if they want it. When you write an unqualified "import *", the price you pay is losing control over your namespace, and that's a known cost. A bit more finesse on what exactly is imported won't change the basic tradeoff. _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Thu Feb 28 18:43:34 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Thu, 28 Feb 2019 13:43:34 -0500 Subject: Incremental Regex Parsing with Fixed Strings Message-ID: Greetings, In Dan Piponi's blog post Fast Incremental Regular Expression Matching with Monoids [1], he outlines a way to take advantage of fingertrees to perform increment regex matching. In his article, the regular expression (more accurately, its equivalent DFA) is fixed, and the strings we are matching on are modified incrementally. What I'm interested in is the opposite: What if the regular expression is modified incrementally and the string we are testing is static? Thinking about this, it seems to run into problems immediately. Typically, to evaluate a regular expression, I would convert it to a NFA (and then maybe to a DFA). But there is no way to do incremental graph modification on the resulting graphs. (Or is there?). And even if there were a way, it seems unclear how one would go about exploiting its incremental nature. To provide an example, consider the following regex and sample string: Regex: Lost (dog|cat) loo for home Sample: Lost dog looking for home In the regex, I'm currently in the middle of typing "looking", so it doesn't match the sample string. But large parts of it do. So when I update the regex by typing "k", I'd like to be able to not redo this work. Maybe there's a certain subset of regex that's amenable to this kind of incremental evaluation. Maybe not. If anyone has any additional insights or can point me to any research, I would appreciate it greatly. Thanks. [1] http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Feb 28 21:47:13 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 28 Feb 2019 16:47:13 -0500 Subject: Incremental Regex Parsing with Fixed Strings In-Reply-To: References: Message-ID: I'm not too optimistic in general about editing regex machines interactively. I'd expect you to do a lot of work to save a little. But I'd expect you could win a good bit (at least in some common cases) by using something like a suffix tree of your text. That'll let you jump quickly to the end of "Lost ", for example, and may offer other interesting opportunities. On Thu, Feb 28, 2019, 1:43 PM Andrew Martin wrote: > Greetings, > > In Dan Piponi's blog post Fast Incremental Regular Expression Matching > with Monoids [1], he outlines a way to take advantage of fingertrees to > perform increment regex matching. In his article, the regular expression > (more accurately, its equivalent DFA) is fixed, and the strings we are > matching on are modified incrementally. What I'm interested in is the > opposite: What if the regular expression is modified incrementally and the > string we are testing is static? > > Thinking about this, it seems to run into problems immediately. Typically, > to evaluate a regular expression, I would convert it to a NFA (and then > maybe to a DFA). But there is no way to do incremental graph modification > on the resulting graphs. (Or is there?). And even if there were a way, it > seems unclear how one would go about exploiting its incremental nature. To > provide an example, consider the following regex and sample string: > > Regex: Lost (dog|cat) loo for home > Sample: Lost dog looking for home > > In the regex, I'm currently in the middle of typing "looking", so it > doesn't match the sample string. But large parts of it do. So when I update > the regex by typing "k", I'd like to be able to not redo this work. Maybe > there's a certain subset of regex that's amenable to this kind of > incremental evaluation. Maybe not. If anyone has any additional insights or > can point me to any research, I would appreciate it greatly. Thanks. > > [1] > http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html > > > -- > -Andrew Thaddeus Martin > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Thu Feb 28 21:54:39 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Thu, 28 Feb 2019 16:54:39 -0500 Subject: Incremental Regex Parsing with Fixed Strings In-Reply-To: References: Message-ID: Let me make sure I'm interpretting "a suffix tree of your text" correctly. You mean just stripping the common prefix "Lost" from both the regex (the texual representation of it) and from the sample text? If so, it should be possible to do both prefixes and suffixes. But it's still not the win I'm hoping for. On Thu, Feb 28, 2019 at 4:47 PM David Feuer wrote: > I'm not too optimistic in general about editing regex machines > interactively. I'd expect you to do a lot of work to save a little. But I'd > expect you could win a good bit (at least in some common cases) by using > something like a suffix tree of your text. That'll let you jump quickly to > the end of "Lost ", for example, and may offer other interesting > opportunities. > > On Thu, Feb 28, 2019, 1:43 PM Andrew Martin > wrote: > >> Greetings, >> >> In Dan Piponi's blog post Fast Incremental Regular Expression Matching >> with Monoids [1], he outlines a way to take advantage of fingertrees to >> perform increment regex matching. In his article, the regular expression >> (more accurately, its equivalent DFA) is fixed, and the strings we are >> matching on are modified incrementally. What I'm interested in is the >> opposite: What if the regular expression is modified incrementally and the >> string we are testing is static? >> >> Thinking about this, it seems to run into problems immediately. >> Typically, to evaluate a regular expression, I would convert it to a NFA >> (and then maybe to a DFA). But there is no way to do incremental graph >> modification on the resulting graphs. (Or is there?). And even if there >> were a way, it seems unclear how one would go about exploiting its >> incremental nature. To provide an example, consider the following regex and >> sample string: >> >> Regex: Lost (dog|cat) loo for home >> Sample: Lost dog looking for home >> >> In the regex, I'm currently in the middle of typing "looking", so it >> doesn't match the sample string. But large parts of it do. So when I update >> the regex by typing "k", I'd like to be able to not redo this work. Maybe >> there's a certain subset of regex that's amenable to this kind of >> incremental evaluation. Maybe not. If anyone has any additional insights or >> can point me to any research, I would appreciate it greatly. Thanks. >> >> [1] >> http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html >> >> >> -- >> -Andrew Thaddeus Martin >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Feb 28 23:09:47 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 1 Mar 2019 00:09:47 +0100 (CET) Subject: Incremental Regex Parsing with Fixed Strings In-Reply-To: References: Message-ID: On Thu, 28 Feb 2019, Andrew Martin wrote: > Let me make sure I'm interpretting "a suffix tree of your text" > correctly. https://en.wikipedia.org/wiki/Suffix_tree