[Bug 26799] [XP31] operator namespace, for compatibility and for use in higher order functions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I understand your objections, though my point was not necessarily to make it a
normative part of the spec, it was more about the sentence:

> and there is no requirement that implementations should 
> actually provide these functions

about which I understood that it is not forbidden (MUST NOT) to do so. If it is
not forbidden, it seems to make sense to at least provide a namespace for it.
Even in the event that it is forbidden, it would still make sense to provide a
namespace for it (as we do for "err" and "output").

The other half or your answer is far more interesting though. I remember that
we discussed a possible syntax for lambda style functions briefly during a
joined F2F in Prague, but it was dismissed at the time (probably as too late in
the game).

I like the suggestion of numbered arguments, alternatively we can think of the
arrow notation (but, as you said, a notation discussion should probably be done
after, and if, such proposal is considered).

My idea of arrow notation:

$a => {abs($a + 2)}          (: one arg :)
($b, $c) => {$b lt $c}       (: multi args :)
() => {system-property('x')} (: no args :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 16 September 2014 15:17:18 UTC