Option 1
"Parameters" section with optional is clause.
function logarithm is real:
parameters:
number is real. -- The number to find the log of.
base is real. -- The logarithm
base.
preconditions:
number > 0.
base >
1.
return {some
calculation}.
Pros:
- Putting each parameter declaration on its own line allows comments to be attached to each parameter.
- Parameters may be untyped.
- Polymorphism on parameter types possible.
Cons:
- Looks ugly for untyped parameters. Uses too much space.
Option 2
Inline parameters with optional parameters section.
function logarithm(number,
base) is real:
parameters:
number is real. -- The number to find the log of.
base is real. -- The logarithm
base.
preconditions:
number > 0.
base >
1.
return {some
calculation}.
Pros:
- Compact syntax for untyped parameters.
Cons:
- Can't annotate untyped parameters with comments.
Option 3
Inline parameters with parameter types specified as requirements.
function logarithm(number,
base) is real:
requires:
number is real.
base is real.
preconditions:
number > 0.
base >
1.
return {some
calculation}.
Pros:
- The requirements on parameter types are more flexible. Parameters need not even have explicit types; they could be generic, or simply left under-constrained if it's too difficult to express strict constraints on the parameters.
- Compact syntax for untyped parameters.
Cons:
- It's difficult to annotate parameters with comments.
- Difficult to provide type-based polymorphism.
Alternative
More generalized polymorphism. Right now polymorphism in OO languages selects the most "specific" function based on which function has the most specific type specifications. Generalized polymorphism would select the function with the most specific constraints (requirements). Determining if a set of constraints is more specific than another may be difficult or impossible in general, though...