W3C home > Mailing lists > Public > public-qt-comments@w3.org > October 2013

[Bug 23643] Convenient operator for transform expressions

From: <bugzilla@jessica.w3.org>
Date: Mon, 28 Oct 2013 11:37:25 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-23643-523-Yd26s4B76Z@http.www.w3.org/Bugs/Public/>

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
                 CC|                            |mike@saxonica.com

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
We (or the user) could define a function 

modify($n as node(), $f as updating function($n as node())) {
  copy $m := $n
  modify $f($m)
  return $m

and then you could write

for $e in //item[@status ne 'up-to-date']
return element updated { modify($e, function($n) {insert node <sub/> into $n})

This would be even more attractive if we had a terser syntax for inline
functions. In FtanSkrit I used 

{$1 + $2}

for a function that adds its two arguments (i.e. our "function ($n, $m) {$n +
$m}"). We've decided to use a bare "{" for maps, but we could still go with
something like {= $1 + $2 }, the leading '=' being familiar to spreadsheet
users - or even just a leading '=' without the curlies:

for-each($seq, =($1 + 1))

and then Christian's example becomes

for $e in //item[@status ne 'up-to-date']
return element updated { modify($e, =insert node <sub/> into $1)}

I think we should be trying to build new capability by exploiting higher-order
functions wherever we can, in preference to inventing new higher-order

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 28 October 2013 11:37:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:54 UTC