Calculator

[Keith Thompson]

You never had to use old-fashioned Cobol, did you? The closest
thing to a function or procedure is 'perform', and there is no
parameter passing mechanism whatsoever. So you create some global
variables for the use of the performed paragraph, stuff values in
them, and use self discipline to not use them for other purposes.
This way it is possible to create fairly cleanly structured code.

Sure, you can emulate parameter passing in a language that doesn't
provide it. My only point was about the use of the term "parameter"
in a newsgroup that discuss a language whose standard has a very
specific definition of the term. Flash Gordon clearly was referring
to "parameters" in the C sense of the term.

 

[Malcolm]

Pick some different words if you want to create different concepts...

If you can show that the concepts are different, the of course I would do
so. But that's what is in dispute.

 

[Keith Thompson]

If you can show that the concepts are different, the of course I would do
so. But that's what is in dispute.

I don't know why there's any dispute.

function foo(x: integer) return integer;
begin
talk_to_some_hardware_device(x);
foo := query_some_hardware_device;
end;

Pascal calls this a function. You don't. QED.

 

[Chris Croughton]

If you can show that the concepts are different, the of course I would do
so. But that's what is in dispute.

You say:

One of the weaknesses of C is that there is no distinction between a
"function", which calculates something, and a "procedure" which does
something, i.e. interacts with hardware.

Everyone else says "if it returns a value then it's a function, if not
then it's a procedure", nothing whatever to do with "interacting with
hardware" (which every program does anyway; perhaps you mean "interacts
with peripherals").

You also say:

Procedures naturally contain global variables, because the computer is
attached to various shared devices. Functions don't (though malloc() is a
special case), because a function is naturally defined by its parameters.

Again, this is not true of the way the words have been used in the last
30+ years, Pascal (and Algol, and Modula, etc.) procedures need not do
anything with global variables at all (they can return output through
their parameters), and functions can happily make use of global
variables.

Your use of the words is not the same as the traditional interpretation.
Your quoted statements only make sense by your definitions of the words,
they make no sense at all using the traditional definitions.

Chris C

 

[Malcolm]

I don't know why there's any dispute.

function foo(x: integer) return integer;
begin
talk_to_some_hardware_device(x);
foo := query_some_hardware_device;
end;

Pascal calls this a function. You don't. QED.

American ass:
farts
British ass
farts, eats carrots, appears in nativity scenes.

American billion
1, 000, 000, 000
British billion
1, 000, 000, 000, 000

American state:
subsidiary division of the country.
British state.
superior union of two countries, one province, and a principality.

Now case one is obviously one word which hapens to mean two different
things. As far as I know there is no etymological or other connection, apart
from one incidental point of similarity.

Case two is really confusing and a total nuisance. The concept is "the next
division up from a million", but we have defined it differently.So the
uniformed person can end up with a wildly exaggerated idea of the American
national debt.

My functions and Pascal's functions, however, are like case three. They
express the same concept "unit of territory which is sovereign" but the
definition is different. To say that the British shouldn't use the term "the
state" because it has been bagged by the USA would be ridiculous. In fact
philosphers could argue about what the rights of a "state" ought to be -
should Texas be allowed to compete in the football (example 4?) world cup,
for example?

Similarly we can agree what a "function" is in mathematics, agree that
programming functions have enough similarities to use the same word, and
then argue about exactly how to define a "function" in a way that is useful.
Which is what we are doing.

 

[Walter Roberson]

Similarly we can agree what a "function" is in mathematics, agree that
programming functions have enough similarities to use the same word, and
then argue about exactly how to define a "function" in a way that is useful.
Which is what we are doing.

A "function" in mathematics is not defined by a formulae but
by a set of tuples, with the range of any one tuple member
potentially being infinitely large. There need not be any discernable
"pattern" to the tuples.

Something like f = { x -> x*x | x in integers, x from 5 to infinity }
is not the function itself but rather just a shorthand for the
function: the function is {(5, 25), (6,36), (7,49)} and so on
for all of the infinity of positive integers.

About the only programming language that I have ever encountered
which even comes close to getting this right is Maple, which allows
you to make arbitrary assignments such as f(3,-1/2,8*I) := 42
to -define- the function f at (3,-1/2,8i) .

It is clear that "function" in mathematics and "function" in C are
never going to be reconcilable, so the exercise is pointless.
The closest you would be able to get on the mathematics side
would not be "functions" but rather at most "functions which are
representable as the union of formulae applied over limited ranges".

