elf at sandburst.com
Mon Feb 6 14:40:29 EST 2006
i would argue against treating tuples as pure syntactic sugar for
nested pairs; since the nesting carries hierarchical information, i
would expect (x,y,z) used in place of (x,(y,z)) to cause an error.
bluespec classic implemented n-tuples this way, and the error
messages were rather ugly. not to mention that explaining this to
beginners feels like a "oh yeah, it's not clean, it was an easy hack"
On Feb 4, 2006, at 11:03 PM, Robert Dockins wrote:
> On Feb 4, 2006, at 7:56 PM, Pablo Barenbaum wrote:
>> An awkwardness in Haskell I would like to see solved in
>> Haskell', is the fact that the behavior of tuple-like
>> constructors must be either built-in or "limited".
> One thing I recall seeing on haskell-cafe some time back was the
> notion that an n-tuple is semantically equivalent to n nested right-
> strict 2-tuples (essentially right-strict heterogeneous lists).
> Perhaps we should consider the idea of the tuple notation simply
> being syntactic sugar for nested right-strict 2-tuples. Consider:
> data Tuple a b = Tuple a !b
> -- (a,b) === Tuple a (Tuple b ())-- (a,b,c) === Tuple a (Tuple b
> (Tuple c ()))
> -- etc...
> fst (Tuple x _) = x
> snd (Tuple x (Tuple y _)) = y
> fst ('a',b') = 'a'
> snd (a','b) = 'b'
> fst ('a','b','c') = 'a'
> snd ('a','b','c') = 'b'
> fst ('a','b','c','d','e','f') = 'a'
> -- etc...
> It seems like compiler cleverness could recover the identical
> strictness and unboxing information available now when the "shape"
> of the tuple is known at compile time.
>> As far as I can see, these are two issues:
>> 1. There is not a way, for the programmer, to define
>> infinite constructors for infinite associated types (such as
>> (,) (,,) (,,,) ... / (a, b) (a, b, c) (a, b, c, d) ...)
>> these must be built-in.
>> 2. There is not a way to define functions operating on all
>> of these types. Instead, different functions (like zip,
>> zip3) must be defined. Something similar happens with
>> liftM, liftM2, ... these are "limited".
>> It seems the language is lacking abstraction, or being
>> misused, when the standard prelude issues this code:
>> zip :: [a] -> [b] -> [(a,b)]
>> zip = zipWith (\a b -> (a,b))
>> zip3 :: [a] -> [b] -> [c] -> [(a,b,c)]
>> zip3 = zipWith3 (\a b c -> (a,b,c))
>> Clearly, at least for a human being, it's redundant.
>> I don't know if there already are proposals to solve this.
>> Sorry if I sound aggresive, I'm just trying to help.
>> Excuse my English...
>> Best regards.
>> Pablo Barenbaum
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
> Rob Dockins
> Speak softly and drive a Sherman tank.
> Laugh hard; it's a long way to the bank.
> -- TMBG
> Haskell-prime mailing list
> Haskell-prime at haskell.org
More information about the Haskell-prime