Function definition: Difference between revisions

From Rosetta Code
Content added Content deleted
(Added Forth)
(-> Tcl)
Line 60: Line 60:
12
12
</pre>
</pre>

==[[Tcl]]==
[[Category:Tcl]]

Strictly as descried in the task:

proc multiply { arg1 arg2 } {
return [expr $arg1 * $arg2]
}

But I'm not sure anybody would write it that way. If nothing else, there's no reason to prefer scalar arguments. And it is unclear why one would impose a limit on the number of arguments. I would write this like this:

proc multiply { args } {
return [expr [join [join [join $args]] *]]
}

This will accept one or more arguments which can be scalars or lists (or even nested lists) and returns the product of all of them. E.g.

% multiply "1 2" {3 4} [list 5 6] {{7 8} 9}
=> 362880




=={{header|Toka}}==
=={{header|Toka}}==

Revision as of 17:32, 20 September 2007

Task
Function definition
You are encouraged to solve this task according to the task description, using any language you may know.

A function is a body of code that returns a value. The value returned may depend on arguments provided to the function.

Write a definition of a function called "multiply" that takes two arguments and returns their product.

Ada

function multiply(a : float; b : float) return float is
begin
   return a * b;
end multiply;

C

double multiply( double a, double b )
{
  return a * b;
}

Forth

: multiply ( a b -- c )  * ;

MAXScript

fn multiply a b =
(
    a * b
)

Perl

sub multiply( $$ )
{
  $a = shift;
  $b = shift;
  return $a * $b;
}

PHP

function multiply( $a, $b )
{
   return $a * $b;
}

Python

Named function:

def multiply(a, b):
    return a * b

Unnamed function:

multiply = lambda a, b: a * b

A callable - may be useful to allow both simple functions and complex classes to use the same interface:

>>> class Multiply:
...     def __call__(self, a, b):
...             return a * b
... 
>>> multiply = Multiply()
>>> multiply(3, 4)
12

Tcl

Strictly as descried in the task:

proc multiply { arg1 arg2 } {
   return [expr $arg1 * $arg2]
}

But I'm not sure anybody would write it that way. If nothing else, there's no reason to prefer scalar arguments. And it is unclear why one would impose a limit on the number of arguments. I would write this like this:

proc multiply { args } {
   return [expr [join [join [join $args]] *]]
}

This will accept one or more arguments which can be scalars or lists (or even nested lists) and returns the product of all of them. E.g.

% multiply "1 2" {3 4} [list 5 6] {{7 8} 9}
 
=> 362880


Toka

[ ( ab-c ) * ] is multiply