Re: Example of expression bias?

From: Cimode <>
Date: 20 Jun 2006 23:25:11 -0700
Message-ID: <>

Tony D wrote:
> Well, here we are again ...
> Cimode wrote:
> > You are redefining RM.
> No I'm not. You're about to try though. I would also point you towards
> a boxed out section, in bold type, two-thirds of the way down page 114
> in the 7th edition of Date's Introduction to Database Systems. The
> preceding paragraph is also helpful.
> > 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.
I wrote this...How is it different from what CJ's written..? // You are redefining RM. A relvar has associated properties among which
 a data type //

> Mmmm. How about, a relvar is a variable which can indicate relation
> values. It has an associated set of constraints that define which
> relation values it is acceptable for the relvar to indicate. Clumsy
> I'll grant you.
No. A relvar is a value placeholder for a relation...That's all you have to know...relvar are to relations what variabkes are to functions.

> > 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)
> >
> This may be one definition of a data type (not quite one I'd accept, as
> we've thrashed over elsewhere), but there is nothing particular to RM
> about this.
If the trashing happened elsewhere it must have been due to incomprehension of RM...

> > 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 an attribute doesn't belong (for want of a better word) to a data
> type, how do you specify what the acceptable values for it are ? Your
> second sentence moves in a single breath from attributes to tuples to
> the system as a whole.
Whatch out with semantics...
*belong* suppose EXCLUSIVE relationship between the two...A data type definition may be *mutualized* by several attributes.

> > That's what I mean by saying you are at implementation level.
> >
> Actually no, that's a base level definition, valid in beginner's
> denotational semantics, of what variables *mean*. You *could* implement
> them that way, but not necessarily; as long as the net effect is
> provably the same you have produced an acceptable implementation of the
> definition. (You may care to do some reading on denotational semantics;
> google for Christopher Strachey, Dana Scott and/or Joe Stoy for
> starting points.)

> That's another plus for FP; if you manage to define an acceptable set
> of denotational semantics, it doesn't take a lot of work to turn them
> into an executable specification. Maybe that's why Perl 6 is (according
> to Larry Wall, anyway) being trial implemented in Haskell. Off topic,
> but mildly interesting in context.
> > If you are considering that data types are not defined in RM. That
> > shows the level of ignorance about RM concepts your in.
> >
> And if you're thinking that what RM has to say about data types
> constitutes a complete, sound and usable definition of data types,
> you've got some reading to do.
Again you are not encouraging me...

> > 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.
> >
> I've read a few; they've had little to say about data types, apart from
> they exist, you need them, and you need to be able to define your own.
> (Date moves on into how to define your own via Tutorial D; but since
> the starting point is that types are orthogonal to the relational
> model, this is "add-on" territory, not fundamental to RM itself.)
Maybe but you clearly did not make sense out of them...Maybe you should do some readin about Mathematics of relation...
> > I am tired with you.
> >
> Time for sleepy-byes, then.
Jet lag time zone...

> > I have asked a question you did not answer.
> >
> And I told you I wasn't going to blow by blow our last exchange. (And
> here I am doing it again. Oscar, you have much to answer for !)
I have not perceived the question as a blow by blow exchange excuse. It is a simple question I have asked you to understand your position and that clearly you are refusing to adress because it proves your definition of variable as ambiguous. You refusal to address is a defensive mechanism?

> > Definition RM, through SQL perception limits the understanding of RM.
> >
> I'm not sure this is a sentence, and even if it is, I'm not sure what
> (if any) meaning it is intended to convey.
I am not surprised...

> > That FP is a set of definition sufficiently clear. All I have seen so
> > far in your definition is fuziness..
Clear to whom? All your explanations are fuzzy so far...

> Clear, precise definitions of lambda calculus are readily available. In
> fact, the wikipedia entry is entirely acceptable, because the syntax
> and semantics of the lambda calculus are so straightforward. If you
> suspect wikipedia, then you can buy just about any FP book and it will
> explain it in no time (the operational semantics in Peyton Jones's
> "Implementation of Functional Programming Languages" takes a whole 9
> pages (pp 14 - 23), including worked examples and quite a lot of
> explanatory text.)
Let's play a game...Answer the question I have asked you and I promess I will take a look at your references.

> > No. If the answers were convincing, I may have paid a closer look.
> > But I confirm what I thought.
> Now there's a surprise.
I am not stubborn. But I know when somebody tries to redefine RM. Received on Wed Jun 21 2006 - 08:25:11 CEST

Original text of this message