f x xs = let g y = x+y in map !! g xs
I'm imagining that this !! would not evaluate x, in much the same way as
!!(const 42 undefined)
==>
42
The program generating the deepSeq argument is free to use laziness
as much as it wants, just the (non functional parts of the) result
are completely evaluated.
Andy
On Apr 3, 2006, at 4:16 AM, Simon Peyton-Jones wrote:
Interesting idea.
What would you expect to happen here?
f x xs = let g y = x+y in map !! g xs
Here I'm evaluating the function g hyperstrictly before the call to
map.
Does x, the free variable in g's function closure, get evaluated?
From an implementation point of view, you could imagine that
hyperstrict
evaluation would pull apart function closures, as well as data
structures. But I'm not sure you could give that a sensible
denotational semantics.
Simon
| -----Original Message-----
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Andy Gill
| Sent: 30 March 2006 23:12
| To: haskell-prime@haskell.org
| Cc: Laura McKinney
| Subject: deeqSeq proposal
|
| For the reasons talked about in previous posts, I'd like to
propose a
| deepSeq
| for Haskell'.
|
| - It provides a mechanism to allow an effective, systematic
| tracking down of
| a class of space leaks.
| - It provides a mechanism to simply stomp on a class of space
leaks.
| - It avoids the user having to explicitly declare instances for a
| homebrew deepSeq
| for every type in your program.
| - It has a declarative feel; this expression is hyper strict.
| - Is a specification of strictness.
| - It will open up various optimization opportunities, avoiding
| building thunks.
| (I dont talk about this more, but I'm happy to elaborate)
| - It can have an efficient implementation, or a simple (slow)
| implementation.
| (The fast implementation one can be used to stomp space leaks,
| the slow one can help find the same leaks.)
|
| What I would like to propose for Haskell' are four things:
|
| (Essential) Add a deepSeq function into Haskell'
|
| deepSeq :: a -> b -> b
|
| - Don't really care if its in a class or not; would prefer not
for
| the reasons John Hughes talked about.
| - This would deepSeq all its children for regular constructors.
| - deepSeq would not indirect into IO or MVar.
| - functions would be evaluated to (W?)HNF.
| - IO, ST are functions under the hood.
|
| (Easy) Add a $!! function, and a strict function
|
| f $!! a = a `deepSeq` f a
| strict a = a `deepSeq` a
|
| (Nice) Add a !! notation, where we have ! in datatypes.
|
| data StrictList a = Cons (!!a) (!!StrictList a) | Nil
|
| (Perhaps) Add a way of making *all* the fields strict/hyperstrict.
|
| data !!StrictList a = ..,
|
| We could also do this for !
|
| --------------
|
| Implementation:
|
| deepSeq (RAW_CONS <is_deep_seq'd_bit> ... fields ) =
| if <is_deep_seq'd_bit> == True
| then return /* hey, we've already deepSeq'd this */
| else set <is_deep_seq'd_bit> to True.
| deepSeq (field_1)
| ...
| deepSeq (field_n)
| deepSEQ (REF/MVAR...) = return
|
| So we only deepSeq any specific constructor once! Sorta like lazy
| evaluation :-)
| We'd need to catch exceptions, unset the is_deep_seq'd_bit, so that
any
| subsequent call of deepSeq would also have the option of raising the
| exception.
|
| So,
|
| - How easy is this to add to the compilers? It looks pretty simple
| to me,
| and would provide huge bang-for-buck for Galois.
| - Any alternatives to the key concern; stomping on space leaks.
| (This proposal is orthogonal to the seq/Class discussion)
|
| Andy Gill
| Galois
|
| _______________________________________________
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
