Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > return values

Reply
Thread Tools

return values

 
 
Uno
Guest
Posts: n/a
 
      01-23-2011
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
 
Reply With Quote
 
 
 
 
Uno
Guest
Posts: n/a
 
      01-23-2011
On 1/22/2011 9:12 PM, Sherm Pendley wrote:
> Uno<(E-Mail Removed)> writes:
>
>> What doesn't return a value in C?

>
> 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.
--
Uno
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      01-23-2011
On Jan 23, 3:53*am, Uno <(E-Mail Removed)> wrote:

<snip>

> 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.
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      01-23-2011
Sherm Pendley <(E-Mail Removed)> wrote:
> Uno <(E-Mail Removed)> writes:
>
> > What doesn't return a value in C?

>
> 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.)
--
Larry Jones

I've got to start listening to those quiet, nagging doubts. -- Calvin
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      01-24-2011
On Jan 23, 5:26*pm, Nick Keighley <(E-Mail Removed)>
wrote:
>
> 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().



 
Reply With Quote
 
Hans Vlems
Guest
Posts: n/a
 
      01-24-2011
On 23 jan, 16:26, Nick Keighley <(E-Mail Removed)>
wrote:
> On Jan 23, 3:53*am, Uno <(E-Mail Removed)> wrote:
>
> <snip>
>
> > 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.


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
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      01-24-2011
On Jan 24, 2:04*am, Hans Vlems <(E-Mail Removed)> wrote:
> On 23 jan, 16:26, Nick Keighley <(E-Mail Removed)>
> wrote:
> > 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).



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)
 
Reply With Quote
 
Uno
Guest
Posts: n/a
 
      01-26-2011
On 1/24/2011 11:54 AM, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On Jan 24, 2:04 am, Hans Vlems<(E-Mail Removed)> wrote:
>> On 23 jan, 16:26, Nick Keighley<(E-Mail Removed)>
>> wrote:
>>> 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).

>
>
> 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.
--
Uno
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      01-27-2011
On Jan 26, 2:32*am, Uno <(E-Mail Removed)> wrote:
> On 1/24/2011 11:54 AM, (E-Mail Removed) wrote:
>
>
>
>
>
> > On Jan 24, 2:04 am, Hans Vlems<(E-Mail Removed)> *wrote:
> >> On 23 jan, 16:26, Nick Keighley<(E-Mail Removed)>
> >> wrote:
> >>> Some languages (eg. pascal) distinguish between functions thatreturn
> >>> 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
> >>returnavalue.
> >> I can't remember whether Fortran IV had subroutines that returned a
> >>value(IIRC they couldn't).

>
> > Statement functions and functions subprograms couldreturnvalues.
> > 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 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Unpack less values from function's return values Chris Rebert Python 1 05-28-2009 02:47 PM
what value does lack of return or empty "return;" return Greenhorn C Programming 15 03-06-2005 08:19 PM
difference between return &*i and return i; Ganesh Gella C++ 4 11-12-2004 04:28 PM
How do I return a return-code from main? wl Java 2 03-05-2004 05:15 PM
Return a return value from Perl to Javascript PvdK Perl 0 07-24-2003 09:20 AM



Advertisments