<div dir="auto">Do not underestimate the repercussions of strict-by-default. I have quite a bit of production code which would bottom out (or at best *massively* over-allocate) without pervasive laziness.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 9, 2019, 11:11 AM james faure <<a href="mailto:james.faure@epitech.eu">james.faure@epitech.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Haskell has th<span style="font-family:calibri,arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgba(0,0,0,0)">e '</span><span style="color:rgb(0,0,0);font-family:calibri,arial,helvetica,sans-serif;font-size:12pt;text-align:left;background-color:rgba(0,0,0,0);display:inline!important">~'
and '!' that can be used to specify strictness of constructor parameters, If nothing is given lfvm will assume '!'. It's worth noting that it's not always easy to tell when laziness can pay off, the classic example of 'take 3 . sort' being something that benefits
from lazy evaluation. Perhaps cases like these can be resolved by marking 'take' as preferring lazy lists.</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:calibri,arial,helvetica,sans-serif;font-size:12pt;text-align:left;background-color:rgba(0,0,0,0);display:inline!important"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:calibri,arial,helvetica,sans-serif;font-size:12pt;text-align:left;background-color:rgba(0,0,0,0);display:inline!important">So yes, This strict by default approach probably means some library code
will need to be updated to avoid unnecessarily forcing huge lists to be evaluated, although I don't think the effects will be that massive, for lists I can't think of many functions besides 'take' and 'head' that don't need the whole list. Besides the vast
majority of the time I would assume one uses all the data one creates. In the above example, you're relying on sort to operate in a certain way - if it uses a bubble sort for example, then that's unfortunate.</span></div>
<div id="m_252524935945355959appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_252524935945355959divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Haskell-Cafe <<a href="mailto:haskell-cafe-bounces@haskell.org" target="_blank" rel="noreferrer">haskell-cafe-bounces@haskell.org</a>> on behalf of Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank" rel="noreferrer">ietf-dane@dukhovni.org</a>><br>
<b>Sent:</b> Thursday, May 9, 2019 7:40 PM<br>
<b>To:</b> <a href="mailto:haskell-cafe@haskell.org" target="_blank" rel="noreferrer">haskell-cafe@haskell.org</a><br>
<b>Subject:</b> Re: [Haskell-cafe] LFVM-STG Compilation</font>
<div> </div>
</div>
<div class="m_252524935945355959BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="m_252524935945355959PlainText">On Thu, May 09, 2019 at 12:54:01PM +0000, james faure wrote:<br>
<br>
> Pi calculus [1] (process calculus) In the STG<br>
> <br>
> * Multithreading occurs for arguments of functions with >1 arity<br>
><br>
> * Perfect garbage collection is quite probably possible [2], where<br>
> allocation creates a new pi name, and its uses are modeled by pi calculus<br>
> communication<br>
><br>
> * Perfect Lazy evaluation (in the sense that the wrapper and associated<br>
> wrapped type overhead is coerced away after the first evaluation) is<br>
> possible in the pi calculus and closely linked the gc model. I intend<br>
> to make strict evaluation the default, If you want lazy (for MonadFix<br>
> or infinite lists or whatever), you must request it.<br>
<br>
The ideas sound very interesting, but could you elaborate on the<br>
"strict by default" aspect? Who's the "you" who'd have to request<br>
lazy evaluation? Is this something internal to the compiler with<br>
strictness analysis generating the "requests" internally, or would<br>
all existing application and library code that expects lazy evaluation<br>
need to be updated with explicit laziness annotations?<br>
<br>
-- <br>
Viktor.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank" rel="noreferrer">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</div>
</span></font></div>
</div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>