Manuel M T Chakravarty
chak at cse.unsw.edu.au
Tue Mar 21 14:27:37 EST 2006
> On Mon, Mar 20, 2006 at 09:39:41AM -0500, Manuel M T Chakravarty wrote:
> > Apart from the syntactic issues, does anybody else support the idea of
> > strict tuples as proposed? I just want to know whether I am alone on
> > this before putting it on the wiki.
> I have a few issues though, not entirely easy to articulate.
> I worry about all the (! .. !) types that will appear in interfaces,
> making things like (map fst) not work. It has been my experience that a
> lot of things that should be strict that are obvious to the user, are
> often obvious to the compiler as well. having the user place redundant
> strictness annotations in can ofsucate where the actual performance
> fixes are. As in, are lazy tuples actually a source of problems or are
> we just guessing? ghc's strictness analyzer is pretty darn good, If
> something is subtle enough for the compiler not to catch it, then the
> programmer probably won't right off the bat either. it usually takes
> profiling to determine where the human-fixable problems are.
I agree that strict tuples can be abused, but that's true for most
> 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
> 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.
More information about the Haskell-prime