[xquery-talk] Sequence comprehension WAS: SQL vs. XQuery (aka FOR vs FROM and RETURn vs. SELECT)

[Pavel Minaev]

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).

So, for example, imagine that I take Roslyn
<https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview#working-with-syntax>,
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.

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.



On Tue, Jun 23, 2015 at 4:32 PM, daniela florescu <dflorescu at me.com> wrote:

> >
> > 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,
>
> Pavel,
>
> you ignored one of the FIRST things I put there for a data processing
> language: the necessity to be FUNCTIONAL in nature.
> (aka, 90%+ functional without side effects)
>
> The characteristic of being “functional”  is a NECESSITY for being able to
> do data flow analysis, aka the ability for the compiler to
> know automatically what operations will be applied on each piece of data,
> and what data is being given as input to each operation.
>
> Data flow analysis is a NECESSITY for optimization.
>
> Optimization is a NECESSITY for data processing for large volumes of data.
>
> =====
>
> C# with select-from-where is nearly not as optimizable as XQuery with a
> scripting extension (as Zorba used to have it for example).
>
> After 5 assignments you lost track of where the data came from and where
> the data goes, and which data changed where,
> and what indexes need automatic updates.
>
> You lost optimizability and logical/physical data independence.
>
> That’s all.
>
> It’s a trade-off.
>
> Best regards
> Dana
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150623/57093178/attachment.html>