On Tue, Mar 21, 2006 at 02:27:37PM -0500, Manuel M T Chakravarty wrote:
> > strictness does not belong in the type system in general. strictness
> > annotations are attached to the data components and not type components
> > in data declarations because they only affect the desugaring of the
> > constructor, but not the run-time representation or the types in
> > general. attaching strictness info to types is just the wrong thing to
> > do in general I think.
>
> I am *not* proposing any addition or change to the type system. In H98,
> I can define
>
> data Pair a b = Pair a b
> data StrictPair a b = StrictPair !a !b
>
> For some reason, we have Pair with special syntax pre-defined, but we
> haven't got StrictPair pre-defined. All I am proposing is to also
> pre-define StrictPair.
yes, but 'StrictPair a b' being a separate type from '(,) a b' is the
problem I am refering to.
personally, I just really don't see much use for them and feel they will
give a false sense of efficiency while only creating headaches. Imagine
two uses.
f :: (! a,b!) -> Int
f (!a, b!) = 3
well, this can better be expressed as
f :: (a,b) -> Int
f (!a, !b) = 3
and now you can still do things like 'curry f'
now, imagine it in return position
f :: a -> (! x,y!)
f a = (! x, y !)
this can better be expressed as
f :: a -> (x,y)
f a = x `seq` y `seq` (x,y) -- ^ some syntatic sugar
for this could be nice
If you care enough about some data you are passing around to intimatly
know whether it might or might not have bottoms in it, then chances are
it is something you want a custom data type for anyway. strict tuples
would not really express intent any more and without some sort of
subtyping mechanism the hassle of dealing with them would greatly
outweigh the questionable benefit.
not that people shouldn't create their own 'data StrictPair' if they
want. but I would never want to see such a type in any public APIs. It
would just not be very friendly.
> > however, strict tuples I think would have use in function returns,
> > no need to declare them as a separate type, just have
> >
> > (! a,b !) desugar exactly to a `seq` b `seq` (a,b)
> >
> > this avoids any type issues and the only time the strictness of a
> > constructor comes into play is in the constructor desugaring anyway, it
> > makes sense that strict tuples would be a simple desugaring to normal
> > tuples as well.
>
> The disadvantage of this scheme is that the consumer of a strict tuple,
> then, has no knowledge of the fact that the components are already
> evaluated - ie, this wastes a good opportunity for optimisations.
optimizations for who? knowing something is already evaluated without
any other knowledge about it affords no optimizations in the ghc model
(but actually does in the jhc one), knowing things will definitily be
evaluated certainly does. which strict tuples don't really help with any
more than the 'seq' translation would.
John
--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
