Re: xsl:function with optional parameters

On Thu, Sep 29, 2022 at 5:52 PM C. M. Sperberg-McQueen <
cmsmcq@blackmesatech.com> wrote:

>
>    (b) It is a declaration of two (related) functions, one of which is
>    my:f#1 and the other of which is my:f#2.  The xsl:function element in
>    question is in effect shorthand for
>
>     <!-- my:f#1 (just calls my:f#2 with the default value for p2) -->
>     <xsl:function name="my:f" as="...">
>        <xsl:param name="p1" as="node()"/>
>        <xsl:sequence select="my:f($p1, 42)"/>
>     </
>
>     <!-- my:f#2 -->
>     <xsl:function name="my:f" as="...">
>        <xsl:param name="p1" as="node()"/>
>        <xsl:param name="p2" as="xs:integer"/>
>        ...
>     </
>
>     I'll call the collection of functions thus declared a 'function
>     family'.
>


More simply, this is true:

      my:f#1 is identical to my:f#2(?, 42)

So yes,  these are indeed two different (but related) functions:  my:f2
and one of its many possible partial applications.


+1 for the whole message!

Thanks,
Dimitre



>
> I think your notes are assuming (a), which is perfectly reasonable.  But
> I wonder if (b) might be worth thinking about.  It would have the
> advantage that it would require not change (that I can see, at the
> moment) to the type system as it relates to functions.  At least, that
> looks like an advantage to me.
>
> If we look ahead to parameters with a cardinality of 'multiple', then
> (b) would mean that a single xsl:function element might declare an
> unbounded number of functions.  That would mean that implementors will
> need a way to avoid materializing all the instantations of such a
> function family and to materialize the ones they need when they need
> them.  But there too, the rules remain relatively straightforward, since
> every instantiation of the function familiy has the same fixed arity
> currently expected by our type system.
>
> > I think the simplest rule is that it's an error to have declarations D
> > and E, where the import precendence of D is higher than that of E, if
> > D's arity range includes part but not the whole of the arity range of
> > E.
>
> If it's a single function, that's probably simplest, yes.
>
> It does mean that while under today's style of handling such groups of
> related functions I could override my:f#1 without overriding my:f#2, I
> would not have that ability under the new dispensation.  (This does not
> matter to me in practice: since I normally want anything I write to be
> runnable under Saxon HE, I don't actually use packages even where it
> would make sense to use them.  That also means I lack useful experience
> in this part of the spec.)
>
> If we take approach (b), then I don't think we would need any change to
> the rules.  (That's not the same as claiming implementors won't need to
> change anything in the way they check the rules.)
>
> I see that the day has now reached its end without my getting back to
> this; I'll go ahead and send it, fragmentary though it is, for what it
> is worth.
>
> Michael
>
>
> --
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> http://blackmesatech.com
>
>