<div dir="ltr">I see what you're aiming at. But, in general, you can take an imperative language and produce a declarative subset of such a language. The obvious benefits there is that you don't have a syntactic or semantic mismatch between your declarative islands and the imperative sea of code around them. Declaring a function, for example, would be the same, it's just that if you want it to be pure, then you have to avoid leaking state changes or referencing any non-pure functions (possibly with some keyword to explicitly enforce these restrictions). <div><br></div><div>So, for example, imagine that I take <a href="https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview#working-with-syntax">Roslyn</a>, and use it to dynamically translate C# methods attributed with [Query] to equivalent XQuery code, transparently to the user. Obviously, they'd be limited with respect to the features of the language they are able to use in such methods, but it's much easier to explain the limitations than it is to explain the whole new syntax (and semantics, in some cases). I'm pretty sure that I could have a very reasonable 1:1 mapping from such a subset to the entirety of XQuery, actually, though some of it would probably not be quite as pretty.<br><div><br></div><div>Also, correct me if I'm wrong, but it would seem that imperative patterns (variable assignments etc) can be optimized perfectly well so long as they're constrained (e.g. if the variable is local and no aliases are ever leaked). Basically, so long as you can clearly contain state changes, you can rewrite the whole thing as a purely functional monad, and that can be analyzed and optimized same as any other declarative data flow.</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 4:32 PM, daniela florescu <span dir="ltr"><<a href="mailto:dflorescu@me.com" target="_blank">dflorescu@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> I'm curious as to what exactly you believe to be features that are necessary to semi-structured data that are unique to XQuery. I've looked at the posts that you've linked to, and e.g. conditionals/typeswitches, functions and recursive functions, and try/catch, are there in pretty much any imperative language with sequence comprehensions,<br>
<br>
</span>Pavel,<br>
<br>
you ignored one of the FIRST things I put there for a data processing language: the necessity to be FUNCTIONAL in nature.<br>
(aka, 90%+ functional without side effects)<br>
<br>
The characteristic of being “functional”  is a NECESSITY for being able to do data flow analysis, aka the ability for the compiler to<br>
know automatically what operations will be applied on each piece of data, and what data is being given as input to each operation.<br>
<br>
Data flow analysis is a NECESSITY for optimization.<br>
<br>
Optimization is a NECESSITY for data processing for large volumes of data.<br>
<br>
=====<br>
<br>
C# with select-from-where is nearly not as optimizable as XQuery with a scripting extension (as Zorba used to have it for example).<br>
<br>
After 5 assignments you lost track of where the data came from and where the data goes, and which data changed where,<br>
and what indexes need automatic updates.<br>
<br>
You lost optimizability and logical/physical data independence.<br>
<br>
That’s all.<br>
<br>
It’s a trade-off.<br>
<br>
Best regards<br>
Dana<br>
<br>
<br>
</blockquote></div><br></div>