# Re: Example of expression bias?

Date: 20 Jun 2006 07:33:10 -0700

Message-ID: <1150813990.371937.184350_at_h76g2000cwa.googlegroups.com>

Tony D wrote:

*> Cimode wrote:
**> > You defined relevance of FP by its usefulness.
**>
*

> No; you enquired what FP would be useful for, and started rambling

*> about implementation.
**>
**> > I simply responded that soundness is not determined by usefulness...
*

That's how you defined that FP.

> > I do not have time to do reading on FP.

*>
**> Your loss.
*

I doubt it.

> > The little I have been exposed to was sufficient to

*> > consider it irrelevant to data management issue. All the nonsense you
**> > produce about data management concepts do not encourage me any more...
**> >
**>
**> What nonsense would that be, precisely ? So far on data management
**> concepts, we've managed to agree to differ on perspective on the
**> definition of relvars and relations (I accept Date's position, with
**> which you are not comfortable). You seem to think Date's definition can
**> cause confusion between the definitions of attributes and variables; I
**> don't see how this confusion can arise. We disagree on the definition
**> of a data type (you hold domains to be a pool of possible values,
**> distinct from types;
**>I don't see this as a useful distinction and don't
**> accept it). Please describe the nonsense therein, given the position
**> that data types are orthogonal to relations.
*

Data types are not orthogonal to relations (in RM), they are integral
part of RM definition.

*> > Good. All I wrote to describe what is a sound implementation model was
**> > totally useless.
*

> > The predicate is

*> > Mathematical expression 1(is implemented as) Logical Model for data
**> > management1 (is implemented as) Implementation Computational
**> > Model1...For RM, it comes to
**> > Mathematical Relations(is implemented as) RM (is implemented as) TRM?
**> > (Last one not confirmed)...
**> >
**> > What is the occurence of predicate you state to give me any interest in
**> > FP.
*

If I bother ask you a question, the least you could do is try to answer
it. How do you express the proposal explaining the logical methodology
that caracterizes the definition of FP.

> You're bashing on about implementations again; as I have said on

*> *several* occasions, implementation issues are of no interest to me.
*

The predicate I have stated was not exclusively aimed at implementation
level. It was aimed at detailing the methodology necessary to get a
sound implementation model. Do you bother respond to the question I
have asked or I will stop this discussion.

> However, we have (I think) agreed that user defined types are essential

*> to a useful relational system; therefore, we need some way of defining
**> those types and the associated operators. That's where I want to use
**> functional programming. (In fact, I want to use an FP system which just
**> happens to offer full support for relations.)
*

user defined types are a part of RM, they are defined as types of
arbitrary complexity.

> > Huh? What the hell are you talking about...?

*> >
**> I mean, you are being completely irrelevant.
**>
**> > So what is your point? I will not get back to higher order functions.
**> > relations are sufficient to describe more simply the concepts refered
**> > to as higher order functions...
**> >
**>
**> The point is, Erwin asked about where he could learn about higher order
**> functions. Marshall gave him some references. You bashed Marshall in a
**> completely irrelevant way, and cast ignorant aspersions on the
**> soundness of the basis of functional programming (that is, the lambda
**> calculus). I pointed this out to you, and advised you to read up on the
**> lambda calculus before making any more ignorant pronouncements about
**> it. You have responded in your usual delightful manner. Hopefully Erwin
**> is reading about higher order functions in blissful ignorance of yet
**> another trail of useless postings involving you being irrelevant and
**> insulting with it.
**>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...

*> > I am not shaking anything except your delluded brain...To encourage get
*

> > significant education about RM which has been proven sufficient to

*> > abord the problem of formal representation of information in mechanized
**> > systems...
**> >
**>
**> RM answers some problems. It answers those problems better than any
**> other available model. But it doesn't answer *every* problem.
*

What data management problems are you refering to? Be more specific...

> So it

*> will have to be joined with "something else" to answer other problems.
*

> Given the mathematical basis of RM, and the mathematical basis of the

*> lambda calculus, wouldn't you agree that there is more chance of those
**> resulting in a mathematically sound, reasonable union than say, RM and
**> OO ?
*

RM was demonstrated as a sound and clear basis for being used as a
model of logical application of mathematics....I do not see any of
these caracteristics in your speech...I see only confusion and
vagueness...

*> > undecideability relies on a concept that is totally off scope for data
*

> > management issues...

*>
**> So, computability theory isn't relevant to data management issues ? If
*

undecideability is a logical mathematical concept, computability theory
is expressed as an implementation model derived from a logical
computing model (RM) derived itself from the logical mathematical
concept...They are not equal but they derive from one another.

So I ask once again, what is the logical model equivalent to RM that support the implementation issue of FP?

> your data management involves pen and paper, maybe. As soon as a

*> computer is involved, computability is more relevant than you care to
**> think.
*

A computer is a set of mechanized components regulated by electronic.
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.

It is not my data management, it's also the data management who
inspired an entire industry which did not know how to make full use of
it.

*> > Don't you get it?
**> >
**>
*

> Yes. But I don't think you do.

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

*> > As a lot of people, you probably perceive RM through misinformed SQL
*

> > audiences who have limited the relevance of RM theory.

*> >
**>
**> This is one of your own "prepackaged notions" that you fall back on
**> with monotonous regularity. And, for your info, no, I don't.
*

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.

> > It is perfectly (fill the predicate proposition and you will understand

*> > hopefully the chain of reasoning)
**>
**> The chain of reasoning (such as it was) was irrelevant to the
**> discussion at hand.
*

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.
Received on Tue Jun 20 2006 - 16:33:10 CEST