even with that, I would be interested to see the mathematical
union-of-formulaes function corresponding to something as relatively
simple in C as "the next prime number after the whole number given as
the argument".

 

[Flash Gordon]

Fortunately for me, I haven't.

> The closest

I've come across SW written in assembler that way. However, it is still
accessing global variable rather than passing parameters in the
conventional sense.

Sure, you can emulate parameter passing in a language that doesn't
provide it. My only point was about the use of the term "parameter"
in a newsgroup that discuss a language whose standard has a very
specific definition of the term. Flash Gordon clearly was referring
to "parameters" in the C sense of the term.

Or the Pascal sense, or the way the term is used in other languages I've
used. I thought this was obvious. I could equally have invented some
non-portable function for reading from a piece of HW.

 

[Malcolm]

Everyone else says "if it returns a value then it's a function, if not
then it's a procedure", nothing whatever to do with "interacting with
hardware" (which every program does anyway; perhaps you mean "interacts
with peripherals").

No, that's the subtle but confusing point.
Memory you don't own is hardware.

Let's take this bit of code.

void grey(unsigned char *rgb, int width, int height)
{
unsigned char lum;
int i;
int ii;

for(i=0;i<height;i++)
for(ii=0;ii<width;ii++)
{
lum = luminance(rgb[0], rgb[1], rgb[2]);
rgb[0] = lum;
rgb[1] = lum;
rgb[2] = lum;
rgb += 3;
}
}

is it calculating something or doing something? Normally you would say it is
calculating something - what an image would be if converted form colour to
black and white.
But let's say we have memory-mapped screen, and pass it the screen buffer.
Now it is doing something - it's painting the screen grey.

However let's say we write the function like this.

unsigned char *grey(unsigned char *rgb, int width, int height)
{
unsigned char *answer;
answer = malloc(width * height * 3);
... etc ..
return answer;
}

Now it's a function. It is definitely calculating something rather than
doing something.

But what's really important here? The important difference is whether we
pass the first function a screen buffer, in which case it hardware
dependent, or memory that is local to the calling function, in which case it
is completely portable.

Now let's say we make a slight change to the first example.

/*
Make an image greysclae
Returns: average luminance.
*/
int grey(unsigned char *rgb, int width, int height)

Now grey() is a function, on your definiton. Is this change of any
importance or real interest to the calling programmer? Is that definition
actually capturing a useful difference?

 

[Keith Thompson]

I don't know why there's any dispute.

function foo(x: integer) return integer;
begin
talk_to_some_hardware_device(x);
foo := query_some_hardware_device;
end;

Pascal calls this a function. You don't. QED.

[snip]
My functions and Pascal's functions, however, are like case three. They
express the same concept "unit of territory which is sovereign" but the
definition is different. To say that the British shouldn't use the term "the
state" because it has been bagged by the USA would be ridiculous. In fact
philosphers could argue about what the rights of a "state" ought to be -
should Texas be allowed to compete in the football (example 4?) world cup,
for example?

Similarly we can agree what a "function" is in mathematics, agree that
programming functions have enough similarities to use the same word, and
then argue about exactly how to define a "function" in a way that is useful.
Which is what we are doing.

My followup was in response to your previous statement:

] If you can show that the concepts are different, the of course I would do
] so. But that's what is in dispute.

I understood the concepts in question to be "functions" as you use the
term, and "functions" as the term is used in, say, Pascal or any of a
number of other languages. If something is a function under one
definition of the term, and is not a function under another definition
of the term, then the two definitions refer to different concepts.

There is an ambiguity in the meaning of the term "state" between
American English and British English. There is no such ambiguity in
the meaning of the term "function" in the context of programming
languages, or at least there isn't nearly as great an ambiguity as
you're trying to create. The word is used differently in pure
mathematics; if you want to discuss that, there are several newsgroups
in the sci.math hierarchy.

Take a look at the responses in this thread. Unless I've missed
something, everyone other than you has said that the meanings of
"function" and "procedure" are already perfectly clear in the context
of programming languages, and they simply do not mean what you claim
they mean. What you're calling a "function" seems similar to what's
known as a "pure function". You may well have something important to
say about pure functions, but if you're more interested in redefining
words than in actually communicating with the rest of us, I for one am
not going to waste any more time trying to figure out what it might
be.

 

[Chris Croughton]

No, that's the subtle but confusing point.
Memory you don't own is hardware.

