[Haskell] semantice of seq

[Duncan Coutts]

On Wed, 2006-07-19 at 08:09 -0400, roconnor at theorem.ca wrote:
> On Tue, 18 Jul 2006, Duncan Coutts wrote:
> 
> > On Tue, 2006-07-18 at 09:44 -0400, roconnor at 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