# Re: Example of expression bias?

Date: 20 Jun 2006 06:06:20 -0700

Message-ID: <1150808780.552310.62170_at_g10g2000cwb.googlegroups.com>

Sorry, TYPO, you have been pouding so hard your high order function that I made a nonsense.

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

should read...

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 ensemblist combinatory functions...

Cimode wrote:

*> Tony D wrote:
**> > Cimode wrote:
**> > > I meant nothingness.
**> > >
**> >
*

> > Then be more careful with your method of expression. But your method of

*> > expression is quite obviously the least of your problems ...
**> I may do sometimes a typo but so are you...I have some excuse to speak
**> a foreign language.
**>
**> > > Usefulness does not determine soundness.
**> >
**> > And quite obviously, you haven't bothered to read anything about the
**> > lambda calculus; it pre-dates electronic computers and programming as
**> > it is currently known. It is a formalism for describing and discussing
**> > computable functions. It is provable (and was, as part of the
**> > Church-Turing Thesis - look it up) that any computable function can be
**> > described in terms of the lambda calculus. If you still need a proof of
**> > soundness, disengage your bile ducts and start doing some reading.
**> You defined relevance of FP by its usefulness. I simply responded that
**> soundness is not determined by usefulness... I do not have time to do
**> reading on FP. 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...
**>
**>
**> > > It is not because FP or OO
**> > > mechanisms can be helpful at implementation that they represent a sound
**> > > fundation to build on...Implementations should be determined according
**> > > to sound logical fundation.
**> >
**> > And as I've told you on a few occasions now, there is no sounder basis
**> > than the lambda calculus for describing and reasoning about computable
**> > functions.
**> 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.
**>
**>
**> > > In data management RM is pure succesfully
**> > > applied mathematics. Only indepth comprehension of RM concepts can
**> > > allow to evaluate validity of a possible implementation model.
**> >
**> > You have gone off the deep end now. Sadly, you're not even in the
**> > correct swimming pool.
**> Huh? What the hell are you talking about...?
**>
**> > > FP or OO are not even models they are mechanisms...I do not see how a
**> > > mechanism can be succeful in anything if it does not rely from an
**> > > implementation model, which itself derives from RM... The rest is
**> > > repetition...
**> > >
**> >
**> > Yes, you are very repetitious, both in your language and your ability
**> > to completely miss the point. Would you care to go back and read where
**> > this started from (that is: a question about where Erwin could find out
**> > about higher order functions) ?
**> 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...
**>
**> >
**> > > If I have stated that FP is irrelevant it is because I have already
**> > > discussed and wasted time with it...
**> >
**> > It's only irrelevant and a waste of time because you have grabbed the
**> > wrong end of the stick and are shaking it with vigour.
**> 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...
**>
**> > > No sound logical model has been
**> > > defined for *undecideability* computing (while at it while not evoque
**> > > quantic computing!) and even if there was one it would not be relevant
**> > > to data management. Only RM has been defined specifically in such
**> > > direction.
**> > >
**> >
**> > The mention of undecideability was with regard to one of the
**> > fundamental issues of computability theory. Maybe if you'd bothered
**> > reading rather jumping off the deep end you would have known that.
**> undecideability relies on a concept that is totally off scope for data
**> management issues...
**> Don't you get it?
**>
**> > > The reason why you still advocate such nonsense is because you do not
**> > > understand sufficiently the difference between SQL and RM.
**> > > Understanding better RM can only help you make sense of what I am
**> > > stating.
**> > >
**> >
**> > What on *earth* has SQL got to do with this ? You have now wandered off
**> > into total irrelevance.
**> As a lot of people, you probably perceive RM through misinformed SQL
**> audiences who have limited the relevance of RM theory.
**>
**> > > Should read...
**> > > Somebody who believes that programming which is an implementation could
**> > > define a computing abstract foundation such as RM is simply delluding
**> > > himself.
**>
**> > If this means what I think it means (and it's a stretch), then it would
**> > be both correct and irrelevant to the topic under discussion.
**>
**> It is perfectly (fill the predicate proposition and you will understand
**> hopefully the chain of reasoning)
*

Received on Tue Jun 20 2006 - 15:06:20 CEST