Brian Boutel wrote:
> On Thursday, January 27, 2000 2:08 PM, Frank A. Christoph
> [SMTP:[EMAIL PROTECTED]] wrote:
>
> >> My preference is still (B). (A) is not *very* bad, but should really
> >> replicate (-7) "foo" be []?
> >
> >I could say: Sure, why not? replicate suffers from the same
> domain problem
> >as take/drop.
>
> This was not the point of introducing replicate to the discussion.
> The Prelude says, in a comment,
>
> -- replicate n x is a list of length n with x the value of every element
>
> and then defines replicate in terms of take.
>
> replicate :: Int -> a -> [a]
> replicate n x = take n (repeat x)
I don't see that there is any great difference between that and the Prelude
comment describing take:
-- take n, applied to a list xs, returns the prefix of xs of length n, or xs
itself if n > length xs.
Both descriptions are equally undefined w.r.t. negative arguments.
My point is that when the behavior of replicate was described using the
equation above, I think the authors did not intend (although I admit you
would know better than me :) to define replicate in terms of the behavior of
take, whatever it happens to be, but rather in terms of a specific
mathematical function which they wrongly thought take denoted. We all agree
that take is ill-defined; replicate is ill-defined for the exact same
reason, so I would presume that _in principal_ the semantics of replicate
are also up for grabs. So I'm just saying you can't argue for a specific way
of completing take by just pointing at replicate if you want to respect the
spirit (i.e., intended meaning) and not just the letter of the Prelude.
That said, I certainly think we _should_ define the new behavior of
replicate so that it agrees with the above equation, if possible. (In other
words, I was just nitpicking. :) I agree with everything else you wrote:
--fac
> There is a clear assumption on the part of the Prelude authors
> that take behaves in a particular
> way, corresponding to the law
> length (take n xs ) === n
> but it doesn't. So even the authors of the Prelude got caught by
> take's inconsistency.
>
> While I dislike functions with a simple, obvious intended
> semantics being extended in non-obvious,
> non-simple ways, because it creates just this kind of error, I
> understand that many people are less concerned
> about it. I can live with any of the proposed definitions, but do
> suggest that incorrect statements are corrected.
>
> So, if negative values are to be allowed in take, the comment re
> replicate should say,
>
> -- if n >=0 replicate n x is a list of length n with x the value
> of every element
>
> Or, if negative values are *not* to be allowed in take, then fix
> the present code so that they are
> not allowed for any list, including [].
>
> --brian
>
>
>
>
