John Meacham:
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 language features.
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.
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. Manuel