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

From: Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be>
Date: Wed, 22 Jun 2005 19:08:36 GMT
Message-ID: <UGiue.127257$mY2.7061611@phobos.telenet-ops.be>

vc wrote:
> 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 ?

It is a part of the for expression, which is bascially expressing list comprehension.

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

The identity function. The print is only there to indicate that you produce a value, so you can simply translate it to the expression that produces that value if you makes sure that they are concatenated for each value that you iterate over. And that's of course exactly what list comprehension does.

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

Yes, but I don't need all that. Just list or set comprehension will do.

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

Sure. And the same exists for some list-comprehension calculi. Just look in the NRA/NRC literature I already pointed you to.

• Jan Hidders

Received on Wed Jun 22 2005 - 14:08:36 CDT