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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
