From: santas@inf.ethz.ch (Philip Santas)
Newsgroups: comp.object
Subject: Re: Passing functions as parameters in an OO environment
Keywords: function, object, type, mathematics , ADT , parameter
Date: 28 Sep 92 21:04:07 GMT
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH



In article <1992Sep25.150611.24570@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
>
>So if you are working in Algebra you should be thinking in terms of
>Sets, Groups, Rings, Fields, Euclidean Domains, Polynomials, Vector
>Spaces, Field Extensions, Finite Fields, Finite Groups, Galois
>relations , splitting fields of a polynomial, etc etc. These are your
>Abstract Data Types.

So, Real, Integer are the Normal Data Types and Ring is the Abstract
Data Type? Can you please present the graph you propose?

>The so called 'functional' concepts have led software people into a
>kind of mathematical cloud cuckoo land. We now have these
>disembodied 'functions' floating out there in bits of code with
>almost no connection to their domain or range of relevance and no
>axiomatic constraints. This is a nightmare fantasy!

What functions in FP have no axiomatic constraints?
And which have no domain or range? 
Do you say that in OOP you get this for free?

From Smalltalk-80:

Class Integer:

+ aNumber 
	"Answer the sum of the receiver and the argument, aNumber."
	^aNumber sumFromInteger: self

Where do you see the domain and the range and the integer addition?

On the other hand I bring you an example from SML:

- fun f(x) = x+1;
val f = fn : int -> int

Have you noticed the work of the automatic type inference?

>No wonder most non-OO languages and hybrids have to fumble around
>in the dark with myriads of CASE statements inside 'functions' to
>allow for every single possible form of input that some other part of
>a system may choose to dump on them.

CASE statements are generated by the compiler and not by the user.
The Haskell manual explains some of these tricks.

But in Smalltalk-80:

Class Integer:

// aNumber 
	"Answer the result of dividing the receiver by the argument.
	The result is rounded down towards negative infinity to make it 
	a whole integer."

	| q |
	self = 0 ifTrue: [^0].
	q := self quo: aNumber.
	(q negative
		ifTrue: [q * aNumber ~= self]
		ifFalse: [q = 0 and: [self negative ~= aNumber negative]])
		ifTrue: [^q - 1"Truncate towards minus infinity"]
		ifFalse: [^q]

Did you say anything about CASE statements?...

>The misguided evolution of the 'functional' movement, 'functional
>decomposition', 'structured analysis' etc is , in my opinion, almost
>entirely due to ignorance of the most basic concepts of
>mathematics. e.g. the nonsense of the idea of a 'function' existing
>independently of its domain, range , taxonomic context, axioms,
>theorems etc. OO gives us the opportunity to get back to the real
>mathematical sense of what a function is and has been for several
>hundred years. 

Look example above.

Can you please enlighten us, what has a function been for "several hundred
years"?

> The database people got landed with another half
>truth : that we are only concerned with the domains, the ranges are
>less important. History has shown that they were left with the
>lesser of the two evils. At least they knew where they were
>beginning even if they did not know where they were going.

Are you "a bit" prejudiced?

Philip Santas

     Self-evident: Evident to one's self and no-one else. (Ambrose Bierce)
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391
      
Newsgroups: comp.object,comp.lang.objective-c