Re: Function naming: Problems and proposed solution

Let's think about map:remove(). Is there any way we can make it work without a prefix, given that fn:remove#2 also exists, and is also applicable to maps (though it doesn't do anything useful with them). We have the problem that $map => remove(1) already has a well-defined meaning (it returns an empty sequence).

One thing that might work is $map => .remove('abc') where the "." is not an operator, but a syntactic marker indicating that the function name "remove" is to be resolved in a type-sensitive way. It's certainly parseable, because "=>" cannot currently be followed by ".". Whether it's goodness or ugliness is another matter.

Michael Kay
Saxonica

> On 28 Nov 2020, at 17:06, Michael Kay <mike@saxonica.com> wrote:
> 
>> 
>> current-date().year() seems quite readable?
>> 
> 
> Wow, "." as an operator. First thought was, it won't parse: "." is a valid character in names, so you wouldn't be able to write $my-date.date() without a space, and that feels to me like a show-stopper (especially as the diagnostics would be very obscure). Also there are just too many similar operators (=>, ?, !, /) and it's getting confusing. We would have used "." rather than "=>" in 3.1 if it weren't for the parsing difficulties.
> 
> Next thought is, what exactly are the semantics? How does it differ from "=>"? Perhaps the difference is about where we look for the function year()? The implication here, I think, is that we look in some set of type-specific functions ("methods", if you like) available for instances of xs:date. If we introduce a concept of type-specific functions like this, then I think we can use the existing operator (=>) without introducing the parsing complications of ".".
> 
> Michael Kay
> Saxonica
>