On Tue, 25 Jan 2000, Chris Okasaki wrote:
> > 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.
As a purely _pragmatic_ argument: code that does things by taking blocks
of stuff from a list (e.g., some form of block based compression
technique) could be written (in broad outline)
f [] = []
f a xs =res:f a' zs
(ys,zs)=splitAt 40 xs
(a',res)=doStuff a xs
If the list isn't a multiple of 40 then only doStuff needs to know how to
deal with incomplete blocks with B; with values too big being an error f
has to check at each point whether there's enough list there before trying
the splitAt. So you have a way of ascertaining that length > 40 without
diverging on infinite lists. It all gets complicated, and this pattern
of `eat fixed size chunks while the list isn't depleted' seems common
enough to warrant simple programming.
I can't think of a pattern of usage that's natural that
leads to wanting to take negative portions of the list, but maybe that's
my imagination...
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm Farenheit 451 is the temperature at
email: [EMAIL PROTECTED] which paper burns. Let's do an experiment to
work tel: (0117) 954-5253 see what temperature melts human brain cells.
