Re: [xsl] getting type information in xslt 2.0

Subject: Re: [xsl] getting type information in xslt 2.0
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Tue, 24 Oct 2006 20:09:16 -0700
David,
To continue, taking leaving type-checking aside, the examples you
provided will not run in the case of a function that has 2 or more
arguments that must be sequences.

For example:

f:subsequence(1,2,3,4,5,2,3)

Is this the function overload to obtain the subsequence of (1,2,3,4,5)
starting at the second item and with length 3 ?

Or is this the overload that creates the partial application with one
argument (the whole sequence) ?

Or is this the overload that creates the partial application with two
arguments (the sequence (1,2,3,4,5,2) and the starting index 3 ?


Also, an argument to a function may be a list of functions (each of which may be a partial application).

How to encode this argument without serializing to xml?


-- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play




On 10/24/06, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
On 10/24/06, David Carlisle <davidc@xxxxxxxxx> wrote:
>
> > Very briefly, all the functions in your example are typeless.
>
> Not sure what you mean by typeless in this context?
>
> The actual examples certainly have holes in them, it was just some very
> late night doodling in response to you "how" question:-) But I'm not
> sure that you ever _have_ to save data in xslt2 as element content do
> you (which is I think where you are losing type information) unless you
> need to serialise to an XML output. If you can hold the data in memory
> as XPath sequences, you should be able to retain type information?
>
> Oh do you mean you need to define separate functions for separate types
> rather than rely, as I did, on the inbuilt polymorphism of the build in
> F&O functions and operators? In that case yes you do need to get type
> information but in that case it's not to do with the requirments of
> partial function application, just getting round the limitation that
> XPath2 signatures for user-functions have to be distinguished by arity
> not type.
>
> David


Actually. it is quite clear.


If a function has two arguments, the first an xs:date and the second
an xs:integer,

and the function that creates the partial application accepts one
argument, it must accept only an xs:date -- not an argument of another
type.

Failing to do so will postpone the error message until "late-runtime"
instead of compile time and this is too-much to lose.

I will write more on this when I have more time -- in the meantime
maybe both Colin and Florent could explain.

The main thing is FXSL supports static type-checking of arguments (and
function return types).  A partial application is implemented as a
structure (xml element) encoding the function with N arguments and k <
N argument values. It may be interpreted (invoked) at any time in the
future bu providing some or all of the remaining arguments.

Any time a new argument value is provided, it must be of the type the
original function accepts for this (Kth) argument -- this must be
checked at the time this arg. value is provided -- not at the final
when the original function is invoked with all N argument values.

All this requires that a partial application knows the number and
types of all the arguments of the original function.

--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play

Current Thread