Re: Interesting article: In the Beginning: An RDBMS history

Marshall Spight wrote:
mAsterdam wrote:

Marshall Spight wrote:

The choice between a numerical vs. symbolic identification of
attributes is purely syntactic.

I can not agree with that.

First a frame of reference.
Supporting levels, low to high:
(fatic -) syntactic - semantic - pragmatic.

I don't understand this last paragraph at all. (What is "fatic?")

A theory explained in
Watzlawick, P., Beavin, J., & Jackson, D., (1967). Pragmatics of Human Communication. W. W. Norton: New York , referenced e.g. at
has a nice and simple layered reference model for
communication interactions.

I'm going to do the theory unjustice.
It is 32 years after I last read it (I never got the book
back), and I kept reshuffling the concepts in application.

Here is the gist of what's left:

0. fatic: the creation and maintenance of the communications infrastructure: E.g. holiday cards:
"Hi, the wether is great here - how are you doing?"
The content is irrelevant: the essence of the message is the message itself: I am here - are you there?)

1. syntax: grammars, forms, interview-style talks.
Information structure.

2. semantics: What does it mean? Generic (say dictionary-)
Information substance.

3. pragmatics: Goals and Consequences. What is the purpose, desired
and real effect of this communication - the interpretation and consequential action of this message in a specific context.
Information use.

Like in network protocolstacks and n-tier client-server models
the lower level is supporting the upper level: the higher level
constructs can not exist without the lower level and there
is no use for the lower level but to serve the higher level

An example:
You find a parking ticket on your car:

fatic: Yep, the police is doing it's job.

syntax: The form they filled.
(if the police made a mistake in this aspect there is rejoice at the pragmatic level :-)

semantic: You parked your car where it isn't allowed.

pragmatic: How zealous is the local police in cashing the
money - can I get away with it by pretending I did not see it?
but also: I'll have to reschedule my appointment because
I have to pay this at the station within 24 hours.

But it seems to imply that syntactic is somehow "lesser"
than semantic; I wouldn't agree with that. They are different
things, but one is not "higher" than the other; both are
necessary for language.

In general: agreed - That in this support-level list
syntax supports semantics doesn't in anyway mean that
syntax is lesser than semantics.

Numerical vs. symbolic identification of attributes has
consequences (i.e. differs at the pragmatic level.)

I'm not sure I understand this either. It seems to say
that if something has pragmatic consequences, it can't
be purely syntactic. If so, I strongly disagree.

Emphasis: /purely/.
Whenever we can change the syntax without affecting meaning and
use, we have a purely syntactic issue.

Syntax is huge in what it can do. I have often underestimated
its importance and its power, but I'm going to try not to
do that anymore. I'm still not clear on what the boundaries
of syntax are, but I'm working on it.

I'm not saying I do know where they are.

To me to book "Pragmatics of Human Communication",
was really helpful in not having to many difficulties
with this boundary.

Names rely on the existance of common semantics,
numbers on form agreement (isomorphism)
(Both only implied in practise most of the time,
but hey! this is cd/t/ :-)

This choice goes well beyond syntax.

Can you give a specific example?

Consider: we can write a relational language which contains
join as an operator. We can write this language in such a way
that the syntactic phase uses either numbers or names to
identify relation attributes, and we can produce an abstract
syntax tree that identifies attributes either by name or by

So how is the decision anything *other* than syntactic?

In effect.

When the stuff which is joined undergoes a change, say it
looses or gets new attributes, the number references will
have to be re-examined. I'ld say that is a pragmatic effect
of the change.
The names for existing attributes will stay the same and
consequently refer to the same as they did before effortlessly,
so in that case there is no pragmatic effect.

So, this decision, while dealing with "just" syntax, does
have impact in other areas.

But wanting to have both at the same time, while it seems innocuous
enough, actually leads to the loss of important algebraic properties.
It seems like it can be reconciled, but I am convinced it can't, at
least not without some loss.

Intuitively: Yep, I think it can't either. My guess: demarcating
this loss will take some effort and time, though.

It certainly took me long enough!

I'm too tired to write up the substitutibility problem right now.
I'll just mention that I spent long time trying to devise a
syntax and semantics that would hold all the design value
of named attributes with all the notational convenience of
positional attributes, and I couldn't make it work. The
problems are subtle, but pernicious.

I wish I had some nice words to encourage you to share
those problems.

Um, well. Let's see.

An important property of a language is that you can bind a
subexpression to a name and then rewrite the expression,
substituting the name for the subexpression and get identical

Sometimes context doen't matter, sometimes it does.
Is this one of the problems?