[Xpath-ng] Proposal for definition of values/lists

[Joe English]

A good criterion for designing type conversion rules is that
they should commute.  For instance, the result of converting a
string to a number and then to a boolean should be the same as
converting a string to a boolean directly.   More generally,
you want T2->T3(T1->T2(x)) = T1->T3(x) for all types T1,
T2 and T3.

For example, the following rules aren't commutative:

    any->number(x) =
    	x,			if x is a number
	bool->number(x)		if x is a boolean
	list->number(x)		if x is a list

    list->number(l) =
    	any->number(first(l)), 	if l nonempty
	NaN,			if l empty

    list->bool(l) 	= length(l) != 0

    number->bool(n)	= n != 0
    bool->number(b)	= if b then 1 else 0

since

	number->bool(list->number([0]))
    =	number->bool(0)
    =	false

but
	list->bool([0])
    =   length([0]) != 0
    = 	1 != 0
    =	true


Defining list->number as

	list->number(l)	= length(l)

would make them commute.


Another good criterion is that converting from type T1
to type T2 and back again should be idempotent.  That is,
if

	T2->T1(T1->T2( x )) = y,
then
	T2->T1(T1->T2( y )) = y.

Preferably T2->T1(T1->T2(x)) = x for _all_ x, but that isn't
always possible.

The rules above for converting between numbers and booleans
meet this criterion.  But, if we take

	list->number(l) = length(l)

then there really isn't a good definition of number->list
that would make it idempotent.  You could define
number->list(n) = a list containing N copies of the empty
list (or any other value), but that's not a very useful
definition.

I have no idea if we can come up with a set of
conversion rules that are backwards-compatible with
XPath 1.0, and meet these criteria, but it's something
worth considering.  IMO, if the conversion rules *don't*
commute, they shouldn't be automatic.



--Joe English

  jenglish at flightlab.com