> > I'm with the option (B): negatives are just outside > > the domain of take&drop, and should give you an error > > message. > > For the people that share this sentiment, can you please > explain why ints that are too big should not similarly > give an error? I can see both being ok, or both being > errors. I just don't see why one should be ok and the > other an error. >From a 'common sense' point of view, if I don't know how many coins are in a bag, and I told you "Take 10 coins", it's sensible that, if there are less than 10 (say, 5), instead of telling me than they are not enough, you just pick all of them, and says "I only could take 5". But if I told you "Take -1 coins", you will think that I'm joking at you, or I'm just a weirdo. I think that it is a good idea that programs can be thought with common sense, and not just readable by hackers. >From a pragmatical point of view, negative numbers as take's arguments are likely to be bugs (and if not, use another function), but it is not a bug if I don't know the lenght of the list. So, asking the behaviour of take to depend on the lenght of the list is too restrictive. Quoting a previous post by Qrczak: "The current behavior can be useful and could not be simulated well using your version. Trivial example: you want to see what remains from a text file after scrolling left a few columns and clipping the right margin to the window width. Present versions of both drop and take are needed. drop and take mean "drop/take at most that many"." If you make the behaviour of take and drop dependant of the lenght of the list, then you could end with space leaks. Of course, I can be wrong, and all this be a nonsense. May you support your point, please? Fidel.
