Re: Relation name = address?

It's probably a good idea to make sure you don't think of relation names as somehow special.

Taking one semantic view, it's normal to have a two level view of names, variables and the likes. The first layer is the environment, which is a function that maps from names to "denotable values". A denotable value is anything that can be identified by name in your language. The second layer is the store, which is a function that maps from locations to "storable values". For a variable, the denoted value for the name is a location in the store.

The two level setup is there to cope with several issues, principally aliasing (where two names can point to the same location - call-by-reference parameters, for example) and languages where the denotable values are not the same as the storable values - for example, in some languages records/structures are denotable values, but not directly storable values - only the components of the record/structure are actually stored.

If you can find a copy of David Harland's Polymorphic Programming Languages:Design & Implementation (Ellis Horwood, 1984), there is a quick and useful discussion of what he calls ontology diagrams of different languages that show how some differentiate between denotable & storable values.

The interesting question in language design is then: is a relation a denotable value which is not itself a storable value but the components
(tuples ? attributes ?) are stored, or a storable value in its own
right ? Then it all starts get fun (can you have an array of relations ? records/structures with relations as elements ? what would it mean to have a four dimensional array of relations ?) and if you haven't set the whole lot on a sound, solid foundation it'll all come crashing down about your ears in a horrible avalanche of special cases, exceptions, alternatives, etc etc etc ...

You then have to decide how you'll allow people to manipulate the data structures you've allowed them to create - for example, given the Pascal style ':=' operator, do you allow arbitrary expressions on the left hand side, so long as the expression results in a location ? e.g., would you allow

(if condition then variable1 else variable2) := (some other
expression);

If you do allow this, then it's reasonable to assume you would also allow

(select table_name_column from table_names where condition) := (some
relation);

(Preferably with nicer syntax than select ... from ... where though !)

So then you'd have to think about what would happen if the select on the left hand side returned multiple rows (do they all get set to the relation on the right hand side of the ':=' ? does the statement return a run time error ? what happens if the name returned by the select doesn't actually indicate a relation typed variable ? etc ?) The worst thing you can do is attempt to enforce some kind of aritrary restriction on the left hand side expression.

Aside : in language design, there are only three acceptable numbers :

0 - you can't
1 - you can, but exactly once
Infinity - you can, and as often as you like

The appearance of any other number is bad news. And even if you stick to the three acceptable numbers, you better have a sound rationale for why you chose the number you chose.

Language design is easy, eh ? And that's before you get *too* far into designing your type system, which brings a whole load more interactions to play with. Much easier to stay home and wrangle cats (which I suspect would have been a better occupation for at least some of the SQL standards committee, given some of the stuff they came up with).

God, I rambled a bit there ...

• Tony