Calculator

[Malcolm]

You forget a "functure", which interacts with the hardware and then
calculates something from the result; a "fucedure", which calculates
something and then sends the result to hardware; and a "procion", which
neither interacts with hardware, nor calculates something.

Normally you would say that a procedure can call a function, but if a
function calls a procedure then it becomes a procedure.
The whole point of the separation is to get rid of "functures" and
"procions", so that if, for instance, I want to calculate raster data from
wavelets stored in a JPEG file, the bulk of the calculation (the function)
is separate from the IO (the procedures which read the data in from the disk
drive).

I'm not sure what a "procion" would be. Can you give an example?

However of course the issue isn't open and shut - there are lots of reasons
for not introducing this distinction as a function type qualifier.

 

[Keith Thompson]

Normally you would say that a procedure can call a function, but if a
function calls a procedure then it becomes a procedure.
The whole point of the separation is to get rid of "functures" and
"procions", so that if, for instance, I want to calculate raster data from
wavelets stored in a JPEG file, the bulk of the calculation (the function)
is separate from the IO (the procedures which read the data in from the disk
drive).

Then you're making a distinction that has no relationship I can see to
the usual distinction between a "procedure" and a "function".

In Pascal, a "procedure" is a subroutine that doesn't return a result
(though it can indirectly return a result via a parameter); a
"function" is a subroutine that does return a result. Functions can
call procedures, and procedures can call functions. The C equivalent
to a Pascal procedure is a void function; the C equivalent to a Pascal
function is a non-void function. Several other languages (many of
them Pascal-based) use the same terminology.

The distinction has nothing whatsoever to do with interacting or not
interacting with hardware, and I don't know of any language that makes
such a distinction at the language level.

If you want to talk about distinguishing between subroutines that
interact with hardware vs. ones that don't, please pick different
terms.

 

[Malcolm]

Then you're making a distinction that has no relationship I can see to
the usual distinction between a "procedure" and a "function".

In Pascal, a "procedure" is a subroutine that doesn't return a result
(though it can indirectly return a result via a parameter); a
"function" is a subroutine that does return a result.

So a function calculates something - ie is a number of set of numbers that
is defined by the arguments.
A procedure doesn't calculate something, because it doesn't return anything.
So obviously it must do something if it is to have any purpose whatsoever.

However Pascal hasn't made the distinction very well, because both functions
and procedures are allowed to interact with global variables or to modify
their arguments. So you can have a procedure which is effectively a function
but just doesn't happen to return its value using function notation, or a
function whose main purpose is the side effects, and tis thus effectively a
procedure.

I think my definitions are capturing the same idea, but in a better way.

 

[Flash Gordon]

So a function calculates something - ie is a number of set of numbers that
is defined by the arguments.

What if the value returned is determined by by HW rather than
parameters? For example, getchar which has *no* parameters.

A procedure doesn't calculate something, because it doesn't return anything.
So obviously it must do something if it is to have any purpose whatsoever.

What about a routine the prime purpose of which is to do something, but
also returns a value? Such as putc?

What about a "procedure" the prime purpose of which is to modify it's
input parameters, such as qsort? It definitely "returns" something, i.e.
a sorted array.

I often write functions which return a value where the primary purpose
is to *do* something and the return value indicates what it did, or
whether it succeeded etc. The C *function* main being a prime example in
a lot of programs.

However Pascal hasn't made the distinction very well, because both functions
and procedures are allowed to interact with global variables or to modify
their arguments. So you can have a procedure which is effectively a function
but just doesn't happen to return its value using function notation, or a
function whose main purpose is the side effects, and tis thus effectively a
procedure.

I think my definitions are capturing the same idea, but in a better way.

If you are defining a different concept it is best to use a different
name, rather than one which already as a meaning people are familiar
with. You also need to realise that the world is not a simple place.

 

[CBFalconer]

So a function calculates something - ie is a number of set of
numbers that is defined by the arguments.
A procedure doesn't calculate something, because it doesn't return
anything. So obviously it must do something if it is to have any
purpose whatsoever.

However Pascal hasn't made the distinction very well, because both
functions and procedures are allowed to interact with global
variables or to modify their arguments. So you can have a procedure
which is effectively a function but just doesn't happen to return
its value using function notation, or a function whose main purpose
is the side effects, and tis thus effectively a procedure.

Hardware, globals, modifying arguments have nothing to do with it.
The essential difference is that a function returns a value, and
can be embedded in an expression. A procedure performs actions,
and cannot be embedded in an expression.

x = 1 + 2 * f(g);

is a use of the function f, while

x = 1 + 2 * p(g);