I own all of it, I paid for it when I bought the computer. It's still
hardware. At work I don't own the compiler I use (my employer does),
but it's still software. The same for the CPU etc. Yet another
meaningless distinction and yet more redefining of words in general use.

(And if you are referring to 'own' in some memory management sense --
off-topic for c.l.c -- then it's still a meaningless distinction, as
your examples show.)

Let's take this bit of code.

void grey(unsigned char *rgb, int width, int height)
{
unsigned char lum;
int i;
int ii;

for(i=0;i<height;i++)
for(ii=0;ii<width;ii++)
{
lum = luminance(rgb[0], rgb[1], rgb[2]);
rgb[0] = lum;
rgb[1] = lum;
rgb[2] = lum;
rgb += 3;
}
}

is it calculating something or doing something? Normally you would say it is
calculating something - what an image would be if converted form colour to
black and white.
But let's say we have memory-mapped screen, and pass it the screen buffer.
Now it is doing something - it's painting the screen grey.

Yup. So by your reasoning whether it is a 'function' or a 'procedure'
depends on the parameters when it is called. How is that even vaguely
useful?

To me, it's a 'procedure' (well, it would be in Pascal, in C it's a
"function returning void" regardless of what the parameters are).

However let's say we write the function like this.

unsigned char *grey(unsigned char *rgb, int width, int height)
{
unsigned char *answer;
answer = malloc(width * height * 3);
... etc ..
return answer;
}

Now it's a function. It is definitely calculating something rather than
doing something.

But if you pass it a pointer to a memory-mapped screen then by your
reasoning it's a 'procedure' again because it's accessing 'hardware'.

But what's really important here? The important difference is whether we
pass the first function a screen buffer, in which case it hardware
dependent, or memory that is local to the calling function, in which case it
is completely portable.

So you are now defining it by how it is called. What will you call it
if sometimes it is called with a pointer to screen memory and others to
a local screen buffer?

Now let's say we make a slight change to the first example.

/*
Make an image greysclae
Returns: average luminance.
*/
int grey(unsigned char *rgb, int width, int height)

Now grey() is a function, on your definiton. Is this change of any
importance or real interest to the calling programmer? Is that definition
actually capturing a useful difference?

Yes, it is. It is caputuring a difference in how it is used, the syntax
used to call it. That is essential information when programming, if
call it in the wrong way then I can expect to either lose the result or
get a syntax error by expecting a result when there isn't one.

Whether it accesses 'hardware' (whatever that is, I might be running
over the JVM) or not is not relevant to whether it is a 'function' or a
'procedure', and as you have demonstrated the same code may access
'hardware' or not depending how it is called.

Chris C

 

[Malcolm]

I own all of it, I paid for it when I bought the computer.

Schoolboy response to a point which is difficult and may well be beyond your
capacity to understand.
How about reading what Derrida had to say on metaphor and thinking, and
coming back when you have a qualified opinion on the subject?

 

[Malcolm]

It is clear that "function" in mathematics and "function" in C are
never going to be reconcilable, so the exercise is pointless.

No, we use the term "function" in programming because there is a resemblance
to the mathematical term.
An extremely pedantic mathematician might say that sqrt() isn't a square
root as he understands it, because sqrt(2) * sqrt(2) is unlikely to equal 2,
and pow(sqrt(-1), sqrt(-1)) will cause the computer to throw a wobbly,
whilst to the mathematican this is a perfectly normal real. However most
mathematicians would say that there is sufficient similarity between a C
sqrt() and a mathematical square root to use the same words.

The closest you would be able to get on the mathematics side
would not be "functions" but rather at most "functions which are
representable as the union of formulae applied over limited ranges".

Every programming function must have a domain which is less than the total
set of integers, or of real numbers. In practise this isn't much of a
problem - if we want to calculate pow(100000, 10000000000000) the computer
won't let us, but in reality we normally want to work with low numbers that
can be represented in C doubles.
The problem comes when the word "function" is used for things like exit(),
assert() and free().
You could design a proramming langage in which all functions are "pure
functions", or mathematical functions. So they return a vaule which is
defined solely by their arguments, and have no side effects. This wouldn't
necessarily be a bad idea, but you would have major efficency problems - the
sort routine would have to return a sorted copy of the list it was passed,
for instance.
So I've chosen to define "function" in a different way.
But I am not oblivious to the point that there is already a largely
syntactic definition of "procedure" and "function". Unfortunately people
don't seem to be able to grasp that my definitions are refinements of the
concepts (as British state is to American state), not reuse of the same
terms (as British ass is to American ass). This is frustrating but not
totally unexpected. It generally takes a bit of plugging away before ideas
click.

