suggestion: use lazy pattern matching for Monoid instances of tuples

[Edward Kmett]

If you are looking into a tackling lazy foldr, I'd recommend also including
or considering using foldMap as a basis. It can make an asymptotic
difference for some folds. I sent Gabriel a version in that style. I'll dig
up a copy and send it your way as well.

-Edward


On Mon, Aug 19, 2013 at 3:29 AM, Petr Pudlák <petr.mvd at gmail.com> wrote:

>  Thank you all for the responses.
>
> Edward's objection is very serious, I didn't think of it.
> Because of it I retract the proposal, this would indeed create big
> problems. (I just wish someone invents an oracle strictness analyzer...)
>
> Instead, as suggested, I'll make a package with `newtype` wrappers for
> tuples that will provide the extra-lazy monoid semantics. Any ideas for
> what other type classes except `Monoid` (and `Semigroup`) could be
> included? Or perhaps even other data types except tuples?
>
> Dne 08/18/2013 11:21 PM, Gabriel Gonzalez napsal(a):
>
> I'm guessing this proposal is related to this Stack Overflow answer you
> gave:
>
> http://stackoverflow.com/a/18289075/1026598
>
> Note that your solution is very similar to the solution in the `foldl`
> package I just released (also based off of the same blog post you got your
> solution from).  The key differences are that:
>
> * The `foldl` solution is for left folds and uses a strict tuple
> internally to prevent space leaks
> * Your solution is for right folds and uses an extra-lazy tuple internally
> to promote laziness
>
> This suggests to me that it would be better to keep this extra-lazy tuple
> as an internal implementation detail of a right-fold package that would be
> the lazy analogy of `foldl`, rather than modifying the standard Haskell
> tuple.
>
> Yes, this is how I encountered the problem. If I have time I'll make a
> mirror package `foldr` based on extra-lazy tuples. (Or perhaps we could
> merge the ideas into a single package.)
>
>   Best regards,
>   Petr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130819/72a21809/attachment.htm>