[Haskell-cafe] LFVM-STG Compilation

[Brandon Allbery]

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 <tanuki at gmail.com>
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 <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.
>
> _______________________________________________
> 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 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190509/dcc44378/attachment.html>