forum-msg-id-133357-edit

Original date:2019-01-05 13:42:20 Edited by: ChrisB Subject: Re: Procedure, function and return

  • 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 more more difficult to read.

_tom

Not Categorized, Please Help

Search



Quick Links

User menu

Not signed in.

Misc Menu