return values

[Uno]

I swear to God that I didn't invite clc to my party, but here you are.

So, now that the lingua franca is the yatik of ritchie, I'd like to
contrast many features to syntaxes that were formed primarily with an
eye toward C, as opposed to being C itself.

I'm reading _Learning Perl_ right now, and I think to understand that
perl "always returns something" is what perlfolks think is an important
feature to their language.

What doesn't return a value in C?

Peace. Love. MLK

 

[Uno]

Functions that are explicitly declared as returning void.

Right.

Your C compiler will emit a warning if a non-void function lacks a return
statement.

sherm--

Ok. Dankenstein.

 

[Nick Keighley]

So, now that the lingua franca is the yatik of ritchie, I'd like to
contrast many features to syntaxes that were formed primarily with an
eye toward C, as opposed to being C itself.

I'm reading _Learning Perl_ right now, and I think to understand that
perl "always returns something" is what perlfolks think is an important
feature to their language.

What doesn't return a value in C?

anything marked as "returning" void?

Some languages (eg. pascal) distinguish between functions that return
something and procedures that don't. Traditionally in mathematics a
function doesn't have side effects as there is nothing to have side
effects on. I think the aim of the Pascal function/procedure
distinction was that functions should be without side effects (ie.
don't modify the program state or do i/o). Whilst procedures modified
the environment and/or do i/o. But I don't believe Pascal enforces
this distinction. It's supposed to be a lot easier to prove things
about programs that lack side effects. But practically its hard to
write useful programs that lack side effects. Take a look at a
functional language (that doesn't just mean "has functions") or
prolog.

 

[lawrence.jones]

Functions that are explicitly declared as returning void.

Statements.

(Technically, operators don't return values, they yield results, but
that's probably not a significant difference in this context.)

 

[Malcolm McLean]

Some languages (eg. pascal) distinguish between functions that return
something and procedures that don't. Traditionally in mathematics a
function doesn't have side effects as there is nothing to have side
effects on. I think the aim of the Pascal function/procedure
distinction was that functions should be without side effects (ie.
don't modify the program state or do i/o).

There's not an important distinction between

void foo(int *xret)

and

int foo(void)

except at the level of grammar - we can say

if(foo())

in the second case but not in the first. So really it's not helpful
from a software engineering perspective to think in terms of functions
as procedures with a non-void return type.

The side-effect distinction, however, is very important, but hard to
nail down. For instance sqrt() is the paradigm of a function, but in C
it sets errno if passed a negative, so not a pure function. Most code
will never test errno, however, so we can't usefully say a function
becomes a procedure because it calls sqrt().

 

[Hans Vlems]

anything marked as "returning" void?

Some languages (eg. pascal) distinguish between functions that return
something and procedures that don't. Traditionally in mathematics a
function doesn't have side effects as there is nothing to have side
effects on. I think the aim of the Pascal function/procedure
distinction was that functions should be without side effects (ie.
don't modify the program state or do i/o). Whilst procedures modified
the environment and/or do i/o. But I don't believe Pascal enforces
this distinction. It's supposed to be a lot easier to prove things
about programs that lack side effects. But practically its hard to
write useful programs that lack side effects. Take a look at a
functional language (that doesn't just mean "has functions") or
prolog.

Algol recognizes the reserved word procedure, and a procedure may
return a value.
I can't remember whether Fortran IV had subroutines that returned a
value (IIRC they couldn't).
In Algol the difference is obvious to the compiler. So there was no
linguistic need to use different reserved words
to make that clear to the compiler. Pascal makes the difference
because it specifies the object type at the end of a declaration.

Algol Pascal C
INTEGER PROCEDURE SUM(..); function sum(..):integer; int
sum(..)
PROCEDURE DOTHIS(..); procedure dothis(..); void
dothis(..)
INTEGER GETAL; var getal:int; int
getal;

I guess that the decision to put the type of a variable at the end of
the declaration in Pascal forced the need
to alert the compiler what was coming. C followed Algol and put the
type in fornt of the variable list. Which is
IMHO a more natural way of doing things.
Other than that there is no other difference. It is perfectly alright
to perform IO in functions. And procedures
can return fascinating results via parameters, e.g. Jensen's device.
Basically the motto of Algol60 explains it all: Was sich überhaupt
sagen lässt, lässt sich klar sagen (Wittgenstein).
Which probably explains why Algol remains my favourite language ;-)
Hans

 

[robertwessel2]

Algol recognizes the reserved word procedure, and a procedure may
return a value.
I can't remember whether Fortran IV had subroutines that returned a
value (IIRC they couldn't).

Statement functions and functions subprograms could return values.
Statement functions being more similar to a Basic DEF FNx than
"proper" subroutines:

DOMULTIPLY(A,B)=A*B
...
X=DOMULTIPLY(Y,Z)

And function subprograms:

FUNCTION DOMULTIPLY(A,B)
C Yes, this doesn't handle fractional B's as you'd expect
DOMULTIPLY=0
DO 10 I=1,B
10 DOMULTIPLY=DOMULTIPLY+A
RETURN
END
...
X=DOMULTIPLY(Y,Z)

 

[Uno]

Statement functions and functions subprograms could return values.
Statement functions being more similar to a Basic DEF FNx than
"proper" subroutines:

DOMULTIPLY(A,B)=A*B
...
X=DOMULTIPLY(Y,Z)

And function subprograms:

FUNCTION DOMULTIPLY(A,B)
C Yes, this doesn't handle fractional B's as you'd expect
DOMULTIPLY=0
DO 10 I=1,B
10 DOMULTIPLY=DOMULTIPLY+A
RETURN
END
...
X=DOMULTIPLY(Y,Z)

thx, Robert, that's syntax I know.

I guess what I wonder is why the feature of
"always returning a value"
might be considered to be better than a bug.

 

[robertwessel2]

thx, Robert, that's syntax I know.

I guess what I wonder is why the feature of
"always returning avalue"
might be considered to be better than a bug.

Don't know. If there's nothing to return, how would it be better to
return something meaningless or arbitrary? At least for an imperative
language like C. A stronger case is obvious for purely functional
languages, where functions don't have any side effects (and a function
not returning anything isn't actually doing anything either - although
there the definition of "returned" ends up being a little different).

OTOH, always returning a value allows you to call the function from
within a statement, as opposed to a standalone call, although in C the
comma operator often allows you to do that anyway. But I'm not sure
how much utility that actually has.