Email list hosting service & mailing list manager

Re: Problems in the specs for 'gdelete' and 'gindex' Mark H Weaver (21 Jul 2019 09:25 UTC)
Problems in the specs for 'gdelete' and 'gindex' Mark H Weaver (21 Jul 2019 01:46 UTC)
Re: Problems in the specs for 'gdelete' and 'gindex'
Re: Problems in the specs for 'gdelete' and 'gindex' Arthur A. Gleckler (02 Mar 2020 23:09 UTC)
Re: Problems in the specs for 'gdelete' and 'gindex' John Cowan (02 Mar 2020 23:10 UTC)

Re: Problems in the specs for 'gdelete' and 'gindex' Mark H Weaver 21 Jul 2019 09:25 UTC

Hello again,

Earlier I wrote:

> (3) 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.
>
>     It then goes on to state:
>
>       The result generator is exhausted when either generator is
>       exhausted
>
>     I think there's a condradiction here.  If 'value-gen' is exhausted
>     first, that would seem to imply that there was an index that that
>     exceeds the number of elements generated by value-gen.

Sorry, I made a mistake.  The implication of the last sentence is
actually false, due to the off-by-one error mentioned in point (2) of my
last email.  The implication is true only if "exceeds" is changed to
"exceeds or equals".

In contrast, the converse implication is true regardless of whether "or
equals" is added or not, and so that's what I should have written above:

  If there's an index that exceeds the number of elements generated by
  value-gen, then 'value-gen' is exhausted first.

The remainder of point (3) still stands:

>     If you disagree, can you please give an example where the following
>     rule is applicable:
>
>       It is an error [...] if any index exceeds the number of elements
>       generated by value-gen.
>
>     and where the other error conditions are not applicable?

except that the "[...]" should be removed.

      Thanks,
        Mark