Hi Michael. thx for pointing me out this link. . It points out also that "Each entry comprises a key which is an arbitrary atomic value", and that ordering is implicited by fn:distinct-values. Hence functions or nodes can not be accepted as keys, neither can we supply external ordering functions. Maps of maps, maps of nodes are not possible with this specification.
Is it possible to propose / suggest changes to this specification ? 2013/11/21 Michael Kay <[email protected]> > The specification of map:new and map:entry can be found in the XSLT 3.0 > working draft, and it does indeed specify that when there are duplicates, > the last one wins. > > http://www.w3.org/TR/xslt-30/#map-functions > > Michael Kay > Saxonica > > On 21 Nov 2013, at 07:56, jean-marc Mercier <[email protected]> > wrote: > > @John > > Hello. > I started modifying your RB tree. I noticed that, while inserting two time > the same keys, the last inserted value replace > the previous one into your rbtree. As an illustration the following query > > let $map := map:new( > (map:entry("dummy","rocks"),map:entry("dummy","roll")) ) > return map:get($map,"dummy") > > returns "roll" > > I was expecting to "rocks". First : can you reproduce it ? (I modified > your files, and use BaseX interpretor. It is better to check with another > implementation). > Second, should I "roll" your rbtree or is this expected (is this a bug or > not ?) ? > > > > > > > 2013/11/20 jean-marc Mercier <[email protected]> > >> Yes you're right, using fold should be strightfroward. >> >> For the remove function, I'll try. Hopefully I won't spent too much time >> :) >> I'll keep you posted >> >> >> 2013/11/20 John Snelson <[email protected]> >> >>> On 20/11/13 13:16, jean-marc Mercier wrote: >>> >>>> ok. I've done a first draft that is working. I will keep the code a >>>> little bit to tune and complete it. For instance, that could be an idea >>>> to implement the remove($map,$key) function, or to implement key($map). >>>> >>> >>> Implenting keys($map) can be done using the fold() function. I recall >>> the remove() algorithm being a fair amount harder to implement in a >>> functional red/black tree, and I didn't need it so I didn't tackle it. >>> >>> >>> However, I have to modify your rbtree to do it. >>>> >>> >>> Very happy to accept contributions of a remove() implementation if you >>> do it. :-) >>> >>> >>> John >>> >>> -- >>> John Snelson, Lead Engineer http://twitter.com/jpcs >>> MarkLogic Corporation http://www.marklogic.com >>> >> >> > _______________________________________________ > [email protected] > http://x-query.com/mailman/listinfo/talk > > >
_______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
