<div dir="ltr">The same is true of the Prelude. You might want to look at what's happened with -XStrict and even -XStrictData. Both end up meaning you replace or rewrite a bunch of library functions, because lots of things rely on laziness either for memory usage or to avoid bottoms.<div><br></div><div>In short, if you are still talking about Haskell, default-strict isn't an option. A strict Haskell-*like* language is an option, but it won't be Haskell; its idioms will be different and library compatibility will be dubious at best.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 9, 2019 at 5:22 PM Theodore Lief Gannon <<a href="mailto:tanuki@gmail.com">tanuki@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">james.faure@epitech.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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">~'
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"><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">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="gmail-m_2135817920545779671m_252524935945355959appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_2135817920545779671m_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" rel="noreferrer" target="_blank">haskell-cafe-bounces@haskell.org</a>> on behalf of Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">haskell-cafe@haskell.org</a><br>
<b>Subject:</b> Re: [Haskell-cafe] LFVM-STG Compilation</font>
<div> </div>
</div>
<div class="gmail-m_2135817920545779671m_252524935945355959BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="gmail-m_2135817920545779671m_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" rel="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.</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>
_______________________________________________<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" 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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>