Hi Graydon,
Replying to the list for posterity. I hope you don’t mind.
When you dynamically evaluate an expression (xquery:eval(), job:eval(), …), you start with the default values of the static context [1]. Nothing of the XQuery module from which you evaluate the expression is known (unless supplied by binding, but ordinary function declarations are not amenable to binding), therefore no risk of circularity.
As stated in the table in [1], you can use module import [2] to augment this clean slate. In particular the module’s function declarations/signatures will be available then. If you don’t want the dynamically evaluated expression to import the whole module, you can store functions into variables and supply these variables to the evaluation through bindings. Haven’t tried it yet.
Gerrit
[1] https://www.w3.org/TR/xquery-31/#id-xq-static-context-components [2] https://www.w3.org/TR/xquery-31/#id-module-import
On 16.08.2023 14:02, Graydon Saunders wrote:
Thank you for the specific example!
I'm croggled that works without giving me a circular reference error of some kind, but it does work.
Much appreciated!
Graydon
On Tue, Aug 15, 2023 at 11:34 PM <gerrit.imsieke@le-tex.de mailto:gerrit.imsieke@le-tex.de> wrote:
You can import the library module in the evaluated expression. Example: https://github.com/transpect/control-backend/blob/main/webapp/control-backend.xqm#L60 <https://github.com/transpect/control-backend/blob/main/webapp/control-backend.xqm#L60> Gerrit Sent from MailDroid <https://goo.gl/ODgwBb> -----Original Message----- From: Graydon Saunders <graydonish@gmail.com <mailto:graydonish@gmail.com>> To: BaseX <BaseX-Talk@mailman.uni-konstanz.de <mailto:BaseX-Talk@mailman.uni-konstanz.de>> Sent: Wed, 16 Aug 2023 4:42 Subject: [basex-talk] mapping functions Hello -- I have various databases that will be run through the same code after their contents is regularized. So the only different function is the one used for regularization. This can be handled by writing a wrapper function and passing in a label to say which function to use, but I was wondering if there's a way to do it in the configuration map directly. The configuration map exists as a text file and gets run through xquery:eval() at the start of the process. declare namespace abc='http://some/uri <http://some/uri>'; 'regularizationFunction': map { 'typeOne': abc:regularizationOne#1, 'typeTwo': abc:regularizationTwo#1 } doesn't work, because the abc functions aren't known at evaluation time. These functions are defined in the library module that's evaluating the configuration file but xquery:eval() doesn't know that. I don't see a way to use bindings to get around this. Is there a way to map a locally-defined function reference so xquery:eval() will recognize it? thanks! Graydon -- Graydon Saunders | graydonish@fastmail.com <mailto:graydonish@fastmail.com> Þæs oferéode, ðisses swá mæg. -- Deor ("That passed, so may this.")
On Thu, Aug 17, 2023 at 02:07:52AM +0200, Imsieke, Gerrit, le-tex scripsit:
Hi Graydon,
Hi Gerrit --
Replying to the list for posterity. I hope you don’t mind.
Not in the slightest.
When you dynamically evaluate an expression (xquery:eval(), job:eval(), …), you start with the default values of the static context [1]. Nothing of the XQuery module from which you evaluate the expression is known (unless supplied by binding, but ordinary function declarations are not amenable to binding), therefore no risk of circularity.
That makes sense; xquery:eval() has only the supplied static context.
As stated in the table in [1], you can use module import [2] to augment this clean slate. In particular the module’s function declarations/signatures will be available then. If you don’t want the dynamically evaluated expression to import the whole module, you can store functions into variables and supply these variables to the evaluation through bindings. Haven’t tried it yet.
The thing that has me croggled is that the dynamically evaluated expression is in the module being imported, where it is bound to a public variable in the module namespace.
https://www.w3.org/TR/xquery-31/#id-module-import does say that public variable declaration are included in what's imported.
I'm pleased that it works, but I wouldn't claim I understand how it works.
My (somewhat reduced) library module starts off as:
module namespace xc = "http://example.com/stuff";
(: load the list of parameters:) declare variable $xc:paramsFile external; declare variable $xc:params as map(*) := file:read-text($xc:paramsFile) => xquery:eval();
followed by various functions, and the parameters start off:
import module namespace xc="http://example.com/stuff" at "library.xqm"; map { (: many parameters :) }
While I think I get that the xquery:eval() only has the static context provided to it, and by default has nothing, why the xquery:eval() doesn't try to evaluate the variable again when the library module is provided as context isn't at all clear to me. I suppose there has to be something in the import process that avoids infinite loops.
Thanks! Graydon
On 17.08.2023 02:40, Graydon wrote:
The thing that has me croggled is that the dynamically evaluated expression is in the module being imported, where it is bound to a public variable in the module namespace.
That may be true, but if you are referring to it in the evaluated expression by its signature, this signature won’t be known – unless you import the module in the expression.
'typeOne': abc:regularizationOne#1
On Thu, Aug 17, 2023 at 02:46:24AM +0200, Imsieke, Gerrit, le-tex scripsit:
On 17.08.2023 02:40, Graydon wrote:
The thing that has me croggled is that the dynamically evaluated expression is in the module being imported, where it is bound to a public variable in the module namespace.
That may be true, but if you are referring to it in the evaluated expression by its signature, this signature won’t be known – unless you import the module in the expression.
Which implies that perhaps at import time in xquery:eval ONLY those variables and functions which are referenced in the evaluated expression are resolved from the imported module, which explains why the variable (which isn't referenced in the eval) doesn't cause an infinite loop.
Thank you! I feel less confused.
-- Graydon
basex-talk@mailman.uni-konstanz.de
-
Graydon -
Imsieke, Gerrit, le-tex