[Bug 27098] New: possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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

[Bug 27098] New: possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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

            Bug ID: 27098
           Summary: possibility of functions to return multiple arguments
                    which can be used in the argumentlist of a
                    functioncall.
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Functions and Operators 3.1
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

I regularly build functions which return more than one result and where these
results need more processing. For example if I want a counter which runs along
in a hof:until-construction, but there are plenty more situations. I end up
building some sort of result-constructor-function which enfolds both result in
a single construction and using this function to return my functionrsult as a
single argument in a functioncall. In the calle function a need then to defold
the argument in its origional values. This is pretty cumbersome.

I wouldn't mind if a function could return a type of argumentset with the
possibility of moore than one argument, which can be used in the argumentlist
of a functioncall to an other (or perhaps the same) function.

I now use the following construction:

(: resultconstructorfunction :)
let $result.constructor :=
function( $a, $b, $c, ....){ function( $f) { $f( $a, $b, $c, .....)}}

(: returning multiple values from a function:)
declare function my_function
      ( $p1, $p2, ....)
      { .....
        return $result.constructor( $x, $y, $z, ....)
      } ;

(: using this result in a functioncall :)
$result( calledFunction( $u, ?, ?, ?, ....)

(: what I would like is: :)
calledFunction( $u, my_function( $q1, $q2, ....), ....)

Although laborious it works fine but only in case of the results of one
function in the argumentlist of the functioncall. If I need the results of more
functions in the argumentlist this construction doesn't work and than it really
get laborious.

The example shows on the other hand that xquery already contains some sort of
solution for this transmission of arguments.

The possibility of returning a argumentset with more than one argument as
functionresult which can be used within the argumentlist of an functioncall
would, in my opinion, result in more elegant and propably also faster code.

Rob Stapper.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 27098] possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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

--- Comment #1 from Michael Kay <[hidden email]> ---
This sounds like one of the use cases for maps, which are introduced in XPath
3.1. A function can return multiple results in a map, and the map can either be
passed to another function as a single argument value, or its components can be
passed in multiple arguments:

declare function f() {
  map{ x:23, y:34 }
}

declare function g($x, $y) {
  ...
}

let $f := f()
return g($f?x, $f?y)

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

Reply | Threaded
Open this post in threaded view
|

[Bug 27098] possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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=27098

--- Comment #2 from Rob <[hidden email]> ---
(In reply to Michael Kay from comment #1)

> This sounds like one of the use cases for maps, which are introduced in
> XPath 3.1. A function can return multiple results in a map, and the map can
> either be passed to another function as a single argument value, or its
> components can be passed in multiple arguments:
>
> declare function f() {
>   map{ x:23, y:34 }
> }
>
> declare function g($x, $y) {
>   ...
> }
>
> let $f := f()
> return g($f?x, $f?y)

Yes, indeed it does sounds like it but this solution only meets the
requirements halfway. The solution forces the use of a variable ( $f in this
case) and it doesn't allow functioncalls to be nested.

The result of function f() still has to be brought back (serialized) to the
program ( $f), there being splitup in its origional elements ($f?x and $f?y)
and individually being fed to function: g#2. This all could be done in the
background if function f()'s result could be interpreted as a sequence of
arguments within the call to function g#2.

I realize that this would have a significant impact on the internal
xquery-design and I probably wouldn't have mentioned it if it hadn't, to my
opinion, so much in common with the apply-request:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26585

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

Reply | Threaded
Open this post in threaded view
|

[Bug 27098] possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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=27098

--- Comment #3 from Michael Kay <[hidden email]> ---
>This all could be done in the background if function f()'s result could be interpreted as a sequence of arguments within the call to function g#2.

That is very difficult to achieve given that the number of arguments (arity) in
the function call to g is used when deciding which function is being called.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 27098] possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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=27098

--- Comment #4 from Rob <[hidden email]> ---
(In reply to Michael Kay from comment #3)
> >This all could be done in the background if function f()'s result could be interpreted as a sequence of arguments within the call to function g#2.
>
> That is very difficult to achieve given that the number of arguments (arity)
> in the function call to g is used when deciding which function is being
> called.

Yes, that will be an issue that has to be tackled then ;-). But hé, if it is
interesting enough for the xquery-language ...

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

[Bug 27098] possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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=27098

--- Comment #5 from Rob <[hidden email]> ---
Just came back from my run and I kept wandering what the actual fun is of the
arity of a function being part of its identification. Is that more interesting
than being able to nest functioncall to functions with more than one return
value?

An option could be, so both features could be implemented besides eache other,
to be able to overrule the arity calculated from the argumentlistsize with the
#<integer> notation in case of these nested functioncalls, f.e. g#2(f())

Just something that popped up while running.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 27098] possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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=27098

--- Comment #6 from Michael Kay <[hidden email]> ---
Making things "fun" and "interesting" are not criteria that the WG usually uses
to justify its design decisions. Perhaps they should be.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 27098] possibility of functions to return multiple arguments which can be used in the argumentlist of a functioncall.

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=27098

--- Comment #7 from Rob <[hidden email]> ---
I'm confident the WG will use the right criteria and I can reconcile myself in
whatever will be decided.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 27098] possibility of functions to return multiple results which can be used in the argumentlist of a functioncall.

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=27098

Jim Melton <[hidden email]> changed:

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

--- Comment #8 from Jim Melton <[hidden email]> ---
Many thanks for your suggestion.  After discussion, the WG decided at its
meeting on 2014-10-27 that is would not be feasible at this stage of
development to add this capability to XQuery.  Consequently, with regrets, we
must reject your suggested enhancement.  If you accept this decision, please
mark this bug as CLOSED.

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