is invalid syntax with the procedure p. For C, a procedure is a
void function. In Pascal the returned value of a function must be
used (but can be deposited in a junk variable).

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

 

[CBFalconer]

.... snip ...

What if the value returned is determined by by HW rather than
parameters? For example, getchar which has *no* parameters.

But it does have parameters, namely the global value of stdin. The
parameters just happen to be hidden from the casual user. You can
affect that global value (and thus the action of getchar) by
redirecting the programs input stream.

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

 

[Walter Roberson]

Hardware, globals, modifying arguments have nothing to do with it.
The essential difference is that a function returns a value, and
can be embedded in an expression. A procedure performs actions,
and cannot be embedded in an expression.

#include <stdio.h>

void myproc(int param) {
printf( "myproc: %d\n", param );
}

int main(void) {
int rez;
rez = (myproc(7), 42);
printf( "main: %d\n", rez );
return 0;
}


The comma operator is part of an expression.

 

[Malcolm]

What if the value returned is determined by by HW rather than parameters?
For example, getchar which has *no* parameters.

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

What about a routine the prime purpose of which is to do something, but
also returns a value? Such as putc?

What about a "procedure" the prime purpose of which is to modify it's
input parameters, such as qsort? It definitely "returns" something, i.e. a
sorted array.

Exactly. The designers of Pascal were trying to express the difference
between a function and a procedure, but did't do so in a way that is useful
to the programmer.
Ideally a function would not be allowed to alter its arguments. So qsort
would be

void *qsort(const void *array ... etc)

taking an array as input and returning a sorted array. However efficiency
considerations preclude this.

I often write functions which return a value where the primary purpose is
to *do* something and the return value indicates what it did, or whether
it succeeded etc. The C *function* main being a prime example in a lot of
programs.

So it doesn't actually make sense to say that a procedure cannot return a
value. Writing an image to disk is basically output, for example, but you
have to input the amount of free space left on the drive.

If you are defining a different concept it is best to use a different
name, rather than one which already as a meaning people are familiar with.
You also need to realise that the world is not a simple place.

We can't really surrender the term "function" to ANSI. Essentially I am
using the same concept as Pascal, but defining it in a better way.
Most good ideas are inherently simple, but the implications are not
necessarily simple. I don't think anyone apart from you is accusing me of
being simplistic here, though I might be wrong.

 

[Malcolm]

Hardware, globals, modifying arguments have nothing to do with it.
The essential difference is that a function returns a value, and
can be embedded in an expression. A procedure performs actions,
and cannot be embedded in an expression.

That's a good point. The Pascal distinction is useful to the compiler
writer. My definition is useful to the programmer.

 

[Chris Torek]

[snippage]

Hardware, globals, modifying arguments have nothing to do with it.
The essential difference is that a function returns a value, and
can be embedded in an expression. A procedure performs actions,
and cannot be embedded in an expression.

I think this is not quite what Malcolm is trying to express.

In compiler circles, the idea I think he has in mind is usually
referred to as a "pure" function. A pure function is one whose
outputs depend only on its (obvious) inputs; it has no side effects.
Examples of such functions include the usual mathematical functions.
Of course their implementations in Standard C are not actually
pure, because of their behavior when invoked with out-of-range
arguments; but if we were to ignore this, we could, for instance,
take something like:

for (i = 0; i < n; i++)
a = b * asin(x);

and compile it as:

temp = asin(x);
for (i = 0; i < n; i++)
a = b * temp;

and thus call asin(x) exactly once, regardless of the value of n
(which could even be <= 0).

C compilers cannot (usually) make this optimization. The reason
is that asin(x) is not actually a pure function. Consider what
happens if the code fragment above is entered with x set to 3.14159
and n set to 0. If the compiler does call asin(x), the asin()
function will generally set errno to EDOM, which is not permitted
in Standard C. (Not in this particular case, with n==0, that is.
On the other hand, x>1.0 but n==7, a Standard C system *should*
set errno to EDOM. But note that C99 says that whether errno
becomes EDOM is implementation-defined.)

(Fortunately, a sufficiently clever C compiler can still optimize the
above -- it merely needs to test for n>0 before setting the temporary.)

A pure function can always be called any number of times (including
zero or some infinite number) without changing any program state.
Something that is not a pure function -- which, in the general
case, covers everything you can write in C or Pascal or indeed many
other languages -- cannot. There are a few languages, such as ML,
in which *everything* is a pure function, i.e., there is no such
thing as "state". Of course, "producing output" is usually an
irreversible change of state, so programs written in such languages
can never produce output either. This makes them useless -- which
means there is invariably some sort of exception to the "no state"
rule. In the purest of these languages, the sole exception is that
a complete program produces output in the form of a function return
value. Most of them have a slightly-less-pure mode, such as an
interactive command line, as well.

