[Haskell-cafe] LFVM-STG Compilation

Theodore Lief Gannon tanuki at gmail.com
Thu May 9 21:22:09 UTC 2019


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 <james.faure at epitech.eu> 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 <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.
> _______________________________________________
> 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/2b7b853a/attachment.html>


More information about the Haskell-Cafe mailing list