Strict tuples

[Manuel M T Chakravarty]

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