C tends to go quite far in the other direction: almost everything
one does in C, one does with side effects.

Incidentally, note that a random number generator function (whether
pseudo-random or really, truly random) is never a "pure" function.
Thus, any language that includes a random number function is not
"mathematically pure".

 

[Flash Gordon]

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

Well, you are flying in the face of normal usage.

Exactly. The designers of Pascal

Wirth is only one person.

> were trying to express the difference
between a function and a procedure, but did't do so in a way that is useful
to the programmer.

I don't see that there is any major problem, although I did only spend a
few years writing SW in Pascal.

Ideally a function would not be allowed to alter its arguments. So qsort
would be

void *qsort(const void *array ... etc)

taking an array as input and returning a sorted array. However efficiency
considerations preclude this.

So your definitions are not useful in the real world. That makes them
rather less useful than the definitions in Pascal.

So it doesn't actually make sense to say that a procedure cannot return a
value. Writing an image to disk is basically output, for example, but you
have to input the amount of free space left on the drive.

So functions cannot modify their parameters and return a value.
Procedures, on the other hand, can't modify their parameters and can
return a value. It does not sound like a very useful definition of
function and procedure to me.

We can't really surrender the term "function" to ANSI.

Every where else I've come across the terms function and procedure in
computing as distinct items, a function is something that returns a
value and a procedure is something that doesn't. Languages which only
have things which return a value call them functions.

> Essentially I am
using the same concept as Pascal, but defining it in a better way.
Most good ideas are inherently simple, but the implications are not
necessarily simple. I don't think anyone apart from you is accusing me of
being simplistic here, though I might be wrong.

As far as I can see your definition's can be implemented in C (as much
as they can in any language) with the following:

#define procedure
#define function

Then you can do things like:

procedure void my_procedure(int);
procedure int my_procedure_returning_int(int);
function int my_function(int);

So I can't see the use of your definition. As far as I can see the
definitions in Pascal and other languages are more useful.

 

[Joe Wright]

Flash Gordon wrote:

... snip ...



But it does have parameters, namely the global value of stdin. The
parameters just happen to be hidden from the casual user. You can
affect that global value (and thus the action of getchar) by
redirecting the programs input stream.

How would one programmatically affect the value of stdin? It is usually
#define'd as the address of a FILE structure long before run time.

You're all spinning your wheels on this procedure vs function stuff.
There is no procedure in C. Our subroutines are all functions.

In a free country, you can call a void function a procedure if you want
to. You can also call it a streetcar if you want to.

 

[Keith Thompson]

But it does have parameters, namely the global value of stdin. The
parameters just happen to be hidden from the casual user. You can
affect that global value (and thus the action of getchar) by
redirecting the programs input stream.

This must be some new meaning of the word "parameters" that I was
previously unaware of.

