1. Procedure, function and return
- Posted by alrobnett Jan 05, 2019
- 1221 views
The distinction between procedure and function is muddy in my mind. The 4.1 manual says that a procedure performs a computation and then gives an example of puts-ing to the screen. I have two basic questions:
Is a return required to keep a stack from getting confused and even over-loaded?
If a procedure or function operates on a global variable is there any need to return a result as opposed to simply using the global variable?
2. Re: Procedure, function and return
- Posted by ChrisB (moderator) Jan 05, 2019
- 1229 views
Hi
For simplicity.
A function always returns something.
A procedure doesn't return anything.
Both are subroutines
example
function add2numbers(integer a, integer b) return (a+b) -- must have a return in a function end function c = add2numbers(3,4) -- c is returned from the function ? c -- ? is shorthand for quick and dirty print procedure subtract2numbers(integer a, integer b) ? (a-b) -- ? is here, as no value is returned return -- this return is optional end procedure subtract2numbers(9,12) -- nothing is returned from the procedure --there is a twist, but you don't need this for now - keep it simple
As far as global variables go, funtions and procedures both operate on them, and the result remains global so they can be read wherever in the program. But try to discipline yourself to avoid using them, as using local variables (to the function or procedure) can make your code easier to read. I freely admit in some cases it is just easier to use global variable (eg flags across several functions), but signify them with a global name - form your own convention to recognise the globality (is that a word) - for instance all capitals, or prefixed with G_ etc.
Cheers
Chris
fixed a typo, _tom And another 2 fixed! - Chris
3. Re: Procedure, function and return
- Posted by _tom (admin) Jan 05, 2019
- 1215 views
- A procedure "performs actions."
- A function "is a value; because it has a return statement."
If a procedure changes the value of a global variable then that may be described as "bad" programming. If a function changes values and does non obvious actions then that is also described as "bad" programming.
Euphoria ( oE and Phix) is sharp by design. A procedure just performs actions. A function must contain a return statement and must return a value. There is a clear distinction; it makes the intent of a routine obvious. The interpreter catches sloppy programming.
( Function may change a global variable within its code block (see bad programming), but it must also always return some value.)
Euphoria ( oE and Phix ) is sharp by design. To change the value of any variable you must use an assignment statement. You can not write code that makes it difficult to find out how some value changes. The interpreter, again, catches sloppy programming.
Arguments are pass-by-value; a value is copied into a routine (procedure or function). A value passed into a routine is never altered in the main program; this means no surprise changes in values. Think sharp, no surprises, no changes without explicit assignment.
If you have a global variable then its value may be changed anywhere as long as there is an obvious explicit assignment statement. You can change a global variable within a procedure or a function. When a routine changes a value outside of its code block this change is described as a "side effect". (Side effects make debugging more difficult; side effects are considered to be "bad" programming.) Thus, the Euphoria way is to use a function that returns a value and avoid writing code with "side effects."
[Functional programming languages are designed to work with no side effects; see Haskel]
Some languages allow an argument to be pass by reference. When this is allowed, a change to an argument passed into a routine changes its value outside of the function block. This makes debugging more difficult.
An excuse for allowing pass by reference is that is is more efficient. In the case of Euphoria ( oE and Phix ) there is an internal pointer mechanism that does not actually create copies of values passed into a routine. Routines behave like pass-by-value but perform like pass-by-reference. Only if a value is changed within a routine does actual copying of values start. The Euphoria way is both fast and secure.
You can use a function to return just an error code. In this case a function may be designed to just perform some action (like a procedure). The error code is used to confirm that an action took place correctly.
oE allows you to discard a function value quietly. This is contrary to the original Euphoria language design. Phix continues the correct way of using functions. A function value must always be used or assigned. To discard a value in Phix you write
{} = myfunc( "foo.txt" )
In a dull language (see most any popular language) you will realize that a "function" is a sloppy construct. It may perform one of two services (procedure or function); it may promote side effects; argument passing may be sloppy. Dull languages are more difficult to debug; they are more difficult to read.
_tom
edit - couldn't resist - fixed a typo - Chris
4. Re: Procedure, function and return
- Posted by petelomax Jan 05, 2019
- 1177 views
A quick note on global variables/side effects and "bad" programming:
Imagine your program was like a kitchen, and global variables are like the kitchen floor. Now some things actually deserve to be left on the kitchen floor, like a dustpan & brush, that massive box of washing powder, a mousetrap, and nobody cares much. But now imagine storing everything in your kitchen on the kitchen floor, and likewise it is not "some" global variables and side effects, it is "too many" that makes it "bad", and as your program grows the only sensible approach is to try very hard to make it "as few as possible".
5. Re: Procedure, function and return
- Posted by irv Jan 06, 2019
- 1160 views
I usually think of it this way:
A procedure is handy when I find myself needing to do something more than once, and would rather not write out the same code multiple times (with the possibility for making multiple errors). A return is never required, and there are only a few instances where a return makes code simpler.
A function always requires a return (but you aren't obligated to use it). Is that "bad programming" ? Well, the alternative, if your program sometimes needs to use the return value, and sometimes doesn't need to use it, would be to clutter your code with dummy assignments:
object junk = myfunc(x)
While that construct makes it plain to the reader that you are discarding the return value, it also looks like you didn't plan things out as thoroughly as a "good programmer" would have done.
Modifying global variables inside functions or procedures is great - by that, I mean a great way to introduce hard-to-find "bugs" that can occur randomly and unpredictably. It's also a great way to obfuscate your code, so that no one (including yourself) can easily figure out what is going on.
6. Re: Procedure, function and return
- Posted by alrobnett Jan 06, 2019
- 1190 views
Thank you all, gentlemen. I will take your comments to heart and try to program sharp-ly.
7. Re: Procedure, function and return
- Posted by petelomax Jan 08, 2019
- 1171 views
This fairly nice article just appeared in my inbox, and I thought of this thread:
https://www.codeproject.com/Tips/1265519/10-Small-Tips-for-Better-Code-Readability
