Re: Re: Function memoization

> > Also, developers could have a flexible definition, so that
> > memberwise comparison could be used for sequences up to,
> > let's say, ten items and reference (ID) comparison will be
> > used for comparing longer sequences.  This treshold can
> > even be determined dynamically depending on the speed of
> > execution.
> 
>   IMHO, it is a bad idea, as this could result in different
> results when arguments are sequences of different size.  But
> if it is needed, having the ability to set the comparator
> let the developer the ability to get it.


I guess you and Colin are referring to "functions" that return
newly-created nodes...

Let's put this straight in the specification and say that this is a
"feature" of XSLT 2.0 of which developers/users must be warned and aware.

I believe any attempt to memoise such functions correctly will have mixed
results -- so, let's just warn the users and do the good thing for the
real functions.


Cheers,
Dimitre

--- Florent Georges <[email protected]> wrote:

> Dimitre Novatchev wrote:
> 
>   Hi
> 
> > If in the context of memoisation we accept that "identity"
> > is equivalent to all-memberwise identity of the items of
> > the two sequences, then the effect of memoising long
> > sequences arguments will be negative! It will actually be
> > harmful!
> 
>   Good point.
> 
> > I am proposing to leave developers the potential to define
> > and implement sequence "identity" in the context of
> > memoisation using other definitions (such as the
> > reasonable comparison of a single "sequence-reference").
> 
>   Good idea.  Do you think to something like the following:
> 
>     <xsl:function name="...">
>       <xsl:param name="..."/>
>       <func:memoisation comparator="..."/>
>       ...
>     </xsl:function>
> 
> where @comparator is a QName identifying a function (with
> something like func:sequence-identity() to check identity of
> two sequence, which is not implementable in plain XSLT or
> XPath).  If yes, two questions:
> 
>     - what could be the default comparator?
> 
>     - does the arity of the comparator have to be always 2,
>       as it will be called once for each pair of argument,
>       or 2*(arity of the memoised function), as it will be
>       called only once for each memoised value?
> 
> > Also, developers could have a flexible definition, so that
> > memberwise comparison could be used for sequences up to,
> > let's say, ten items and reference (ID) comparison will be
> > used for comparing longer sequences.  This treshold can
> > even be determined dynamically depending on the speed of
> > execution.
> 
>   IMHO, it is a bad idea, as this could result in different
> results when arguments are sequences of different size.  But
> if it is needed, having the ability to set the comparator
> let the developer the ability to get it.
> 
> > This is the way to achieve maximum effect of memoisation
> > without the harm (that would result for long sequence
> > arguments) of imposing strict memberwise comparison.
> 
> > Think of developers as often clever people that are
> > capable of making the right decision in a particular
> > situation.
> 
>   I completely agree.  Tools have to be designed to minimize
> the possibility of writing bad things, default values have
> to be well-choosed, but the developer always has to get the
> ability to express what he wants.  IMHO.
> 
>   Regards,
> 
> --drkm
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 	
> 
> 	
> 		
>
___________________________________________________________________________
> 
> Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son
> interface révolutionnaire.
> http://fr.mail.yahoo.com
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com