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"
copout :)
-- m
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
[email protected]
http://haskell.org/mailman/listinfo/haskell-prime
Rob Dockins
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
_______________________________________________
Haskell-prime mailing list
[email protected]
http://haskell.org/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
[email protected]
http://haskell.org/mailman/listinfo/haskell-prime
