[m-rev.] for review: document failrue conditions for list.split/4
Peter Wang
novalazy at gmail.com
Thu Jun 2 17:08:49 AEST 2016
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?
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.
Peter
More information about the reviews
mailing list