Re: Example of expression bias?

From: Cimode <>
Date: 20 Jun 2006 09:34:32 -0700
Message-ID: <>

Tony D wrote:
> Cimode wrote:
> > Data types are not orthogonal to relations (in RM), they are integral
> > part of RM definition.
> >
> Then we've just come to a shuddering halt in this discussion, because
> this is an unbridgeable gap. Relations are *very much* orthogonal to
> data types; the definitions of relation, tuple, attribute and the
> relational operators have only one thing to say about the data types to
> which attributes may belong - that a boolean equivalence function
> between two values of that type is defined. That's *it*. Nothing else,
> and nothing more.
You are redefining RM. A relvar has associated properties among which a data type expressing how it draws values from a domain and restricts that extraction only to permissible values.

A data type in RM = (a domain1 to draw values from) + (restrictions implemented on domain1 --> domain constraint) + (operators that can be defined using that data type)

An attribute does not belong to a data type. A data type is the set of rules that apply to attribute for saying whether or not values in tuples are permissible values in the system.

> If we can't agree on that, then yes, this discussion is completely null
> and void.

> Since we're shuddering to a halt, I won't go through the whole post
> blow by blow.
> > I have provided you with an analogy about the bus. Did you understand
> > it? Do you still consider a variable as varying?
> >
> Taking a commonly used denotational semantics view of it, for a
> variable name the denotable value is a location, and a store is a
> function, mapping from a location to a value. The location won't
> change, but the value that location maps to will. Does that answer your
> question ? I was quite specific to say that in my post I was referring
> to C/Pascal/3GL style variables, rather than the mathematical/FP sense
> of variables.
That's what I mean by saying you are at implementation level.

> [ snippage ]
> > user defined types are a part of RM, they are defined as types of
> > arbitrary complexity.
> >
> Care to vague that up for me a bit more ? It's not much of a
> definition; it's not much of a definition because data types are
> nothing to do with RM.
If you are considering that data types are not defined in RM. That shows the level of ignorance about RM concepts your in.

> > From what I observe interacting with you and the level of confusion
> > that seems induced by FP, I believe that it is a waste of time. Which
> > I express...
> >
> Fair enough, you think I'm confused; in that case you owe it to
> yourself to consult better sources than me. You could *start* at
> wikipedia, which has some useful links on to other sites; or you could
> go to It's really up to you. And yes, it's your loss if
> you don't.
> > What data management problems are you refering to? Be more specific...
> Not every problem is a data management problem. For example, data type
> definition, about which the RM has nothing to say. As I said in the
> first paragraph, if we're not going to agree on that, then yes, future
> discussion will, as ever, generate plenty of heat and little light.
> [ snippage ]
If you state that RM has said nothing about data types: It can only mean one thing -->you have never read a book about RM.

> > A computer is a set of mechanized components regulated by electronic.
> At the physical level, yes. At the physical level, they are also
> generally uninteresting lumps of plastic and metal. At the conceptual
> level of computable functions, electronics, electricity, plastic and
> metal are utterly irrelevant. Hence a comment I made before: all the
> really interesting results in computing science can be derived with a
> pen and piece of paper.
> > The only way you can make inferences about data is by defining a
> > logical computing model then derive an implementation physical model
> > from that logical model.
> >
> Actually, you only really need what you call the logical computing
> model.
I am tired with you.

> [ snippage ]
> > I can not agree with confusion and vagueness. I have provided you with
> > several definitions, analogies and proofs to proove your definition of
> > variable was wrong. You have produced an exhortation to find out about
> > FP
> Where was your "proof", never mind several ? It can't have been the bus
> analogy, surely. And even then, we argued to agree.
I have asked a question you did not answer.

> > No it is a fact. SQL has been clearly identified by many RM people as
> > having a very strong limiting effect on RM understand..Some people
> > dumped it for more than 20 years ago because of that.
> "No it is a fact." What is a fact, in either of the two sentences to
> which you responded ? SQL can only limit your understanding of RM if
> you allow it to. Once the differences have been pointed out, accepted
> and understood, it's pretty difficult to confuse them thereafter.
> (Whether you either discover the differences or have them pointed out
> to you is another matter entirely.)
Definition RM, through SQL perception limits the understanding of RM.

> > It was irrelevant when you give relevance to the premice behind the
> > theory. I don't. I have been asking questions that have not been
> > answered therefore I have to assume I was right.
> I'm not clear on what your first sentence means. Which premise to which
> theory ?
That FP is a set of definition sufficiently clear. All I have seen so far in your definition is fuziness..

> I think you would assume you were right no matter what answer was given
> to you.
No. If the answers were convincing, I may have paid a closer look. But I confirm what I thought. Received on Tue Jun 20 2006 - 18:34:32 CEST

Original text of this message