3.1.2 Dynamic Context "some component of the dynamic context" s/context/environment/ ? dynEnv.funcDefn "The dynEnv.funcDefn environment component maps an expanded function name and parameter signature of the form "expanded-QName (Type1, ..., Typen)" to the remainder of the corresponding function definition." The domain of dynEnv.funcDefn should be the same as that of statEnv.funcType, i.e. (expanded-QName,arity). By including the parameter types in the domain, rather than simply the arity, you allow for functions with the same name and arity but different parameter types, which there is no need to do. This change would only affect a few premises in 4.1.5, 5.11, and 5.15. It would especially simplify 5.11 / Notation 3 / rule 4, which is currently broken (see Bug 1715). 'If the function is locally declared, the function definition is of the form "(Expr, Variable1,..., Variablen)", ...' I think it would make more sense if the Variables came before the Expr. (You have to bind the parameters before you can evaluate the body.)
The fix for this bug does not appear in the Recommendation of 23 January 2007. It will be considered for a future publication (either an Errata document or some possible future version of the specification).
(In reply to comment #0) > 3.1.2 Dynamic Context > > "some component of the dynamic context" > s/context/environment/ ? The FS appears to use "context" and "environment" more or less interchangeably. So, while the suggestion might be an improvement, it's not worth an erratum. I'll consider it for FS 1.1. > dynEnv.funcDefn > "The dynEnv.funcDefn environment component maps an expanded function name > and parameter signature of the form "expanded-QName (Type1, ..., Typen)" > to the remainder of the corresponding function definition." > The domain of dynEnv.funcDefn should be the same as that of > statEnv.funcType, i.e. (expanded-QName,arity). This proposal has been incorporated into the fix for FS erratum E006. The fix has been committed to the source files for the next edition of the FS document. > 'If the function is locally declared, the function definition is of the > form "(Expr, Variable1,..., Variablen)", ...' > I think it would make more sense if the Variables came before the Expr. > (You have to bind the parameters before you can evaluate the body.) Again, this might be an improvement, but it's not worth an erratum. I'll consider it for FS 1.1. Based on the outcome of the second item above, I'm marking this bug resolved-FIXED (with a "consider for 1.1" note in the Status Whiteboard), and then closing it.