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

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.

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.

-- 
http://conceptoriented.com