Yes, anything that affects the behavior of a routine can loosely be
considered to be a parameter, but the word specifically refers to the
stuff between the parentheses in the declaration. Since we're
discussing the misuse of well-known terms ("procedure" and "function"
to refer to odd concepts, it's a fairly important point.

 

[Keith Thompson]

Exactly. The designers of Pascal were trying to express the difference
between a function and a procedure, but did't do so in a way that is useful
to the programmer.

No, they did it in a way that's extremely useful to the programmer; I
certainly found it so back when I was a Pascal programmer. A function
directly returns a result, and a function call can occur as part of an
expression. A procedure does not return a result, and a procedure
call can appear only as a statement. (C, of course, doesn't make
quite the same distinction between void and non-void functions.)

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

[...]

We can't really surrender the term "function" to ANSI. Essentially I am
using the same concept as Pascal, but defining it in a better way.

No, you're not. You're using the same terms that Pascal uses, but
you're assigning different meanings to them.

I'm not just talking about ANSI. I'm talking about the nearly
universal usage of the terms "procedure" and "function" over the past
several decades.

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.

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

Note that the distinction involves side effects and global variables.
There's no mention of hardware. *All* code interacts with hardware,
at least with memory and the CPU.

Again, if you're going to make distinctions like this, *please* pick
terms other than "procedure" and "function". We know what they mean,
and it's not what you think they mean.

 

[Keith Thompson]

#include <stdio.h>

void myproc(int param) {
printf( "myproc: %d\n", param );
}

int main(void) {
int rez;
rez = (myproc(7), 42);
printf( "main: %d\n", rez );
return 0;
}


The comma operator is part of an expression.

Right. That's because myproc() is a function. C doesn't have
"procedures" in the Pascal sense; void functions are the nearest
equivalent, but there are differences.

 

[Keith Thompson]

That's a good point. The Pascal distinction is useful to the compiler
writer. My definition is useful to the programmer.

The Pascal distinction is equally useful to the programmer.

If you can specify just what distinction you're making *without*
misapplying the terms "procedure" and "function", I might be able to
decide whether your definition would be useful to programmers.

 

[Malcolm]

Again, if you're going to make distinctions like this, *please* pick
terms other than "procedure" and "function". We know what they mean,
and it's not what you think they mean.

I see what you are saying.

I think that if some silly committe that can't even come up with a language
definition that anyone wants to adopt uses the term "function", their
definition can't affect the way we use the word.

A function is something that returns a result based on a set of arguments.
The mathematical definiton goes into the "domain" in which it is defined.

So a function cannot take any action, it cannot do anything. If a piece of
code does something, it isn't a function, it is something else. The obvious
word to choose for this is "procedure".

However I do accept that the Pascal definition is in a sense a purely
syntactical one, and there is room for confusion by redefining the terms.
The problem is that the line between modifying an argument or global and
interacting with hardware is a loose one. If you write to memory-mapped
screen, is this "interacting with hardware?". What if the progrma is the
same but the monitor isn't physically attached?.

If a Pacal procedure neither modifies its arguments nor modifies globals nor
interacts with hardware, what exactly is it doing (sleep maybe)?

Can't you see that my definition essentially expresses the same idea?

 

[Keith Thompson]

I see what you are saying.

I don't think you do.

I think that if some silly committe that can't even come up with a language
definition that anyone wants to adopt uses the term "function", their
definition can't affect the way we use the word.

So you're blaming the ISO C committee for their use of the word
"function". That's not what we're talking about here. We're talking
about the consistent common use of the terms "function" and
"procedure" in the programming community for the last several decades.
It is not an arbitrary invention of the committee; it's de facto
standard terminology that probably predates the C language.

That means this discussion is arguably off-topic here, except that
something *might* come out of it that could be useful in C
programming. For example, an implementation-defined #pragma might be
used to assert that a function is "pure". The compiler can use this
information to perform certain optimizations, and to diagnose
operations within the function that make it "impure". Such a #pragma
might even be included in a future version of the standard.

That might be a useful discussion to have here, but only if we're able
to discuss it coherently.

A function is something that returns a result based on a set of arguments.
The mathematical definiton goes into the "domain" in which it is defined.

That's a mathematical function. In programming terms, it's sometimes
referred to as a "pure" function. Not all functions (in the
programming sense) are "pure".

So a function cannot take any action, it cannot do anything. If a piece of
code does something, it isn't a function, it is something else. The obvious
word to choose for this is "procedure".

However I do accept that the Pascal definition is in a sense a purely
syntactical one, and there is room for confusion by redefining the terms.

There's no room for anything other than confusion.

The problem is that the line between modifying an argument or global and
interacting with hardware is a loose one. If you write to memory-mapped
screen, is this "interacting with hardware?". What if the progrma is the
same but the monitor isn't physically attached?.

If a Pacal procedure neither modifies its arguments nor modifies globals nor
interacts with hardware, what exactly is it doing (sleep maybe)?

Can't you see that my definition essentially expresses the same idea?

No. A function that modifies its arguments, modifies global
variables, and interacts with hardware is a function. It's not a
mathematically pure function, but we're discussing software here, not
(just) pure mathematics.

Once again, the usage of the terms "function" and "procedure" is well
established.

 

[CBFalconer]

This must be some new meaning of the word "parameters" that I was
previously unaware of.

Yes, anything that affects the behavior of a routine can loosely
be considered to be a parameter, but the word specifically refers
to the stuff between the parentheses in the declaration. Since
we're discussing the misuse of well-known terms ("procedure" and
"function" to refer to odd concepts, it's a fairly important point.

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.

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

 

[Chris Croughton]

That's a good point. The Pascal distinction is useful to the compiler
writer. My definition is useful to the programmer.

Your definition is useful to no one (unless you like talking to
yourself) because everyone else already knows what the word means in the
context of programming, and has done for the last 35 years or more (IIRC
the terms 'procedure' and 'function' were around before Pascal was
created in 1968, possibly in ALGOL-60).

(I recall someone published a political essay where they defined 'right'
and 'left' the opposite way round. It was perfectly legitimate, because
they defined their terms, but also totally useless...)

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

Chris C