http://www.w3.org/Bugs/Public/show_bug.cgi?id=4841 ------- Comment #15 from jmdyck@ibiblio.org 2007-10-31 02:28 ------- (In reply to comment #12) > The changes proposed fail to provide a catch all case, and so the type is not > defined for an argument with quantifier ? for example. Whoops again! You're right, the four moved rules do not cover all cases. > The typing rules could be made simpler (without changing the result) by just > applying the following rules: > > statEnv |- QName of func expands to (FN-URI,"item-at") > statEnv |- Expr : Type quantifier(Type) in { 1, + } > -------------------------------------------------------- > statEnv |- QName(Expr, 1) : prime(Type) > > statEnv |- QName of func expands to (FN-URI,"item-at") > statEnv |- Expr : Type > -------------------------------------------------------- > statEnv |- QName(Expr1, Expr2) : prime(Type) ? An excellent simplification. (I had to do some quantifier-arithmetic to convince myself that, in all cases, the resulting type was the same as currently inferred, but I agree that it is.) > Additionally, the static typing could be improved with the following rule: > statEnv |- QName of func expands to (FN-URI,"item-at") > statEnv |- Expr : Type quantifier(Type) in { 1, + } > -------------------------------------------------------- > statEnv |- QName(Expr1, $last) : prime(Type) In fact, fn:subsequence used to have such a rule, but it was removed in the 20050915 WD and hasn't returned. (See Bug 1728 Comment #7.) My impression is that the removal was a mistake, and I think the rule should be reinstated (for item-at). However, that won't be happening as part of this issue, and probably not as an erratum either.Received on Wednesday, 31 October 2007 02:28:35 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:20 UTC