Re: Extension candidates

Dimitre Novatchev wrote:

  Dimitre,

  Thanks for this detailed response.

> I think we have basically the same understanding, with only one
> exception.

  Yes, I think so.  But I think this exception is an important point.

>     <xsl:variable name="seq3" select="ex:sequence((1,2), 3)"/>

  That could be a convenience function that would create a ref for any
param that is not a singleton, but I don't think it could entirely
replace a function that create a reference.  Besides it requires
variable parameter lists (could be a portability problem I guess.)

> >    <xsl:sequence select="
> >        sum((ex:sequence-from-ref($seq[1]), $seq[2]))"/>

> The main difference is here. I would prefer to write this as:

>     <xsl:sequence select="
>         sum($seq[1], $seq[2]))"/>

  But that would then be impossible to manipulate references without
dereferencing them.  For example, the snippet you wrote above:

>     <xsl:variable name="ref" select="ex:sequence((1, 2))"/>
>     <xsl:variable name="seq" select="$ref, 3"/>

  If dereferencing was automatic, $seq would hold the plain sequence
(1, 2, 3).  I think (de)referencing should be explicit.  The point is
to be able to manipulate complex structures, so I think exposing
explicitly the structure is a feature, not a bug.

> This is to say: we do not sacrifice the good-looking XPath 2.0
> expression style by interspering deRef-s into an expression.

  I think using functions to (de)reference sequences/refs is not a
sacrifice to XPath style.  Actually, instead of having a function for
referencing and another for dereferencing, I like the Michael's idea
of returning an HOF as the result of referencing, while dereferencing
is achieved by calling the HOF (well, would be also a function, but
with a different, larger scope.)

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/