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

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





--- Comment #1 from Michael Kay <mike@saxonica.com>  2010-07-20 21:31:51 ---
Provisional (personal) response:

(1) is editorial, I'll see what I can do. (The whole idea of classifying
functions into sections is really rather a mess.)

(2) editorial, yes, seems a reasonable suggestion.

(3) (a) (substantive) on finding a better name for the function: please make a
suggestion, and the WG can take a vote on it. (b) (editorial) On explaining
what the function does, I prefer a clear statement of the rules supplemented by
notes and examples, and I think the section currently achieves that. Perhaps
they could be expanded.

(4) (editorial) I agree with the comment; although one can deduce the
possibility of an error from the way the function is specified, it would be
useful to draw this out separately.

(5) (editorial) I agree with the comment.

(6) (editorial) Agreed, although one can deduce the order of results from the
specification it would be useful to draw it out separately.

(7) (editorial) Technically you're right that this information is redundant,
but I still think it's useful as many readers are still new to higher order
functions and our notation for them. I propose to rephrase it to make it clear
that it's redundant, e.g. "A consequence of the function signature is..."

(8, 11) (editorial) Thanks for the pointer. I agree that these two functions
need better descriptions, and better guidance on how they differ, and I'm
grateful for any help in improving the description. Though of course, the spec
mustn't turn into a tutorial on functional programming.

(9, 10) (editorial?) I can see what you're saying here, but I think it reflects
a misunderstanding. The $zero referred to in the error description is the value
of the second argument supplied by the caller of fn:fold-left(). There is only
one such value. It's not a reference to the values passed on the internal
recursive calls in the reference implementation of the function. I'll see if I
can find some way to avoid this confusion.

(12) (editorial). I can see the value of a notation like the one you are
proposing. It could be applied to large numbers of other functions where there
are constraints affecting the relationships of the types of different arguments
and/or the type of the result. I think it would require some effort to define
the semantics of such a notation with sufficient precision, and then to use it
uniformly across the whole spec. There's a danger of trying to replicate some
of the work that was previously done in the formal semantics. I think this
needs WG discussion and a more complete proposal. Meanwhile I think it's better
to use English prose to express the constraints.

-- 
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 Tuesday, 20 July 2010 21:31:53 UTC