[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
On 10/24/06, David Carlisle <davidc@xxxxxxxxx> wrote:
Actually. it is quite clear.
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 07:45:54 -0700 |
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] getting type information , David Carlisle | Thread | Re: [xsl] getting type information , Dimitre Novatchev |
RE: [xsl] Camel case tokenizing, Michael Kay | Date | Re: [xsl] xinclude in XSLT[2], Frans Englich |
Month |