Re: Imperative Query Languages

On Tue, 4 Jul 2017 at 23:57 Chris Travers chris(dot)travers(at)gmail(dot)com
<http://mailto:chris(dot)travers(at)gmail(dot)com> wrote:

I am curious where you see LINQ as starting at an imperative syntax.
>
The imperative integration is thin, I admit — it just the integration with
for loops.

Here's a good case that illustrates the problem I think. Suppose the
> following is understood imperatively:
>
> FOR x IN RANGE student
> SELECT WHERE x.age < 25
> PROJECT ALL(x), lock_if_possible(x.id)
>
> Now, lock_if_possible has side effects. If we understand this to be
> imperative, then we have no possibility of turning this into a declarative
> query because we are interested in the side effects. So you cannot say
> that this is equivalent to the SQL of
>
> SELECT *, lock_if_possible(id)
> FROM student
> WHERE age < 25
>
> The reason is that while the imperative version represents *one* valid
> interpretation of the declarative, there are other interpretations of the
> declarative that are not at all equivalent. The hoops we have to jump
> through to make this work in an imperative way in SQL are sometimes rather
> amusing.
>
What are some alternative interpretations of this query? Are you referring
to which rows are candidates for locking? Or the order of locking?

Kind Regards,

Jason

​