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