[
https://issues.apache.org/jira/browse/JENA-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400828#comment-13400828
]
Andy Seaborne edited comment on JENA-270 at 6/25/12 8:56 PM:
-------------------------------------------------------------
There was no completed implementation in the codebase.
Re: eval ve evalSpecial.
evalSpecial is called before argument evaluation
eval (the common case) after
e.g. f(1+2)
eval will pass 3 to f , evalSpecial will pass the expresstion tree 1+2 to f,
not value 3.
Special forms look like functions but aren't. The evaluation order is not
"inside out".
IF is not a function - it is a special form.
IF(e1, e2, e3) does not e2 evaluated if e1 is false. e2 might be an error.
In the E_Call case, there are two points to evaluate args - in the CALL and
then in the evaluation of the function itself where the ARQ machinery does
argument to value. If things were more statically evaluated this would break if
done late as CALL does... but thimngs aren't, it doesn't break and it does work.
A side effect is that special forms will work in CALL (if they have a URI).
One oddity - the keyword functions do not work in CALL. We can't sensible do
anything about that.
CALL(concat, 'a', 'b') is a parse error.
CALL(fn:concat, 'a', 'b') works.
was (Author: andy.seaborne):
There was no completed implementation in the codebase.
Re: eval ve evalSpecial.
evalSpecial is called before argument evaluation
eval (the regular case after)
e.g. f(1+2)
eval will see f(3), evalSpecial will f( 1+2 ) wheer 1+2 is an expression tree,
not the value 3.
Special forms look like functions but aren't. The evaluation order is not
"inside out".
IF is not a function - it is a special form.
IF(e1, e2, e3) does not e2 evaluated if e1 is false. e2 might be an error.
In the E_Call case, there are two points to evaluate args - in the CALL and
then in the evaluation of the function itself where the ARQ machinery does
argument to value. If things were more statically evaluated this would break if
done late as currently (CALL does it's work in evalSpecial)... but it's not and
it doesn't.
A side effect is that special forms will work in eval (if they have a URI).
One odditiy - the keyword function do nto work in CALL.
CALL(concat, 'a', 'b') is a parse error.
CALL(fn:concat, 'a', 'b') works.
> Support dynamic function invocation in ARQ
> ------------------------------------------
>
> Key: JENA-270
> URL: https://issues.apache.org/jira/browse/JENA-270
> Project: Apache Jena
> Issue Type: New Feature
> Components: ARQ
> Affects Versions: ARQ 2.9.2
> Reporter: Rob Vesse
> Assignee: Rob Vesse
> Labels: call, dynamic, functions, sparql
> Fix For: ARQ 2.9.2
>
>
> Per my suggestion to the SPARQL Working Group I am proposing a new built in
> CALL() which can be used in SPARQL queries for dynamic function invocation.
> CALL with no argument returns null
> CALL with some arguments evaluates the first argument, sees if the result is
> a URI (if not errors) and if so tries to generate a function from it and
> invoke it with the arguments to that invocation being the remaining arguments
> to CALL
> I have implemented a prototype implementation of this in the ARQ language
> which I have committed to Trunk, others with more knowledge of expression and
> function evaluation in ARQ may have suggestions on how to improve the
> implementation
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
