[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