sebastian.sylvan at gmail.com
Mon Mar 20 09:26:15 EST 2006
On 3/19/06, Manuel M T Chakravarty <chak at cse.unsw.edu.au> wrote:
> Loosely related to Ticket #76 (Bang Patterns) is the question of whether
> we want the language to include strict tuples. It is related to bang
> patterns, because its sole motivation is to simplify enforcing
> strictness for some computations. Its about empowering the programmer
> to choose between laziness and strictness where they deem that necessary
> without forcing them to completely re-arrange sub-expressions (as seq
> So what are strict tupples? If a lazy pair is defined in pseudo code as
> data (a, b) = (a, b)
> a strict pair would be defined as
> data (!a, b!) = ( !a, !b )
> Ie, a strict tuple is enclosed by bang parenthesis (! ... !). The use
> of the ! on the rhs are just the already standard strict data type
Maybe I've missed something here. But is there really any reasonable
usage cases for something like:
f !(a,b) = a + b
in the current bang patterns proposal?
I mean, would anyone really ever want an explicitly strict (i.e. using
extra syntax) tuple with lazy elements?
Couldn't the syntax for strict tuples be just what I wrote above
(instead of adding weird-looking exclamation parenthesis).
I'm pretty sure that most programmers who would write "f !(a,b) = ..."
would expect the tuple's elements to be forced (they wouldn't expect
it to do nothing, at least).. In fact !(x:xs) should mean (intuitively
to me, at least) "force x, and xs", meaning that the element x is
forced, and the list xs is forced (but not the elements of the xs).
Couldn't this be generalised? A pattern match on any constructor with
a bang in front of it will force all the parts of the constructor
f !xs = b -- gives f xs = xs `seq` b, like the current proposal
f !(x:xs) = b -- gives f (x:xs) = x `seq` xs `seq` b, unlike the
The latter would then be equal to
f (!x:xs) = b
right? Just slightly more convenient in some cases...
f (A !b (C !c !d) !e !f !g) = y
would be equivalent to:
f !(A b !(C c d) e f g) = y
Instead of the latter meaning doing nothing...
More information about the Haskell-prime