Haskell has the '~' 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. 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. ________________________________ From: Haskell-Cafe on behalf of Viktor Dukhovni Sent: Thursday, May 9, 2019 7:40 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] LFVM-STG Compilation On Thu, May 09, 2019 at 12:54:01PM +0000, james faure wrote:

Pi calculus [1] (process calculus) In the STG

* Multithreading occurs for arguments of functions with >1 arity

* Perfect garbage collection is quite probably possible [2], where allocation creates a new pi name, and its uses are modeled by pi calculus communication

* Perfect Lazy evaluation (in the sense that the wrapper and associated wrapped type overhead is coerced away after the first evaluation) is possible in the pi calculus and closely linked the gc model. I intend to make strict evaluation the default, If you want lazy (for MonadFix or infinite lists or whatever), you must request it.

The ideas sound very interesting, but could you elaborate on the "strict by default" aspect? Who's the "you" who'd have to request lazy evaluation? Is this something internal to the compiler with strictness analysis generating the "requests" internally, or would all existing application and library code that expects lazy evaluation need to be updated with explicit laziness annotations? -- Viktor. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

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. 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. On Thu, May 9, 2019 at 5:22 PM Theodore Lief Gannon wrote:

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.

On Thu, May 9, 2019, 11:11 AM james faure wrote:

...

Haskell has the '~' 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.

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. ------------------------------ *From:* Haskell-Cafe on behalf of Viktor Dukhovni *Sent:* Thursday, May 9, 2019 7:40 PM *To:* haskell-cafe@haskell.org *Subject:* Re: [Haskell-cafe] LFVM-STG Compilation

On Thu, May 09, 2019 at 12:54:01PM +0000, james faure wrote:

...

Pi calculus [1] (process calculus) In the STG

* Multithreading occurs for arguments of functions with >1 arity

* Perfect garbage collection is quite probably possible [2], where allocation creates a new pi name, and its uses are modeled by pi calculus communication

* Perfect Lazy evaluation (in the sense that the wrapper and associated wrapped type overhead is coerced away after the first evaluation) is possible in the pi calculus and closely linked the gc model. I intend to make strict evaluation the default, If you want lazy (for MonadFix or infinite lists or whatever), you must request it.

The ideas sound very interesting, but could you elaborate on the "strict by default" aspect? Who's the "you" who'd have to request lazy evaluation? Is this something internal to the compiler with strictness analysis generating the "requests" internally, or would all existing application and library code that expects lazy evaluation need to be updated with explicit laziness annotations?

-- Viktor. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

Am Fr., 10. Mai 2019 um 00:05 Uhr schrieb Brandon Allbery < allbery.b@gmail.com>:

[...] 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.

+1. I think one (quite old) point has been missed so far in this discussion: "Strict evaluation is fundamentally flawed for function reuse.", see http://augustss.blogspot.com/2011/05/.