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

From: Alexandr Savinov <>
Date: Wed, 22 Jun 2005 18:15:37 +0200
Message-ID: <42b98eaf$>

vc schrieb:
> 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.

As far as I understood it, 'return' marks some information that becomes a persistent part of each record and depends in the instance variables in the context of this query. For example, in SQL we might express it as follows:

select t.x + t.y from mytable t

Here x+y is a new field with the following properties:

- it is computed using the current record(s)
- the computations can be potentially complex and require nested calls
- computations may well involve nessted queries

In Daplex we would write:

return( x(t) + y(t) );

(Again, I am not an expert in Daplex, so may be I am wrong.)

Of course, in any good query language we need to have also transient variables which are computed for each record(s) but are not stored. They are used for intermediate values. (I do not know how it can be done in SQL.) In COM we can define in each context local variables and mark some of them as persistent, which means that their content will be stored along with each record of new collection being built. One important feature is that external contexts of queries are visible from internal (nested) queries. And the new computed fields are then a part of new result sets with their own field names that can be used in other queries. In addition to defining instance variables visible from nested queries (internal contexts) we can define our collections which also will be visible.

Received on Wed Jun 22 2005 - 18:15:37 CEST

Original text of this message