There are probably two main justifications for not allowing function
arguments always to be cast to the required type. The first is error
checking - as the number of types increases, the risk increases of doing
a calculation that is different from the one the user actually intended.
The second is polymorphism. XPath 2.0 doesn't allow functions (as
distinct from operators) to be polymorphic, but some people would like
to keep the option open to allow it in future, and weak typing is not
really compatible with polymorphism.
I do not advocate weak typing. It is possible to avoid unnecessary explicit
casts/conversions with strong typing and still to support polymorphism to
the maximum extent possible.
In Haskell there are type classes. For example:
class Show a where
show :: a -> String
showsPrec :: Int -> a -> ShowS
showList :: [a] -> ShowS
This defines the class of all types that have a "show" method, which will
present an instance of the datatype to a string.
The type "shows" is a synonym for any function from String to String
type ShowS = String -> String
-- Minimal complete definition: show or showsPrec
show x = showsPrec 0 x ""
showsPrec _ x s = show x ++ s
showList [] = showString "[]"
showList (x:xs) = showChar '[' . shows x . showl xs
where showl [] = showChar ']'
showl (x:xs) = showChar ',' . shows x . showl xs
As can be seen, the "showList" method can produce the string representation
of any list of things whose type belongs to the Show class. This is the
direct (and really precise) Haskell analog to the XSLT/XPath concat()
function.
As we see, in a well-designed strongly typed language, functions like
concat() may be defined in such a way so that no explicit conversion of the
arguments will be required.
There are many other useful type classes:
Eq -- a class of datatypes that have the equality operator:
class Eq a where
(==), (/=) :: a -> a -> Bool
-- Minimal complete definition: (==) or (/=)
x == y = not (x/=y)
x /= y = not (x==y)
Ord -- a class of all datatypes that belong to Eq and also have a total
ordering relation defined:
class (Eq a) => Ord a where
compare :: a -> a -> Ordering
(<), (<=), (>=), (>) :: a -> a -> Bool
max, min :: a -> a -> a
-- Minimal complete definition: (<=) or compare
-- using compare can be more efficient for complex types
compare x y | x==y = EQ
| x<=y = LT
| otherwise = GT
x <= y = compare x y /= GT
x < y = compare x y == LT
x >= y = compare x y /= LT
x > y = compare x y == GT
max x y | x <= y = y
| otherwise = x
min x y | x <= y = x
| otherwise = y
Class Bounded
Class Num
etc.
This is a nice example how unnecessary casts/conversions can be avoided,
while still preserving and supporting polymorphism.
=====
Cheers,
Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
Most languages end up being a bit pragmatic about this, and XPath is no
different. In the latest draft, we changed all the functions that accept
or return URIs to use the xs:string type instead of xs:anyURI, because
it was simply too much of a pain to keep casting strings to URIs and
back (though Java makes you do just that). For numerics, we introduced a
set of promotion rules that allow arithmetic to mix the different
numeric types.
There would be no technical difficulty in defining concat(), like
string(), to take item() rather than xs:string as its argument type.
It's just a question of persuading people that it deserves to be treated
as a special case.
The place for such comments, of course, is the public-qt-comments list.
Michael Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list