On Tue, 4 Jul 2017 at 23:57 Chris Travers chris.trav...@gmail.com <http://mailto:chris.trav...@gmail.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
