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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

            Bug ID: 26799
           Summary: [XP31] operator namespace, for compatibility and for
                    use in higher order functions
           Product: XPath / XQuery / XSLT
           Version: Member-only Editors Drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: XPath 3.1
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

Currently, the text under 1.2 Namespaces and prefixes, under the last bullet
point, says the following about operators:

<quote>
These functions are not available directly to users, and there is no
requirement that implementations should actually provide these functions.
</quote>

With the advent of higher order functions, it seems to make sense to allow
these "virtual" operator functions to be made available to end users. This can,
of course, be an implementation dependent feature.

The text above does not necessarily discourage implementers to provide such
functions, nor does it encourage it, but, other than other namespaces that are
not specifically bound to functions (like the output namespace and the error
namespace), the operator namespace is not defined.

I would propose to make this namespace explicit. For implementers that (want
to) provide such functions, i.e. for use with higher order functions or certain
types of dynamic programming, it would be nice if the namespace used for the
"op" prefix is the same for all of them.

A candidate namespace that comes to mind is
http://www.w3.org/2005/xpath-operators. Or alternatively, the standard function
namespace.

I think, if the WG considers such change, that the impact is minimal. It might
suffice to just mention the namespace and a sentence like "implementers that do
disclose these functions directly to end users, should use the namespace xxxx".

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

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Michael Kay <[hidden email]> ---
This has been requested and rejected before, though I'm afraid I can't
immediately find the link.

The main objection to doing it, I think, is that the functions were never
designed for this purpose. If you consider using one of the boolean functions
that does comparisons, for example, as an argument to fn:filter(), you quickly
find that you need le, ge, gt, and ne variants of the function as well as
equals() and less-than() variants; and for strings, the compare() function is
useless because it doesn't return a boolean. If you look at the arithmetic
functions, things like op:multiply have a precondition that the two arguments
are the same primitive type, but they define no error condition when they
aren't, because they expect the caller to have taken care of this (by applying
numeric promotion rules to "equalize" the arguments). So the whole library
would need to be re-designed to make it usable.

A second objection is that a large number of tests would need to be written: we
don't have the resources to do this.

I do think it would be nice if there were a more concise way of expressing a
function such as

declare function($x, $y) {$x + $y}

Rather than using a built-in name op:numeric-add#2 for this function, I think a
much more useful enhancement would be to provide a concise syntax for inline
functions, along the lines of Scala and other modern functional programming
languages. For example

λ{$1 + $2}

where the presence of $1 and $2 both declare the argument and indicate how it
will be used. The construct F{$1 + $2} is more concise than op:numeric-add#2,
and it is also far more general. For example consider

sort(//employee, λ{$1!@salary})

I chose λ, of course, so we could have a boke-shed argument about the concrete
syntax. (It's a lambda, by the way, in case Bugzilla ever repeats its old trick
of throwing away non-ascii characters).

--
You are receiving this mail because:
You are the QA Contact for the bug.
Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

--- Comment #2 from Abel Braaksma <[hidden email]> ---
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.

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

--- Comment #3 from Jonathan Robie <[hidden email]> ---
We should at least be clear whether exposing these operators is permitted or
not.  "No requirement" seems to imply that it is permitted, but I would rather
have a clear statement.

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

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

--- Comment #4 from Michael Kay <[hidden email]> ---
There's nothing to stop you having a library of functions in a namespace of
your own choosing whose local names are the same as, or vaguely similar to, the
functions in the op: pseudo-namespace. You can have any library of functions in
any namespace you like; it's not something we could possibly ban.

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

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

Jonathan Robie <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Jonathan Robie <[hidden email]> ---
(In reply to Abel Braaksma from comment #0)
> Currently, the text under 1.2 Namespaces and prefixes, under the last bullet
> point, says the following about operators:
>
> <quote>
> These functions are not available directly to users, and there is no
> requirement that implementations should actually provide these functions.
> </quote>

I think we answer this question in the next sentence:

<quote>
These functions are not available directly to users, and there is no
requirement that implementations should actually provide these functions. For
this reason, no namespace is associated with the op prefix.
</quote>

These operators are not designed as a library for higher order functions.  If
we wanted to do that, more work is needed. Implementations can provide their
own function libraries for this purpose.

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