Re: The map-lookup-forgiveness problem

Addressing the "difficulty to debug" issue, this reminds me of C# where
there are both the "." (member access)  and "?."  (null-conditional)
  operators.

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#null-conditional-operators--and-

Maybe we could have a "strict lookup" operator "?" that can be applied only
on maps and/or arrays, and raises error if applied on the empty sequence ,
and a null-conditional operator, say "??" that behaves like "?" on an array
or map, but when applied on the empty sequence, it doesn't raise an error,
and returns again the empty sequence?

Thanks,
Dimitre

On Tue, Feb 7, 2023 at 11:42 AM Dimitre Novatchev <dnovatchev@gmail.com>
wrote:

> @Michael Kay <mike@saxonica.com>  I understand this reasoning.
>
> But on the other hand, this is a real use-case submitted by a real user
> almost two years ago. They are maybe hoping to get our understanding...
>
> And a chain of map lookups using "?" is really similar to an XPath
> path-expression using "/".  One could also object to chaining an XPath
> expression with "/" and not reporting errors -- this is equally difficult
> to debug as its maps counterpart. But using path expressions the way they
> are is really convenient, and using chained map-lookup expressions will
> feel the same to XPath users.
>
> We are also thinking about "deep search" inside maps and arrays, and
> probably solving the "map forgiveness" problem could be a good step forward,
>
> Thanks,
> Dimitre
>
> On Tue, Feb 7, 2023 at 9:29 AM Michael Kay <mike@saxonica.com> wrote:
>
>> "?" is modelled on "/", and "/" requires the LHS to deliver nodes, so
>> this would be an inconsistency.
>>
>> The language is already very inconsistent about whether it's a good idea
>> to widen the domain of a function or operator to embrace items that can
>> only deliver a trivial result for the operation. For example we widen the
>> domain of name() to allow text nodes, but not to allow strings. The reason
>> we're inconsistent is that there are benefits in doing it, and there are
>> also benefits (type checking) in not doing it. Personally I think that a
>> void result, with no error, is one of the hardest things to debug, and as a
>> general rule I think it's a good idea to make it a type error to apply any
>> operation to inappropriate operands. But there will always be arguments
>> both ways.
>>
>> Michael Kay
>> Saxonica
>>
>> On 7 Feb 2023, at 17:06, Dimitre Novatchev <dnovatchev@gmail.com> wrote:
>>
>> At today's meeting Michael Kay asked for a detailed use-case for map
>> returning a map with no keys as a result of a failed lookup.
>>
>> Here is this described in https://github.com/qt4cg/qtspecs/issues/105  "[XPath]
>> Proposal: Maps with Infinite Number of Keys: Total Maps and Decorated maps
>> #105"
>>
>>
>> Using this representation of the empty sequence, we can provide a
>> solution for the *"Forgiveness problem"
>> <https://xmlcom.slack.com/archives/C011NLXE4DU/p1616167871037100>* raised
>> by Jarno Jelovirta in the XML.Com #general channel in *March 2021*:
>>
>> This expression will raise an error:
>>
>> [map {"k0": 1}, map{"k0": [1, 2, 3]}]?*?("k0")?*
>>
>> *[XPTY0004] Input of lookup operator must be map or array: 1.*
>>
>> To prevent ("forgive", thus "Forgiveness Problem") the raising of such
>> errors we could accept the rule that in XPath 4.0 any expression that
>> evaluates to something different than a map or an array, could be coerced
>> to the following map, which returns the empty sequence as the corresponding
>> value for any key requested in a lookup:
>>
>> map {'\' : ()
>> }  (: produces the empty sequence  for any lookup:)
>>
>>
>> Thanks,
>> Dimitre
>>
>>
>>
>
>
>
>