Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

Jan Hidders wrote:
> VC wrote:
> However, in XQuery, the 'return' is just a 'print' (or an
> > assignment) in disguise. This 'return' thingy, among others, is what makes
> > XQuery 'impure'. Just think about what would be a definition for a function
> > called 'return' in a pure FL ? What kind of mapping would it describe ?
>
> The 'return' does not represent a function, but is part of the the
> for-expression and as such is just a separator that marks where the
> return-clause begins.

It's not good enough. Assuming as you say it's just a 'separator' for the 'return-clause', what is the return clause ? Is it a function in a purportedly purely functional language ? Is it a value ? If not, what is it ?

But let's not sidetrack to XQuery, rather tell me what 'print' is in Daplex without drawing analogies with XQuery. Just give a definition if you please.

> A for expression is simply another notation for
> the monad comprehension,

If so, please show how you would build the 'for expression' out of functions in Daplex using monadic notation. And while you are at it, please do the same for 'print'.

More importantly, you admit implicitely that the 'for' ... 'print' fragment is indeed imperative by appealing to the monad notion which is used in pure functional languages in order to encapsulate non-pure side effects, states, IO and such. The problem is you cannot claim that Daplex is pure declarative, neither is ML by the way, due to the fact that one cannot reformulate the imperative expression above in a declarative way unless somehow you'll manage to do so.

> Or, to explain it in another
> way, the 'return' keyword plays ruoghly the same role as the 'select'
> and 'from' keyword in SQL; they are simply markers that indicate where
> certain subexpressions begin. If I would apply your reasoning there then
> I would have to ask what the mappings are for 'select', 'from' and
> 'where', and if those would not exist we would have to conclude that SQL
> (and also the tuple calculus) are actually not declarative.

But they do exist as I mentioned in my earlier response to Alexander. E.g.

select name, age from person where city='London'

is nothing more but a relational algebra expression composing two functions:

PROJECTION(SELECTION(person, city='London'), name, age).

It may be more natural for some to think about the expression in an imperative way (I cannot imagine why though) although its declarative interpretation as a composition of two functions is trivial.

>
> >>>>If your above example would be written in ML it would look roughly
> >>>>the same.
> >>>
> >>>I am sure you know that ML is *not* a pure FL and the fragment in
> >>>question would be imperative there too thanks to 'print' or whatever
> >>>ML uses.
> >>
> >>From the way I used it you might have guessed that I meant pure ML. The
> >>print statement is only there to say that you return a concatenation of
> >>values and that you can do in pure ML.
> >
> > See above. A 'print', whether it's called 'return' in XQuery, or 'print'
> > in Daplex, or 'write', I believe, in ML is an imperative feature whichever
> > way you look at it.
>
> No, like I said, I don't need any procedural feature from ML for that.

Show how you'd output a character in ML in a non-imperative way.

> You can also do it in Haskell, or pretty much any other pure functional
> programming language that is based on monad comprehension or list
> comprehension.

Yes, you can encapsulate the non-pure part in Haskell but not in Daplex or ML.

vc
>
> -- Jan Hidders
Received on Wed Jun 22 2005 - 17:39:32 CEST