- Libraries - Haskell.org

add map back to Functor
by Carter Schonwald 11 Feb '19

11 Feb '19

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

7 11

Add Ord Laws to next Haskell Report
by chessai . 11 Feb '19

11 Feb '19

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.

17 45

Proposal: transformers/mtl Applicative Relaxation
by chessai . 10 Feb '19

10 Feb '19

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

1 0

Re: add map back to Functor
by Carter Schonwald 09 Feb '19

09 Feb '19

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 <eacameron(a)gmail.com> wrote: > In that case I must have misunderstood what the automatic migration would > be. > > On Sat, Feb 9, 2019, 2:56 PM Carter Schonwald <carter.schonwald(a)gmail.com > 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 <eacameron(a)gmail.com> >> 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 <spam(a)scientician.net >>> 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(a)haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>

1 0

Re: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report
by Bev 08 Feb '19

08 Feb '19

Please delete me. Thank you On Friday, February 8, 2019 Vanessa McHale <vanessa.mchale(a)iohk.io> 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 <david.feuer(a)gmail.com> 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(a)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(a)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(a)inconsistent.nl> wrote: > On 8 Feb 2019, at 10:57, Sven Panne <svenpanne(a)gmail.com> wrote: > > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten <merijn(a)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(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

add concatMapM to base in control.monad
by Carter Schonwald 08 Feb '19

08 Feb '19

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)

4 5

Calling the callback when event registration fails
by Andrew Martin 07 Feb '19

07 Feb '19

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

2 3

Contacting bytestring-trie maintainers
by Tim McGilchrist 06 Feb '19

06 Feb '19

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

4 7

Peeking into StgInfoTable in cmm
by Andrew Martin 06 Feb '19

06 Feb '19

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

3 5

Order of constructors in Data.Map.Internal
by chessai . 03 Feb '19

03 Feb '19

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.

2 3