<html><head></head><body><div><div><div style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden; visibility: hidden;"><img src="https://r.superhuman.com/yT2tNDIjnClyPfTjDuyFLLuO2e-i9jH0swCmmwSAdkO6FRMne-LkPzZnAoB9I-Pg6R6Ab8cpteBW891lyd5A1xtEpTYcTWZiVVJh2BUkq2lc9CK0er5LnpdNigkrRX-TBH31L6sg1_3EBERBLDdXaLrA8I6Ms4M3Ljz_wDLlaohtXQ-4Q8ArG5o.gif" alt=" " width="1" height="0" style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden; visibility: hidden;"/><!-- --></div><div><div><div>Nice, thanks Chessai</div></div><br/><div class="gmail_signature"></div></div><br/><div><div class="gmail_quote">On Mon, Oct 26, 2020 at 9:16 PM, chessai <span dir="ltr"><<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@gmail.com</a>></span> wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote sh-color-black sh-color" style="null" id="null"><div dir="auto" class="sh-color-black sh-color"><div class="sh-color-black sh-color">Emily, I already put up an MR: <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4355" target="_blank" rel="noopener noreferrer">https:/<wbr/>/<wbr/>gitlab.<wbr/>haskell.<wbr/>org/<wbr/>ghc/<wbr/>ghc/<wbr/>-/<wbr/>merge_requests/<wbr/>4355</a><br/><br/><div class="gmail_quote sh-color-black sh-color"><div class="gmail_attr sh-color-black sh-color" dir="ltr">On Mon, Oct 26, 2020, 20:14 Emily Pillmore <<a href="mailto:emilypi@cohomolo.gy" target="_blank" rel="noopener noreferrer">emilypi@<wbr/>cohomolo.<wbr/>gy</a>> wrote:<br/></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class="gmail_quote sh-color-black sh-color"><div class="sh-color-black sh-color"><div class="sh-color-black sh-color"><div class="sh-color-black sh-color"><div class="sh-color-black sh-color"><div class="sh-color-black sh-color"><div class="sh-color-black sh-color">Just to keep this going so it doesn't die out. I'm going to request that Hécate submit a PR to address the composite criticism here, implementing `sum|product` in terms of `foldr`, and providing a strict equivalent `sum'|product'` variant for each as discussed. We'll move the discussion to that PR. <br/></div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color">Cheers,<br/></div><div class="sh-color-black sh-color">Emily <br/></div></div><br/><div class="sh-color-black sh-color"></div></div><br/><div class="sh-color-black sh-color"><div class="gmail_quote sh-color-black sh-color">On Thu, Oct 22, 2020 at 7:05 AM, Fumiaki Kinoshita <span dir="ltr" class="sh-color-black sh-color"><<a rel="noopener noreferrer" href="mailto:fumiexcel@gmail.com" target="_blank">fumiexcel@<wbr/>gmail.<wbr/>com</a>></span> wrote:<br/><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class="gmail_quote sh-color-black sh-color"><div class="gmail_extra sh-color-black sh-color"><div id="m_6083086840997236243null" class="gmail_quote sh-color-black sh-color"><div dir="ltr" class="sh-color-black sh-color"><div dir="ltr" class="sh-color-black sh-color"><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For a forced example, consider a wrapping of Double with a test<br/>
for infinity on the left argument<br/><br/>
…<br/>
a + b | isInfinite a = a<br/>
…<br/></blockquote><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color">This makes sense only if sum is foldr (+) 0, while the implementation of sum for lists is foldl (+) 0. But hey, we are comparing a hypothetical type with hundreds of real world uses. <br/></div><div class="sh-color-black sh-color"><br/></div><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="sh-color-black sh-color">Haskell should remain a lazy language</div></blockquote><div class="sh-color-black sh-color">I'm not sure if I agree. We've been bitten by laziness too much, hence the introduction of BangPatterns, StrictData, deepseq, etc. IMO Haskell ecosystem should be more strict.</div><div class="sh-color-black sh-color"><br/></div><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="sh-color-black sh-color">I'm uncomfortable with making foldMap/sum strict.</div></blockquote><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color">No one is suggesting to change foldMap; what OP wants to change is sum and product, and foldMap _happens to be_ the current default implementation.</div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color"><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> we dont knowing the context. the best way to avoid the cost of computation is not to compute it; what alternatives are there<div class="sh-color-black sh-color">i this s[ecific problem.</div></blockquote><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color">The context is pretty clear; the status quo (sum = foldl (+) 0) is flat-out wrong. I'd say more than 80% of the uses of sum is supposed to look at all the elements. And even if (+) is short-circuiting in the way Jon suggested, lazy foldl does not take any advantage of it.</div><div class="sh-color-black sh-color"><br/></div></div><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="sh-color-black sh-color"><div class="sh-color-black sh-color">if one was to make foldMap/sum strict why not also other
functions, e.g. scanAccum, where does one stop on the grounds of
possibly saving costs in so as yet</div><div class="sh-color-black sh-color">unknown application</div></div></blockquote><div class="sh-color-black sh-color">I'm not sure which function you are talking about (there's no function called scanAccum in base nor containers). If you mean scanl, lazy accumulator still makes sense because the resulting list can be consumed incrementally. foldl is not.<br/></div><div class="sh-color-black sh-color"><br/></div><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="sh-color-black sh-color"><div class="sh-color-black sh-color">Instead of thinking/programming in a pure lazy language, you are then in the position of thinking lazily apart from some set of</div><div class="sh-color-black sh-color">to be determined exceptional cases. the simplicity and uniformity of the model is gone.</div></div></blockquote><div class="sh-color-black sh-color">Again, there's little to be gained from lazy foldl. It's avoided in general and I'd say it's not "uniform" to use the function.</div><div class="sh-color-black sh-color"><br/></div><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="sh-color-black sh-color"><div class="sh-color-black sh-color">4. As per item 3 but from a pedagogical point of view. I taught UG
FP for years. Complicating the model is not going to help students,</div><div class="sh-color-black sh-color">to say nothing of the caveats that would have to be added to existing teaching materials.</div></div></blockquote>
</div><div class="sh-color-black sh-color">Also from a pedagogical point of view, a number of beginners fall into a trap of lazy foldl. Caveats should be added to the current one if at all, but this danger zone can be removed with one byte change.</div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color">I'm seriously worried that the use of foldl in the standard library might make beginners think that it's fine to use foldl.</div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color">As far as I remember, the same change has been suggested a while ago but didn't make it. I hope we don't get discouraged this time and go ahead with the change.<br/></div><div class="sh-color-black sh-color"><br/></div><div class="gmail_quote sh-color-black sh-color"><div dir="ltr" class="gmail_attr sh-color-black sh-color">2020年10月22日(木) 19:19 David Duke <<a rel="noopener noreferrer" href="mailto:duke.j.david@gmail.com" target="_blank">duke.<wbr/>j.<wbr/>david@<wbr/>gmail.<wbr/>com</a>>:<br/></div><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="sh-color-black sh-color">Concur with Jon's point. <div class="sh-color-black sh-color">I'm uncomfortable with making foldMap/sum strict.</div><div class="sh-color-black sh-color">Haskell was intended to explore a region of the programming design space that had not been well covered. and it remains</div><div class="sh-color-black sh-color">if not unique then at least exemplary in that respect. When I write in Haskell I do so with the knowledge that I am working with</div><div class="sh-color-black sh-color">lazy evaluation with the benefits and risk that comes with that. If I'm desperate to have finer operational control, I either</div><div class="sh-color-black sh-color">swallow that pill and adapt my use of Haskell accordingly, or pick up a different tool from the programming language toolbox.</div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color">Now the OP pointed to an issue with one specific use of sum. However, that seems like weak grounds to make library changes:</div><div class="sh-color-black sh-color">1. we dont knowing the context. the best way to avoid the cost of computation is not to compute it; what alternatives are there</div><div class="sh-color-black sh-color">i this s[ecific problem.</div><div class="sh-color-black sh-color">2. if one was to make foldMap/sum strict why not also other functions, e.g. scanAccum, where does one stop on the grounds of possibly saving costs in so as yet</div><div class="sh-color-black sh-color">unknown application</div><div class="sh-color-black sh-color">3. Instead of thinking/programming in a pure lazy language, you are then in the position of thinking lazily apart from some set of</div><div class="sh-color-black sh-color">to be determined exceptional cases. the simplicity and uniformity of the model is gone.</div><div class="sh-color-black sh-color">4. As per item 3 but from a pedagogical point of view. I taught UG FP for years. Complicating the model is not going to help students,</div><div class="sh-color-black sh-color">to say nothing of the caveats that would have to be added to existing teaching materials.</div><div class="sh-color-black sh-color">So whilst the post was clearly intended to trigger discussion, in terms on conveying sentiment a strict foldMap would be a big '-'</div><div class="sh-color-black sh-color">for me personally. Whilst there are performance challenges in working with Haskell. The primary role of the programming notation</div><div class="sh-color-black sh-color">is allowing one to think about the problem and obtain a clear, correct solution. Performance tuning comes later if at all, and</div><div class="sh-color-black sh-color">her are known techniques for doing so with Haskell/ghc.</div><div class="sh-color-black sh-color">5. OTOH I see little harm in adding a library that provides a strict foldMap for those</div><div class="sh-color-black sh-color">who want to use it after deliberate thought.</div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color">YMMMocV</div><div class="sh-color-black sh-color">David</div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color"><br/></div><div class="sh-color-black sh-color"><br/></div></div><br/><div class="gmail_quote sh-color-black sh-color"><div dir="ltr" class="gmail_attr sh-color-black sh-color">On Thu, Oct 22, 2020 at 10:36 AM Jon Fairbairn <<a rel="noopener noreferrer" href="mailto:jon.fairbairn@cl.cam.ac.uk" target="_blank">jon.<wbr/>fairbairn@<wbr/>cl.<wbr/>cam.<wbr/>ac.<wbr/>uk</a>> wrote:<br/></div><blockquote class="gmail_quote sh-color-black sh-color" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sylvain Henry <<a rel="noopener noreferrer" href="mailto:sylvain@haskus.fr" target="_blank">sylvain@<wbr/>haskus.<wbr/>fr</a>> writes:<br/>
<br/>
> Do we have an actual example of the use of a lazy sum in the<br/>
> wild?<br/>
<br/>
That’s not a very good argument, though I’ve seen it used quite<br/>
a lot. The problem is that just because no-one can currently<br/>
think of a “real” example it doesn’t mean that there are no<br/>
cases where laziness is required.<br/>
<br/>
For a forced example, consider a wrapping of Double with a test<br/>
for infinity on the left argument<br/>
<br/>
…<br/>
a + b | isInfinite a = a<br/>
…<br/>
<br/>
which doesn’t evaluate it’s second argument if the first is<br/>
infinite.<br/>
<br/>
> If the most common case is the strict one, making `sum`<br/>
> strict would be a better default.<br/>
<br/>
Haskell should remain a lazy language, so the defaults should be<br/>
lazy unless they can be proved strict anyway.<br/>
<br/>
> If need be we could also provide `lazySum` or something, but<br/>
> is there really a need?<br/>
<br/>
Who can truly say? I’d support sum' as the strict version as<br/>
that is consistent with other usages.<br/>
<br/>
— Jón<br/>
<br/>
><br/>
> Sylvain<br/>
><br/>
><br/>
> On 18/10/2020 22:16, Oleg Grenrus wrote:<br/>
>><br/>
>> Sorry I wasn't clear myself. Option C is "add sum'"<br/>
>><br/>
>> For lists:<br/>
>><br/>
>> sum = foldr (+) 0<br/>
>> sum' = foldl' (+) 0<br/>
>><br/>
>> For Foldable<br/>
>><br/>
>> sum = getSum #. foldMap Sum<br/>
>> sum' = getSum #. foldMap' Sum<br/>
>><br/>
>> - Oleg<br/>
>><br/>
>> On 18.10.2020 23.11, Hécate wrote:<br/>
>>><br/>
>>> Indeed, and I initially went to suggest a<br/>
>>> foldMap'`-based implementation to keep with the current<br/>
>>> implementation of many Foldable functions that are based<br/>
>>> on `foldMap` rather than a raw `fold`.<br/>
>>><br/>
>>> On 18/10/2020 22:04, Oleg Grenrus wrote:<br/>
>>>> For the sake of bigger audience I didn't bother<br/>
>>>> mentioning #. which is a coercion helper. It's<br/>
>>>> essentially better (.) when the first argument is<br/>
>>>> newtype constructor (i.e. coerce).<br/>
>>>><br/>
>>>> So with Option A (strict):<br/>
>>>><br/>
>>>> sum = getSum #. foldMap' Sum<br/>
>>>><br/>
>>>> Or Option B (lazy)<br/>
>>>><br/>
>>>> sum = getSum #. foldMap Sum<br/>
>>>><br/>
>>>> ---<br/>
>>>><br/>
>>>> There is also third option, Option C:<br/>
>>>><br/>
>>>> sum = foldr (+) 0<br/>
>>>> sum' = foldl' (+) 0<br/>
>>>><br/>
>>>> I don't think this is worthwhile, but it is an option.<br/>
>>>> (to rehash, I don't consider maintaining status quo to<br/>
>>>> be an option at all).<br/>
>>>><br/>
>>>> - Oleg<br/>
>>>> On 18.10.2020 22.54, Vanessa McHale wrote:<br/>
>>>>><br/>
>>>>> It's<br/>
>>>>><br/>
>>>>> sum = getSum #. foldMap Sum<br/>
>>>>><br/>
>>>>> in base.<br/>
>>>>><br/>
>>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote:<br/>
>>>>>><br/>
>>>>>> The problem is the current definition of sum for lists<br/>
>>>>>> which uses foldl, i.e non-strict left fold<br/>
>>>>>><br/>
>>>>>> sum = foldl (+) 0<br/>
>>>>>><br/>
>>>>>> It's utterly broken. Either we should change it to<br/>
>>>>>> foldl' to work on some types where addition is strict,<br/>
>>>>>> Option A:<br/>
>>>>>><br/>
>>>>>> sum = foldl' (+) 0<br/>
>>>>>><br/>
>>>>>> or alternatively (to make people using lazy<br/>
>>>>>> accumulator types), Option B:<br/>
>>>>>><br/>
>>>>>> sum = foldr (+) 0<br/>
>>>>>><br/>
>>>>>> The current state is no good for anyone or anything.<br/>
>>>>>><br/>
>>>>>> ---<br/>
>>>>>><br/>
>>>>>> Related issue which Hecate didn't clearly mention, is<br/>
>>>>>> that Foldable class default implementation has<br/>
>>>>>><br/>
>>>>>> class Foldable f where<br/>
>>>>>> ...<br/>
>>>>>> sum = getSum . foldMap Sum -- this is "good" lazy definition<br/>
>>>>>><br/>
>>>>>> If we select option A, then I argue that for<br/>
>>>>>> consistency the default `Foldable.sum` should be<br/>
>>>>>><br/>
>>>>>> sum = getSum . foldMap' Sum -- strict foldMap'<br/>
>>>>>><br/>
>>>>>> If we select option B, Foldable definition doesn't need to be changed.<br/>
>>>>>><br/>
>>>>>> ---<br/>
>>>>>><br/>
>>>>>> I repeat, using non-strict left fold, foldl, for sum<br/>
>>>>>> and product is not good for anything.<br/>
>>>>>> Either foldr or foldl'.<br/>
>>>>>><br/>
>>>>>> I have no strong preference. Current state is unacceptable.<br/>
>>>>>><br/>
>>>>>> - Oleg<br/>
>>>>>><br/>
>>>>>> On 18.10.2020 22.24, Henning Thielemann wrote:<br/>
>>>>>>><br/>
>>>>>>> On Sun, 18 Oct 2020, Hécate wrote:<br/>
>>>>>>><br/>
>>>>>>>> In conclusion, leaving things to the optimiser that<br/>
>>>>>>>> could be trivially made fast every time seems<br/>
>>>>>>>> needlessly risky.<br/>
>>>>>>><br/>
>>>>>>> `seq` is still a hack. A strict 'sum' and 'product'<br/>
>>>>>>> would still fail on a lazy accumulator type, say a<br/>
>>>>>>> lazy pair type. If at all, sum and product should be<br/>
>>>>>>> deepseq-strict. So currently, letting the optimiser<br/>
>>>>>>> make a lazy sum strict is still the smaller hack.<br/>
>>>>>>><br/>
>>>>>>> _______________________________________________<br/>
>>>>>>> Libraries mailing list<br/>
>>>>>>> <a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
>>>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
>>>>>><br/>
>>>>>> _______________________________________________<br/>
>>>>>> Libraries mailing list<br/>
>>>>>> <a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
>>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
>>>>><br/>
>>>>> _______________________________________________<br/>
>>>>> Libraries mailing list<br/>
>>>>> <a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
>>>><br/>
>>>> _______________________________________________<br/>
>>>> Libraries mailing list<br/>
>>>> <a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
>>> -- <br/>
>>> Hécate <img src="https://emojis.superhuman.com/2728.png" alt="✨" title="✨" style="height: 15px !important; width: 15px !important; vertical-align: text-bottom !important;" height="15" width="15"/><br/>
>>> IRC: Uniaika<br/>
>>> WWW:<a href="https://glitchbra.in" rel="noopener noreferrer" target="_blank">https:/<wbr/>/<wbr/>glitchbra.<wbr/>in</a><br/>
>>> RUN: BSD<br/>
>>><br/>
>>> _______________________________________________<br/>
>>> Libraries mailing list<br/>
>>> <a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
>><br/>
>> _______________________________________________<br/>
>> Libraries mailing list<br/>
>> <a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
> _______________________________________________<br/>
> Libraries mailing list<br/>
> <a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
<br/>
-- <br/>
Jón Fairbairn <a rel="noopener noreferrer" href="mailto:Jon.Fairbairn@cl.cam.ac.uk" target="_blank">Jon.<wbr/>Fairbairn@<wbr/>cl.<wbr/>cam.<wbr/>ac.<wbr/>uk</a><br/>
<a href="http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>www.<wbr/>chaos.<wbr/>org.<wbr/>uk/<wbr/>~jf/<wbr/>Stuff-I-dont-want.<wbr/>html</a> (updated 2014-04-05)<br/>
<br/>
_______________________________________________<br/>
Libraries mailing list<br/>
<a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
</blockquote></div><br clear="all"/><div class="sh-color-black sh-color"><br/></div>-- <br/><div dir="ltr" class="sh-color-black sh-color"><div dir="ltr" class="sh-color-black sh-color"><div class="sh-color-black sh-color"><div dir="ltr" class="sh-color-black sh-color"><div class="sh-color-black sh-color"><div dir="ltr" class="sh-color-black sh-color"><div class="sh-color-black sh-color"><div dir="ltr" class="sh-color-black sh-color"><div class="sh-color-black sh-color">David Duke</div><div class="sh-color-black sh-color">Emeritus Professor of Computer Science</div><div class="sh-color-black sh-color">School of Computing University of Leeds UK</div><div class="sh-color-black sh-color"><a rel="noopener noreferrer" href="mailto:E%3Aduke.j.david@gmail.com" target="_blank">E:duke.<wbr/>j.<wbr/>david@<wbr/>gmail.<wbr/>com</a></div><div class="sh-color-black sh-color">W:<a rel="noopener noreferrer" href="https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke" target="_blank">https:/<wbr/>/<wbr/>engineering.<wbr/>leeds.<wbr/>ac.<wbr/>uk/<wbr/>staff/<wbr/>334/<wbr/>Professor_David_Duke</a></div></div></div></div></div></div></div></div></div>
_______________________________________________<br/>
Libraries mailing list<br/>
<a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a><br/>
</blockquote></div></div>
<p class="sh-color-black sh-color">_______________________________________________
<br/>
Libraries mailing list
<br/>
<a href="mailto:Libraries@haskell.org" rel="noopener noreferrer" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a>
<br/>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noopener noreferrer" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a></p></div></div></blockquote></div></div><br/></div></div></div>_______________________________________________<br/>
Libraries mailing list<br/>
<a rel="noopener noreferrer" href="mailto:Libraries@haskell.org" target="_blank">Libraries@<wbr/>haskell.<wbr/>org</a><br/>
<a rel="noopener noreferrer" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http:/<wbr/>/<wbr/>mail.<wbr/>haskell.<wbr/>org/<wbr/>cgi-bin/<wbr/>mailman/<wbr/>listinfo/<wbr/>libraries</a></blockquote></div></div></div></div></div></blockquote></div></div><br/></div></div></body></html>