[m-rev.] for review: document failrue conditions for list.split/4

[Julien Fischer]

On Thu, 2 Jun 2016, Peter Wang wrote:

> On Thu, 2 Jun 2016 15:25:46 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> Hi Peter,
>>
>> On Thu, 2 Jun 2016, Peter Wang wrote:
>>
>>> On Thu, 2 Jun 2016 12:06:38 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>>>>
>>>> For review by anyone.
>>>>
>>>> I would also be intrested in feedback whether the current behaviour
>>>> of list.{drop,take} when their first argument is negative is intended.
>>>
>>> I think the behaviour is okay, and consistent with at least the indexing
>>> predicates in the list module.
>>
>> Ok, in that case I propose we add the following sentence to the
>> documentation.
>>
>>         If `Len' < 0 then `End' = `List'.
>
> Forget what I said before, it doesn't make sense.  Trying again...
>
> If, conceptually, we have:
>
>    take(Len, List, Start) :-
> 	split_list(Len, List, Start, _End).
>
>    drop(Len, List, End) :-
> 	split_list(Len, List, _Start, End).
>
>    split_list(Len, List, Start, End) :-
> 	take(Len, List, Start),
> 	drop(Len, List, End).
>
> then the three predicates ought to behave consistently for all values of
> `Len', agreed?

Agreed.

> The only inconsistency is for Len < 0.  They should either
>
>  1. all fail for Len < 0 (change to take/drop)
>
>  2. all treat Len < 0 like Len = 0 (change to split_list)
>
> I think the first option is less surprising.

Likewise, I can't imagine a situation where you are going to
want to use a negative value for that argument on purpose.

Julien.