This is probably flame bait. You are warned!
Simon Peyton-Jones wrote:
> (A) Make them defined for any n. If n < 0, do something reasonable:
> take: give empty list
> drop: give whole list
>
> (B) Make them defined for n > length xs, but fail for n < 0.
>
> I've heard suppport for both. Personally I
> favour (A) but only mildly. (B) is a smaller change.
I've been lurking on the list for a couple of months. I've always liked
the aesthetical aspect of functional programming and figured Haskell
would be a good start. However, I didn't go far beyond reading the
tutorials/reports and writing some toy-programs... I am probably not the
only one! Basically, I think you ought to think more about programmer
ergonomics (the namespace is polluted, the notation is overly historical
(math), and my impression is that there is too much special case stuff
for something that is supposed to wet the aesthetical appetite..).
You need to
1) Think about the practical conceptual model the (new) programmer has
of the language and it's constructs.
2) Think about the audience you target.
If you want Haskell to remain obscure, then you probably can ignore the
rest of this message! ;^)
1) I think it is basically wrong to ask "what is the semantics of
take/drop supposed to be?", you should ask "what is a list?". Is a
finite list, really finite, or is it infinite and padded with "empty" or
"bottom", is it circular, or..? Then make all operators consistent with
that conceptual view. In my view, you should have to prequalify an
entity if you want to interpret it differently (view_list_as_circular).
However, the conceptual model should not be taken as the axioms which
the language "is constructed" from, but the high level view the
programmer find convenient when solving design problems.
2) Are you trying to cater for web-hackers of the perl/python variety,
applied math people or people oriented towards verifiable programming?
They are likely to hold different conceptual models... I think you
should focus on those that has most need for something like Haskell,
which most likely are the verifiable programming types...
If I was to vote on this issue then I would choose the most conservative
path. You can always be more liberal at a later stage. You should only
go for the more liberal semantics if a significant number of actual
Haskell programs define their own take/drop functions that way. (Don't
design a could-be-neat language, but an internally consistent one, on
the global level.)
I think negative take/drop should be conceptually viewed as
prepending/appending "empty"/"bottom"/"default value". It would be nice
if "take 5 (take -1 some_list)" was equal to "take 4 some_list". (I
guess it would be more difficult to achieve this with the opposite
order.)
Ola.
