[erlang-questions] lists:seq/[2,3] bug?

[Richard A. O'Keefe]

On 19 Sep 2008, at 5:20 am, Kostis Sagonas wrote:

> Richard A. O'Keefe wrote:
>> On my Mac I have Erlang R12B-3.
>> .....
>>
>> lists:seq(1, N) gives me the expected N-element list for
>> integers N >= 1.  I expect, indeed, I would require, that
>> lists:seq(1, 0) should give me the empty list.

I was not referring to an IMPLEMENTATION bug,
but to a DESIGN bug.
As in, the function does what it is documented
as doing, but that's not clearly the best thing to do.

If lists:reverse/1 had been designed to crash on
empty lists, or if lists:sublist(List, N) had been
designed to crash if N was 0, EVEN IF the code did
exactly what it was documented as doing, I think it
would be reasonable to regard that as a design bug.

>> So, I fail to see why, after having read the manual, one is  
>> surprised by
> the results below:

I am NOT surprised by the results.
What I am is DISMAYED by them.

It seems absurd to handle an increment of 0 (none of the
languages I normally use bother with that) but to refuse
to return a result with a length of 0, especially as the
zero-length-result CAN be very naturally included in the
scope of a SIMPLE explanation of what the result is, but
the zero-step case CANNOT.

What I am asking for is a DESIGN change,
to get exactly the same result that we get now in every
case where the current code gives any result at all, but
to ALSO yield zero-length results when a simple
specification (like "the length of the result is Max-Min+1")
would lead you to expect them.

I now have a slightly cleaner version of the code,
which runs about twice as fast as the current library version.
More speed AND more results.