[Haskell-cafe] LFVM-STG Compilation

[james faure]

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 <haskell-cafe-bounces at haskell.org> on behalf of Viktor Dukhovni <ietf-dane at dukhovni.org>
Sent: Thursday, May 9, 2019 7:40 PM
To: haskell-cafe at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190509/3f90129d/attachment.html>