Note the join point. But `findIndex4` and `findIndex` do not. Maybe
#14387: listToMaybe doesn't participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * owner: (none) => duog Comment: Replying to [comment:2 simonpj]: Thank you very much for your explanations. that was a typo. Yes it was, sorry about that.
Having a join point means constant stack space, not having a join
point means linear stack space.
This definitely isn't true. Here's `findIndex` (the one that does not
In the `False` branch inside `go`, there's a tail-call to `go` (no stack growth). In the `True` branch, `go` returns a cons-cell, and stops. Then
get a join point): the `case go x o# of ...` scrutinises that cons cell and returns a `Just`. All done. No stack growth in either case. Ah I see, I didn't understand that tail-calls to let bindings worked like that. I will examine the Notes on join points to try to understand the difference between calling a join point and tail-calling a let binding; I guess that the tail-call is a bit more expensive because the let binding has additional code for the case when it is not tail-called.
it seems that changing the definition of listToMaybe to use `foldr`
would be a win
Yes I agree. It's a bit like making `map` use `foldr` rather than being
written directly. But you'd need an INLINE pragma on it.
I can't see a downside. If it doesn't fuse you get the original
`listToMaybe` back instead. If someone makes that change (in `base`) do add a Note to explain. I will prepare a patch. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14387#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler