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

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





--- Comment #2 from dnovatchev@gmail.com  2010-07-21 02:49:52 ---
(In reply to comment #1)
> 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.)

Something that's more distinguishing (don't know if it's better):

"The following functions have a single argument that is a function item"

> (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. 

I have thought about a good name. My suggestion is:

  fn:remap

This is both short and close to "map", but at the same time shows that this
function is not completely a "map" -- it isn't isomorphic on the list-argument
and can significantly affect its shape, *re*structure it in the result.

So, "remap" can be thought of as an abbreviation of "restructuring-map".

The same observations and the same suggestion hold for fn:map-pairs, of course.

> (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.

I guess that just explaining the name "remap" will provide a perfect
description of the peculiarities of this function.

> (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.

Agreed.


> (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.

Agreed.

> (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..."

I agree with the proposed new text and I think it would be best to put this as
a "Note:" and not as an "Error condition" that is specific to this function.

> (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.

I would be glad if I can help. Agree that we are not producing a tutorial --
just short hints and maybe a link to more detailed material would suffice.

> (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.

This is the proposed implementation:

declare function fn:fold-left($f, $zero, $seq) {
  if (fn:empty($seq))
  then $zero
  else fn:fold-left($f, $f($zero, fn:head($seq)), fn:tail($seq))
};

for the internal call of fn:fold-left above, 

its $zero has value:

          $f($zero, fn:head($seq)) 

The error that is described happens on the internal call, and the error is for
this exactly call, and the reason is that the $zero argument to this call is
not of the type that is acceptable for the first argument of f().

I think that we both understand this.

I think that a more exact phrasing of the error condition that avoids this
issue is: 

"A type error occurs if the supplied function $f to the fold-left function or
to any of its internal recursive calls cannot be applied to two arguments,
where the first argument is the value of $zero and the second is the value of 
fn:head($seq), passed to that call."

Of course, all this phrazing would be unnecessary had we a notation as the
pseudocode given as example in (12).


> (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.

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 mens of expression that provide a strict and unambiguous way to
express type constraints, we should try to use it instead of unrestricted
natural language.

-- 
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 02:49:55 UTC