[Bug 26958] On not precluding updates in XQuery 3.0

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26958

--- Comment #1 from Jonathan Robie <jonathan.robie@gmail.com> ---
Note that XQuery Update is not functional, and does not have referential
transparency. 

As the Haskell Wiki points out, mutable state and referential transparency do
not easily mix:

http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue3/Functional_Programming_vs_Object_Oriented_Programming

<quote>
A Haskell program is like an OO program where every object is immutable. All
you can do is construct new objects (this makes the term "data constructor"
seem more relevant). When you want to change an object, you make a copy of it
and replace just the bits you want to change. This isn't as expensive as it
sounds, due to the extensive data sharing that immutable objects make possible
(the bits of the object that aren't modified aren't copied; you just retain the
references to the originals). Also, you avoid any aliasing problems, which is a
potential cause of errors in programs that use mutable state.

Haskell also has no notion of object identity. When you construct a value (an
instance of a type), the constructor creates a box (pointer) around the value.
When you pass this value to functions, you pass the box, so it could be
considered a reference. But Haskell has no way of saying "are these the same
object?" i.e. are these the same box? All it has is an equality operator (==),
which is only concerned with the box contents.

Object systems do have a notion of object identity. This seems to go
hand-in-hand with mutable state, because the questions "are these the same
object" and "are these the same value" are both relevant.

When you have immutable objects, the question "are these the same object" seems
a bit pointless, whereas "are these the same value" is always relevant. "Are
these the same object" isn't interesting because the behaviour of your program
can't vary with the answer, whereas with mutable state, the behaviour of your
program can vary with the answer (this is aliasing).

If you have mutable state then you can't guarantee referential transparency.
That's the big deal with Haskell: no mutable state means you can guarantee
referential transparency, and that guarantee is a Very Good Thing (all sorts of
benefits flow from this).
</quote>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 2 October 2014 22:40:51 UTC