Re: "procedure" vs. "function"

[J Martin Rushton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 18/04/15 20:41, PMA wrote:
> PMA wrote:
>> Jacques Menu wrote:
>>> Hello,
>>> 
>>> Yes, historically a disctinction was made between the «
>>> sub-programs » that return a value and those that don’t, but
>>> the Scheme docs seem to use the terms function and procedure
>>> interchangeably.
>>> 
>>> In C++, everything is a function : a procedure is merely a
>>> function that returns a value of the « void » type, i.e. no
>>> value.
>>> 
>>> JM
>>> 
>>>> Le 18 avr. 2015 à 18:33, David
>>>> Nalesnik<address@hidden> a écrit :
>>>> 
>>>> 
>>>> 
>>>> On Sat, Apr 18, 2015 at 4:51 AM, Urs 
>>>> Liska<address@hidden<mailto:address@hidden>> wrote: 
>>>> Hi all,
>>>> 
>>>> I just stumbled over a terminology issue: are "procedure"
>>>> and "function" synonyms in Scheme or do they refer to
>>>> different things?
>>>> 
>>>> From my earliest experiences with programming I'd recall the 
>>>> difference to be that functions return a value and procedures
>>>> don't. But that's clearly not the case in Scheme.
>>>> 
>>>> Any enlightenment available?
>>>> 
>>>> Well, I'm guilty of using them interchangeably...
>>>> 
>>>> Anyway, maybe the following will help -- or add to the
>>>> confusion :)
>>>> 
>>>> http://stackoverflow.com/questions/721090/what-is-the-difference-be
tween-a-function-and-a-procedure<http://stackoverflow.com/questions/7210
90/what-is-the-difference-between-a-function-and-a-procedure>
>>>>
>>>>
>>>>
>>>>
>>>> 
DN
>>>> 
>>>> _______________________________________________ lilypond-user
>>>> mailing list address@hidden 
>>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________ lilypond-user
>>> mailing list address@hidden 
>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>> Hi List --
>> 
>> AFAIK, of our major ancestor languages, only Pascal insisted on
>> a literal working function-vs-procedure distinction. Did Wirth
>> ever defend this insistence (as more than a track-keeping
>> enforcer re value-outputting vs non-value-outputting code)?
>> 
>> PMA
> P.S.  Did he intend a "function" to embody purely a single
> mathematical function (one too fussy to be a command primitive), or
> were the innards to be open to other code as well?  And if the
> latter, did he consider that a growing incorporation of such code
> might well smush the boundaries of his original func-vs-proc
> distinction (which, clearly, hasn't caught on)?
> 
> PMA
> 
> _______________________________________________ lilypond-user
> mailing list address@hidden 
> https://lists.gnu.org/mailman/listinfo/lilypond-user

FORTRAN also insists on the distinction (at least officially).  In
FORTRAN you CALL procedures as a single statement whereas you simply
use functions in an expression.  If you try to mix them the compiler
_ought_ to throw the syntax out.  Likewise BASIC distinguishes between
GOSUB and invoking a function in an expression.

Consider writing a procedure to perform a task.  If this is invoked as
a function then what is the return value?  It might be anything that
was left in the register used to pass the value back; worse, if
returning by reference then you could be interpreting random data as
an address!  Modern compilers often trap this by zeroing the return
value, but you can't rely on it.

You also need to keep in mind that the syntax checking of 2 & 3 GLs
was not as extensive as modern languages like C/C++.  Pascal, in
particular, was designed as a single pass language so that cards or
tape could be read in, passed sequentially through the compiler and
the object code stored to tape.  In the 1970s even mainframes often
only had 128 KiB of memory.  Saving a few machine instructions may
seem trivial today, but major programs were often only kibibytes in
length in the 1960s.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVMrutAAoJEAF3yXsqtyBlzUoQAJI6tW8DRAdVttjEE6Vod5q5
mmzOLCYnHx9JLHx5iaUwrwaNInYE50tHeEm9ik477L1YeLEAryM9gGt/Rv1L9D8c
A4t32nmC2VsjR381Pgf6gND1SlElq9DBP0QZ9cO0acwVJIXto19LvlghfD5O3wR6
m1JCSbiZKsgJqjbw9IdqNiYNo+nB6838ZuAGxjIe/xrxmdYkddP7ROquCk2KMZF2
zkwI2KSV1fONQZSmtsPdVzkqw1HecG4j5Dz7X9V3CxADg80f6S9WAewth8fhyBS6
pDcM7A3nLNTLaQSXObBiEFeiGrC8xEEeqBc5IgDXm+qBnNL8fQvLPhZdA0BbQ8cT
1DPUB6BWWXguL3jy5Uwdj7z3id5E8Zb6P/abkxo6gSaD7ksT/05IBKRUnyc2NSVx
NmE1I3FiQGbBhXa0M+WclYK2541/kJ/EbUajLoxbqeX5r0/UxqI6uJjJlazRF9f/
O6uXrYX6eDmDUhbg6BDxLOLVFuMtUMaJmLbF1iASPgEPh8ADpihqXfRYMeHJ+n+G
U7rpb83k2rFkv8R/+eLM5FYeLEgF6eOD8nzQeLoB4UVr4q+jGmZ5nahLuDFI6jua
2lA8jYnWVi+DOh1K0texBg6cQzmormKsEWtltKZjt3g32tP3yuGZ/iqFmx8Jwfqt
Lcx1P+avbZYIPY1G/WPR
=0L+q
-----END PGP SIGNATURE-----