Re: Issues recommended for closure

Specifically for #112, in the thread there is a very good proposal by
Michael Kay, which I had thumbed-up immediately when his comment was
written:

https://github.com/qt4cg/qtspecs/issues/112#issuecomment-1337294982

Why should we bury the issue given the fact that there was a good
discussion and a good proposal came as result?

Thanks,
Dimitre

On Mon, Feb 20, 2023 at 10:10 AM Dimitre Novatchev <dnovatchev@gmail.com>
wrote:

> > #112: allow $map?function() in place of map:function($map)
> >
> >Rationale: the original proposal introduced an ambiguity, and subsequent
> discussion on the issue did not converge on a proposal that might achieve
> consensus
>
> I am against closing #112. Just re-read it and I do not agree with the
> provided argumentation for closing the issue. This issue is as actual and
> existing as at the time it was raised.
>
> Let's discuss at a meeting.
>
> > #260: array:index-of
> >
> > Rationale: the proposed function is essentially indistinguishable from
> array:index-where
>
> Which is why we shouldn't use any high level programming languages when
> there is the assembler language.
>
> Here is the last comment (by Michael Kay) on this issue:
>
> > While I think it's nice to have symmetry between functions on sequences
> and functions on arrays wherever possible, fn:index-of() relies on an
> equality operator for
>
> > items that is "eq using a supplied or default collation". That operator
> doesn't extend naturally to comparison of sequences; we would need to use a
> different equality operator.
>
> > (a) it's not obvious what equality operator should be used by default
> > (b) if we allowed a user-specified equality test then we would be
> replicating array:index-where()
> > (c) whatever we chose as a default, it would be different from the
> fn:index-of() semantics, which would mean that the apparent similarity of
> fn:index-of and array:index-of is misleading and spurious.
>
> Here are my answers to (a), (b), and (c) above:
>
> > (a) it's not obvious what equality operator should be used by default
>
> This would be fn:deep-equal()   (with its "false-on-error" option
> correctly  defined as true() by default ). As with any default, the users
> have the option to override it. Does this option mean that we should not
> have defaults in the first place?
>
> > (b) if we allowed a user-specified equality test then we would be
> replicating array:index-where()
>
> Not replicating, just giving the developer a convenient shorthand for an
> important and frequent use-case. We have more than one example of providing
> such convenience for the developer, so this is in line with this correct
> strategy.
>
>
> > (c) whatever we chose as a default, it would be different from the
> fn:index-of() semantics, which would mean that the apparent similarity of
> fn:index-of and array:index-of is misleading and spurious.
>
> The standard function fn:index-of() also needs to be expanded with a
> comparer argument (as shown many times by users such as Martin Honnen, as
> we often need to deal with different kinds of equality, such as value-based
> and identity-based equality). And if both  fn:index-of() and
> array:index-of() have a comparer() parameter, then it is natural that this
> argument can have different defaults in the case of index of a value in a
> sequence as compared to the case of index of a member in an array. The fact
> that the semantics of a sequence vs. array is different is well-known and
> we shouldn't try to hide it or artificially eliminate it.
>
>
> Thanks,
>
> Dimitre
>
> On Mon, Feb 20, 2023 at 8:17 AM Michael Kay <mike@saxonica.com> wrote:
>
>> Could I ask for an agenda item to close the following issues with no
>> action, for the reasons stated:
>>
>> #45 - second parameter of fn:sum must be neutral element
>>
>> Rationale: this cannot be done while preserving compatibility, and the
>> requirement is not strong enough to justify a new function.
>>
>> #60 - namespace-uri-for-prefix() no longer allows passing a string
>>
>> Rationale: the new coercion rules mean that a supplied string will be
>> down-cast, so there is no compatibility issue - except possibly for the
>> error code
>>
>> #112: allow $map?function() in place of map:function($map)
>>
>> Rationale: the original proposal introduced an ambiguity, and subsequent
>> discussion on the issue did not converge on a proposal that might achieve
>> consensus
>>
>> #147: terse syntax for map entries
>>
>> Rationale: the discussion showed no signs of converging on a proposal
>> that might achieve consensus
>>
>> #260: array:index-of
>>
>> Rationale: the proposed function is essentially indistinguishable from
>> array:index-where
>>
>>
>> Michael Kay
>> Saxonica
>>
>>
>>
>>
>>
>>
>
>