Am Freitag, 7. April 2006 00:40 schrieb Andy Adams-Moran:
Lennart Augustsson wrote:
Andy Adams-Moran wrote:
The only thing you can do with non-functions is put them in the sin
bin:
deepSeq :: a - IO ()
unsafeDeepSeq?
I guess we don't want to expand the unsafe* vocabulary for
Jan-Willem Maessen wrote:
On Apr 11, 2006, at 5:37 PM, Lennart Augustsson wrote:
Yes, I realize than dynamic idempotence is not the same as
cycle detection. I still worry. :)
I think expectance is in the eye of the beholder. The reason
that (the pure subset of) pH was a proper
On Apr 12, 2006, at 4:25 PM, John Meacham wrote:
On Wed, Apr 12, 2006 at 09:21:10AM -0400, Jan-Willem Maessen wrote:
Though, to be fair, an awful lot of Prelude code didn't work in pH
unless it was re-written to vary slightly from the specification. So
the assumption of laziness was more
On Apr 11, 2006, at 5:37 PM, Lennart Augustsson wrote:
Yes, I realize than dynamic idempotence is not the same as
cycle detection. I still worry. :)
I think expectance is in the eye of the beholder. The reason
that (the pure subset of) pH was a proper implementation of
Haskell was because
On Wed, Apr 12, 2006 at 09:21:10AM -0400, Jan-Willem Maessen wrote:
Though, to be fair, an awful lot of Prelude code didn't work in pH
unless it was re-written to vary slightly from the specification. So
the assumption of laziness was more deeply embedded than the spec was
willing to
On 10 April 2006 22:41, Andy Gill wrote:
Why can't we just steal a bit in the (GHC)
info table,
rather than mess with LSB of pointers, or have two info tables?
Because you need one bit per constructor *instance*. eg. there are two
variants of Just: the normal one, and the deepSeq'd one. So
| Any function that is not defineable in (pure) Haskell should be viewed
| with utmost suspicion. The seq function is one of these. At least
| seq has simple denotational semantics, which can't be said for
deepSeq.
|
| I say, put deepSeq in a type class (which is what I've done when I
need
|
On Tue, Apr 11, 2006 at 09:53:54AM +0100, Simon Peyton-Jones wrote:
Whether it should be in a class is a rather separate discussion. In a
way we already sold out when we allowed seq to escape from the
type-class world. Perhaps deepSeq is worse (because it traverses data
structures) but not
| well, there is a difference there in that 'seq' is unimplementable in
| haskell, so the design comitee had freedom to implement it however
they
| wanted.
class Eval a where
seq :: a - b - b
instance Eval (a,b) where
seq (_,_) b = b
On Tue, Apr 11, 2006 at 12:15:57PM +0100, Simon Peyton-Jones wrote:
| well, there is a difference there in that 'seq' is unimplementable in
| haskell, so the design comitee had freedom to implement it however
they
| wanted.
class Eval a where
seq :: a - b - b
Simon Peyton-Jones wrote:
| Any function that is not defineable in (pure) Haskell should be viewed
| with utmost suspicion. The seq function is one of these. At least
| seq has simple denotational semantics, which can't be said for
deepSeq.
|
| I say, put deepSeq in a type class (which is
| Well, my worry was partly about the suggested version of deepSeq that
| would not diverge on circular structures (since circular structures
| are just one way to implement infinite data structures).
Dynamic idempotence is not the same as detecting circular structures.
Deepseqing a circular
Yes, I realize than dynamic idempotence is not the same as
cycle detection. I still worry. :)
I think expectance is in the eye of the beholder. The reason
that (the pure subset of) pH was a proper implementation of
Haskell was because we were not over-specifying the semantics
originally. I
On 07 April 2006 22:38, Andy Gill wrote:
On Apr 7, 2006, at 3:59 AM, Rene de Visser wrote:
Hello,
As deepSeq has a non local effect, I think it requires a non-local
source transformation to implement it. One option would be for the
compiler to create a second deepSeq version of every
On Apr 10, 2006, at 2:25 AM, John Meacham wrote:
On Mon, Apr 10, 2006 at 10:10:18AM +0100, Simon Marlow wrote:
It's not *completely* straightforward to implement, at least in
GHC, and
at least if you want to implement it in a modular way (i.e. without
touching lots of different parts of the
You're assuming some particular representation where there are
bits to steal. I don't like this at all. I think tying deepSeq
to some particular implementation techniques is a reall *BAD* idea.
Any function that is not defineable in (pure) Haskell should be viewed
with utmost suspicion. The
On Mon, Apr 10, 2006 at 02:40:44PM -0700, Andy Gill wrote:
it is unlikely it will even be possible to implement in jhc without
radical changes to its internals. there is just no where to attach
a bit
to, and even if there were, there is no generic way to evaluate
something to WHNF, or even a
On Apr 5, 2006, at 4:51 PM, John Meacham wrote:
On Wed, Apr 05, 2006 at 10:34:09AM -0500, Spencer Janssen wrote:
How about an implementation that sets the deepSeq'd bit *after* each
field has been successfully deepSeq'd? deepSeq'ing a cyclic
structure
would behave just like an infinite
On 04 April 2006 19:53, Andy Adams-Moran wrote:
Andy Gill wrote:
let xs' () = 1 : 2 : xs' ()
let xs2 = xs'
let xs = 1 : 2 : xs
So deepSeq xs2 == _|_, but deepSeq xs == xs
Yes, and hence deepSeq isn't monotonic. That's bad.
I appeal to the morally correct reasoning argument .. If
On Tue, 04 Apr 2006, Andy Gill [EMAIL PROTECTED] wrote:
let xs' () = 1 : 2 : xs' ()
let xs2 = xs'
let xs = 1 : 2 : xs
So deepSeq xs2 == _|_, but deepSeq xs == xs
I appeal to the morally correct reasoning argument .. If the program
terminates, then it is still correct.
To avoid
| let xs' () = 1 : 2 : xs' ()
| let xs2 = xs'
|
| let xs = 1 : 2 : xs
|
| So deepSeq xs2 == _|_, but deepSeq xs == xs
No, no. deepSeq of either should be _|_.
That's easy to achieve, even with the marking idea. Simply do a
depth-first walk, but mark the node *after* traversing all its
Andy Gill wrote:
- [various reasons for deepSeq]
You left out the one that most interests me: ensuring that there are no
exceptions hiding inside a data structure.
deepSeq :: a - b - b
This ties demand for the (fully evaluated) normal form of an expression to
demand for the WHNF of a
On Wed, Apr 05, 2006 at 10:34:09AM -0500, Spencer Janssen wrote:
How about an implementation that sets the deepSeq'd bit *after* each
field has been successfully deepSeq'd? deepSeq'ing a cyclic structure
would behave just like an infinite structure.
what would be the point of having a bit
On 30 March 2006 23:12, Andy Gill wrote:
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)
On 4/4/06, Simon Marlow [EMAIL PROTECTED] wrote:
So deepSeq doesn't return _|_ when passed a cyclic structure? This is a
bad idea, because it lets you distinguish cyclic structures from
infinite ones. deepSeq has to behave like a function, regardless of its
implementation.
Why is this
On Apr 4, 2006, at 3:47 AM, Simon Marlow wrote:
On 30 March 2006 23:12, Andy Gill wrote:
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
Andy Gill wrote:
On Apr 4, 2006, at 3:47 AM, Simon Marlow wrote:
On 30 March 2006 23:12, Andy Gill wrote:
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
On Tue, Apr 04, 2006 at 11:52:55AM -0700, Andy Adams-Moran wrote:
I'm not convinced Simon's argument holds, as I don't think you can use
deepSeq to write a Haskell function that will distinguish cyclic
structures from infinite ones. If we can't do that, then we haven't
really added any new
On Apr 4, 2006, at 2:18 PM, John Meacham wrote:
On Tue, Apr 04, 2006 at 11:52:55AM -0700, Andy Adams-Moran wrote:
I'm not convinced Simon's argument holds, as I don't think you can
use
deepSeq to write a Haskell function that will distinguish cyclic
structures from infinite ones. If we
On Tue, Apr 04, 2006 at 02:53:36PM -0700, Andy Gill wrote:
Another issue is that being able to detect cyclic structures would
make
it impossible to express deepSeq as a Haskell - Haskell translation.
which is no good.
I am trying to understand this requirement. For the sake of what must
30 matches
Mail list logo
