Email list hosting service & mailing list manager

Problems in the specs for 'gdelete' and 'gindex' Mark H Weaver (02 Jul 2019 04:23 UTC)
(missing)
Re: Problems in the specs for 'gdelete' and 'gindex' Mark H Weaver (02 Jul 2019 04:34 UTC)
Fwd: Problems in the specs for 'gdelete' and 'gindex' John Cowan (03 Jul 2019 02:31 UTC)
Re: Problems in the specs for 'gdelete' and 'gindex' Mark H Weaver (11 Jul 2019 23:14 UTC)

Re: Problems in the specs for 'gdelete' and 'gindex' Mark H Weaver 11 Jul 2019 23:11 UTC

Hi John,

John Cowan <xxxxxx@ccil.org> wrote:

> On Tue, Jul 2, 2019 at 12:23 AM Mark H Weaver <xxxxxx@netris.org> wrote:
>
>
>> (1) The spec for 'gdelete' states:
>>
>>       The = predicate is passed exactly two arguments, of which the
>>       first was generated by gen before the second.
>>
>
> Clearly that sentence was copied from gdelete-neighbor-dups.

Yes.

> But in any case, the = argument should be an equivalence relation,
> which means it is symmetrical.

It would be, except that SRFI-121 explicitly specifies that the
arguments will be passed in a particular order.  That's a nonsymmetric
promise which clearly invites users to provide a nonsymmetric '='.  If
that was not your intent, why make the promise?

>> (2) The spec for 'gindex' makes apparently conflicting assertions about
>>     what should happen if 'value-gen' is exhausted before 'index-gen' is
>>     exhausted.  First, it states:
>>
>>       It is an error if the indices are not strictly increasing, or if
>>       any index exceeds the number of elements generated by value-gen.
>>
>>     This seems to imply that it should be an error if 'value-gen' is
>>     exhausted first.
>
>
> I don't think so, no.

Can you provide a concrete example where following rule is applicable:

   "It is an error [...] if any index exceeds the number of elements
   generated by value-gen."

and where the other specified error conditions are not applicable?

>> In other words, each index should be in the range 0..N-1, where N is the
>> number of elements generated by VALUE-GEN.  Is that right?
>
>
> Yes.

Thanks.

     Regards,
       Mark