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

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 07 Apr 2006 13:51:10 +0200
Message-ID: <4438f512$0$11065$e4fe514c@news.xs4all.nl>

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 http://www.uky.edu/~drlane/capstone/interpersonal/intview.htm 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-) interpration. 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 constructs.

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

Sometimes context doen't matter, sometimes it does. Is this one of the problems? Received on Fri Apr 07 2006 - 06:51:10 CDT