Would the problematic semantics of seq be resolved if seq did nothing on function types? That is to say seq (\x -> undefined `asTypeOf` x) y reduced to y and seq (undefined `asTypeOf` id) y also reduced to y -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
On Tue, 2006-07-18 at 09:44 -0400, roconnor@theorem.ca wrote:
Would the problematic semantics of seq be resolved if seq did nothing on function types? That is to say
seq (\x -> undefined `asTypeOf` x) y reduced to y
and
seq (undefined `asTypeOf` id) y also reduced to y
I don't think so. You'd also have to avoid polymorphic types since they can be used at function types. Basically you'd have to bring back the Seq class. The rationale for removing the class and making seq polymorphic is mentioned in the history of Haskell draft paper that was recently advertised. Duncan
On Tue, 18 Jul 2006, Duncan Coutts wrote:
On Tue, 2006-07-18 at 09:44 -0400, roconnor@theorem.ca wrote:
Would the problematic semantics of seq be resolved if seq did nothing on function types? That is to say
seq (\x -> undefined `asTypeOf` x) y reduced to y
and
seq (undefined `asTypeOf` id) y also reduced to y
I don't think so. You'd also have to avoid polymorphic types since they can be used at function types. Basically you'd have to bring back the Seq class. The rationale for removing the class and making seq polymorphic is mentioned in the history of Haskell draft paper that was recently advertised.
I don't understand. At execution time, all the polymoric variables are gon, so we know the type of the parameter to seq. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
On Wed, 2006-07-19 at 08:09 -0400, roconnor@theorem.ca wrote:
On Tue, 18 Jul 2006, Duncan Coutts wrote:
On Tue, 2006-07-18 at 09:44 -0400, roconnor@theorem.ca wrote:
Would the problematic semantics of seq be resolved if seq did nothing on function types? That is to say
seq (\x -> undefined `asTypeOf` x) y reduced to y
and
seq (undefined `asTypeOf` id) y also reduced to y
I don't think so. You'd also have to avoid polymorphic types since they can be used at function types. Basically you'd have to bring back the Seq class. The rationale for removing the class and making seq polymorphic is mentioned in the history of Haskell draft paper that was recently advertised.
I don't understand. At execution time, all the polymoric variables are gon, so we know the type of the parameter to seq.
Ah ok, I misunderstood. Well that'd be a bit odd too. No other function behaves differently on different types except by use of type classes. It'd make the implementations difficult too since for the rest of the language the types are not needed at runtime and so most implementations do not keep the types available at runtime. Furthermore, the fact is that seq on function types is actually useful for controlling space and time behaviour, so it's not clear that we want to ban it. Duncan
On Wed, 19 Jul 2006, Duncan Coutts wrote:
Ah ok, I misunderstood. Well that'd be a bit odd too. No other function behaves differently on different types except by use of type classes.
I agree it is quite odd, but the seq we have is already quite odd.
Furthermore, the fact is that seq on function types is actually useful for controlling space and time behaviour, so it's not clear that we want to ban it.
Do you have an example of use of seq on a function type? (Of course I don't want to ban it, just change its behaviour.) -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
participants (2)
-
Duncan Coutts -
roconnor＠theorem.ca