even with that, I would be interested to see the mathematical
union-of-formulaes function corresponding to something as relatively
simple in C as "the next prime number after the whole number given as
the argument".

Only God can count in primes. That is one of the mysteries of mathematics.

Why should some really simple rules produce very non-simple results? Have
you written a "prime spiral" program, BTW?

 

[Michael Wojcik]

You never had to use old-fashioned Cobol, did you? The closest
thing to a function or procedure is 'perform', and there is no
parameter passing mechanism whatsoever.

That must be some *mighty* "old-fashioned" COBOL. I haven't been
able to track down the original CODASYL report, but one source
claimed that CALL ... USING was introduced "early in the development"
of COBOL, and another that COBOL has "always" had CALL ... USING.

Nested programs were only standardized in COBOL 85, but I'm not aware
of any COBOL version where you couldn't call other programs - they
just had to be in separate source files.

So you create some global
variables for the use of the performed paragraph, stuff values in
them, and use self discipline to not use them for other purposes.

That certainly was the dominant practice (though some people prefer
to use sections rather than paragraphs - a distinction of importance
only to COBOL programmers), and as far as I can tell still is. And
prior to the 2002 standard there was no standard way to have
recursive (including mutually recursive) calls, though many implemen-
tations supported them as an extension.

But you could also write your application as an initial program and
subprograms, in COBOL parlance, which would all run in the same "job"
or "process". This is still somewhat more limited than C; besides
the lack of recursion, there's no equivalent of "static" (all
program names are externally visible) and while some implementations
(and, I think, the X/Open standard, though not the ISO standard)
provided a way to pass a return code, a program call couldn't be used
in an expression, so there was no function-like behavior. (Now COBOL
has support for user-defined functions.)

Traditional BASIC had no way to pass parameters to subroutines, did
it? They had to be global-scope variables (because there wasn't any
other scope).

At any rate, though, I agree that in these languages common practice
was to use global-scope variables for passing parameters, because the
language either didn't provide a parameter-passing mechanism or made
it cumbersome.

--
Michael Wojcik (e-mail address removed)

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-- David Bonde

 

[Flash Gordon]

No, we use the term "function" in programming because there is a resemblance
to the mathematical term.
An extremely pedantic mathematician might say that sqrt() isn't a square
root as he understands it, because sqrt(2) * sqrt(2) is unlikely to equal 2,
and pow(sqrt(-1), sqrt(-1)) will cause the computer to throw a wobbly,
whilst to the mathematican this is a perfectly normal real. However most
mathematicians would say that there is sufficient similarity between a C
sqrt() and a mathematical square root to use the same words.

Or the term in computing could come from use usage of the work function
as, "the function of the of the engine is to convert chemical energy in
to mechanical energy generating heat as a side effect which is used to
heat the interior of the car." So you have a function with a side effect.

Every programming function must have a domain which is less than the total
set of integers, or of real numbers.

False. The domain of a function can include all possibly values of input
parameter(s). For example:

int negative(int i)
{
return i < 0;
}

> In practise this isn't much of a
problem - if we want to calculate pow(100000, 10000000000000) the computer
won't let us, but in reality we normally want to work with low numbers that
can be represented in C doubles.
The problem comes when the word "function" is used for things like exit(),
assert() and free().

In other languages those would be called procedures or similar. However,
another example of the word function from outside of computing, "the
function of the grommet is to prevent the cable being damaged as it
passes through the case." Another use of the word function that has
nothing to do with returning a value but matches well with the use in C.

You could design a proramming langage in which all functions are "pure
functions", or mathematical functions. So they return a vaule which is
defined solely by their arguments, and have no side effects. This wouldn't
necessarily be a bad idea, but you would have major efficency problems - the
sort routine would have to return a sorted copy of the list it was passed,
for instance.

Unless you don't define the sort routine as a pure function.

So I've chosen to define "function" in a different way.
But I am not oblivious to the point that there is already a largely
syntactic definition of "procedure" and "function". Unfortunately people
don't seem to be able to grasp that my definitions are refinements of the
concepts (as British state is to American state), not reuse of the same
terms (as British ass is to American ass). This is frustrating but not
totally unexpected. It generally takes a bit of plugging away before ideas
click.

