[Bug 10205] Issues in section 16.2 Basic higher-order functions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10205





--- Comment #3 from dnovatchev@gmail.com  2010-07-21 13:32:13 ---
> As we see from (9) and (10), it becomes very difficult and challenging to
> explain type constraints in natural language -- as we well know natural
> language is not a good tool for expressing exact relations and constraints, due
> to its ambiguities.
> If we have a means of expression that provide a strict and unambiguous way to
> express type constraints, we should try to use it instead of unrestricted
> natural language.

Some additional thoughts on this. If some language for expressing type
constraints is used in specifying the functions, then an implementation can
provide *static* type checking instead of raising runtime type errors.

for example:

fn:fold-left(f:add(), 0, $sequece-with-known-string-type)

Because the type constraints are expressed in the definition of fn:fold-left an
implementation can determine at compile-time (statically) that the above
expression violates the type constraint that the second argument of f:add() and
all items in $sequece-with-known-string-type must have the same type.

However, the arguments of f:add() must be numeric, not xs:string. The type
constraint is violated and this results in static type error.

In case type constraints were not expressed in the function definition, this
static error would be raised only as run time error -- too late and causing the
programmer (and end user!) to pay the price...

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 21 July 2010 13:32:16 UTC