Dear Wouter, Yes, the first version of Mike's example (=>) uses fn:replace#4, the second version (!) uses fn:replace#3.
I am not sure what you mean with "detect" : unless I am missing something, it is always 100% clear from the syntax itself which function to use from an EQName and from the number of parameters in the function invocation. When => is used, one always needs to add 1 to the arity when looking up the function. With =>, the implicit binding always occurs and it is statically known that fn:replace#4 must be used in this case, it is a bit like a rewrite. Once the function has been looked up, it is invoked according to the semantics of a function call. Kind regards, Ghislain > On 2 Aug 2017, at 12:07, W.S. Hager <[email protected]> wrote: > > Hi Ghislain, > > Alright, I forgot about fn:replace#4, but the implicit binding is sometimes > hard to detect. > > Thanks. > > 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <[email protected]>: > ... I didn't get it quite right actually. In @address => string(), there is > no context item involved, I wrote too fast. :-) > > New attempt: > > @address ! string(.) (: explicitly passed context item :) > @address ! string() (: context item passed implicitly to string#0, which is > context-dependent) > @address => string() (: @address passed implicitly to string#1 as the first > parameter via the => operator, but string#1 is context-independent) > @address => string(.) (: error: string#2 does not exist :) > > Kind regards, > Ghislain > > > > On 2 Aug 2017, at 12:00, Ghislain Fourny <[email protected]> wrote: > > > > Dear Wouter, > > > > There is one more important difference on the syntactic level. > > > > With the arrow operator, the left-hand-side is implicitly bound to the > > first parameter of the function. > > > > @address => replace(@postcode, "", "q") > > > > is the same as > > > > replace(@address, @postcode, "", "q") > > > > > > With the simple map operator, the context item must be explicitly referred > > to, like so: > > > > @address ! replace(., @postcode, "", "q") > > > > > > What may create confusion is that some functions have several signatures, > > some of which implicitly refer to the context item. But this is a very > > different mechanism. > > > > For example : > > > > @address ! string(.) (: explicitly passed context item :) > > @address ! string() (: context item passed implicitly to string#0, which is > > context-dependent) > > @address => string() (: context item passed implicitly to string#1 via the > > => operator, but string#1 is context-independent) > > > > I hope I got it right! > > > > Kind regards, > > Ghislain > > > > > >> On 2 Aug 2017, at 11:27, W.S. Hager <[email protected]> wrote: > >> > >> Hi Michael, > >> > >> The way you used the arrow operator in the example would be the way I > >> expected it to work, namely by explicitly addressing the context, but it > >> seems that it doesn't. It's actually implicitly binding the first argument > >> of the function on the right to the value on the left. Or is there an > >> exception I don't know about? > >> > >> Thanks. > >> > >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <[email protected]>: > >> In the case of singletons there's very little difference, but (as I now > >> see Christian has pointed out), with sequences the effect is quite > >> different. > >> > >> Also, of course, "!" changes the context item, so > >> > >> @address => replace(@postcode, "", "q") works, while > >> > >> @address ! replace(@postcode, "", "q") doesn't. > >> > >> Michael Kay > >> Saxonica > >> > >>> On 1 Aug 2017, at 13:27, W.S. Hager <[email protected]> wrote: > >>> > >>> Hi, > >>> > >>> Is there any advantage to using the 3.1 arrow operator over the simple > >>> map operator? > >>> > >>> $string => upper-case() => normalize-unicode() => tokenize("\s+") > >>> > >>> versus > >>> > >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+") > >>> > >>> Thanks, > >>> Wouter > >>> _______________________________________________ > >>> [email protected] > >>> http://x-query.com/mailman/listinfo/talk > >> > >> > >> _______________________________________________ > >> [email protected] > >> http://x-query.com/mailman/listinfo/talk > > > > > > _______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