All you will do by continuing to try to redefine terms with well known
meanings is annoy people and get yourself plonked by people who could
help you with problems.

Only God can count in primes. That is one of the mysteries of mathematics.

Why should some really simple rules produce very non-simple results? Have
you written a "prime spiral" program, BTW?

Look at chaos theory. There are simple rules that produce very
non-simple results, and a whole branch of mathematics dedicated to them.
I think you missed Walters point, which is that some pure functions that
can be relatively easily expressed in a high level computer language are
not so easy to express in mathematics.

 

[CBFalconer]

That must be some *mighty* "old-fashioned" COBOL. I haven't been
able to track down the original CODASYL report, but one source
claimed that CALL ... USING was introduced "early in the development"
of COBOL, and another that COBOL has "always" had CALL ... USING.

I used it somewhere around '87 or so, but IIRC it was called COBOL
68. That was it for that installation.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Richard Bos]

Exactly. sqrt() is obviously a function. Is "get_mouse_position()" also a
function? I'm saying it is not, it is a procedure.

How about get_window_pixel(window, x,y)? It first needs to calculate the
global coordinates which are the equivalent of x and y in that window;
then fetch the pixel at those global coordinates; then return that pixel
to the caller.

How about a dummy function, for example the one I just wrote, which
allows one (off-topically, but illustratively) to use the old-style File
common dialogs under MS-Windows? It calculates nothing, interacts with
nothing, does nothing, in fact, but return FALSE.

The distinction you make is meaningless.

Richard

 

[Malcolm]

How about get_window_pixel(window, x,y)? It first needs to calculate the
global coordinates which are the equivalent of x and y in that window;
then fetch the pixel at those global coordinates; then return that pixel
to the caller.

It depends how the window parameter is defined. If the function cannot be
written without accessing global memory, then it is in one class, if it
takes all its arguments as parameters and doesn't alter them, it is a pure
function, if it is in between it is in another class (which I've called
function, to distinguish from pure function).

How about a dummy function, for example the one I just wrote, which
allows one (off-topically, but illustratively) to use the old-style File
common dialogs under MS-Windows? It calculates nothing, interacts with
nothing, does nothing, in fact, but return FALSE.
That's a pure function.

The distinction you make is meaningless.

Then the term "pure function" is also meaningless.

 

[Dave Thompson]

In my (perhaps somewhat limited) experience, these meanings of the
terms "procedure" and "function" are nearly universal.

Plus the similar 'subroutine' and 'function' in FORTRAN, wide but not
universal. PL/I used 'proc(edure)' for both valued and nonvalued.
IIRC algol68 used 'routine' for both. BCPL used 'routine' and had
everything valued, as its untyped word. LISP used only 'function' and
effectively had everything valued although that value can be the
special value NIL, which is arguably like the nonexistent or at least
unexpressible value of void type in C.

There is a related concept that may be close to what you're talking
about: a "pure" function. A pure function, loosely, is one that
computes a result using only its explicit parameters; it doesn't refer
to any global variables, none of its local variables are "static" in
the C sense, it has no side effects. The mathematical functions are
examples of this; time() is not, since it refers to an implicit
global. If an optimizer sees two calls to a pure function with the
same arguments, it can safely replace them with a single call.

Except in C for errno, as Chris Torek has already noted.

Neither Pascal nor C makes any language-level distinction between
"pure" functions and other functions. (Ada does, if I recall
correctly.)

Ada for (valued) functions prohibits any (formal) parameters in modes
that allow 'direct' writing whereas nonvalued procedures can have
'out' or 'in out' parameters. Both allow 'access' parameters,
effectively pointers, which can be written through, and (in a package)
persistent variables. And it allows a pragma to optionally specify
Pure which prohibits all persistent state, not just side-effects.

Fortran beginning with F90 allows FUNCTIONs to be declared PURE which
enforces prohibitions against language-recognized side-effects and
redundant calls may be elided; F95 adds ELEMENTAL which further allows
different calls for whole-array operations to be done in parallel. The
usual math library functions like SIN have this attribute.

- David.Thompson1 at worldnet.att.net

 

[Malcolm]

Ada for (valued) functions prohibits any (formal) parameters in modes
that allow 'direct' writing whereas nonvalued procedures can have
'out' or 'in out' parameters. Both allow 'access' parameters,
effectively pointers, which can be written through, and (in a package)
persistent variables. And it allows a pragma to optionally specify
Pure which prohibits all persistent state, not just side-effects.

Thank you.