polymorphism in functions

[John W. Eaton]

On  8-Jan-2004, Pascal A. Dupuis <address@hidden> wrote:

| One possible solution is to use a formalism of named arguments, like
| in R: 
| 
| %# default number of bin, distribution = gaussian (default)
| result=myfunc(x, mu = someval, sigma = someotherval)
| %# specify explicitelly the threshold 
| result=myfunc(x, sigma = someotherval, threshold=[-3:.5:3])
| %# specify explicitelly the number of bins
| result=myfunc(x, mu = someval, nbin=16)
| %# gives precomputed threshold and expectations for a uniform pdf over 0:1
|  result=myfunc(x, threshold=[.1:.1:.9], expected=(ones(1,10)*length(x)/10))
| 
| So you get an idea of the flexibility. At the program level, things
| are rather simple:
| - if one of (threshold, expectation) is given, compute the other one
| - if none is given, compute both based on mu, sigma, and distribution
| type
| 
| The prototype for such a function would f.i. be:
| 
| function p = myfunc(x, [ mu = 0, sigma=[], threshold=[], expected=[],
|                   nbin = 8, type='gaussian']);
| 
| The named arguments are placed inside a [], and are of the form 
| name=default_value;

This type of feature has been discussed a number of times in the last
10 years, but so far no one has done the work to implement it.

The above proposal won't work because things like

  result=myfunc(x, threshold=[.1:.1:.9], expected=(ones(1,10)*length(x)/10))

are already valid in Octave (but not Matlab, where assignments are not
expressions).  So you would at least need to introduce a new
operator.  Perhaps := instead of =.

For the function definition, what you have is probably OK, but I don't
really see the point of having the additional [], except if you also
implement default values for positional arguments, then the extra []
would separate named arguments from the positional arguments.  Also, I
would probably want to use := (or whatever operator is chosen for the
function call) instead of just = so that they match.

| To build the function invocation at compile time, the steps are:
| 1) create and initialize the variable arguments with default values,
| 2) parse the argument list, and, with pairs of type LHS = RHS,
| evaluate the RHS and store the result in the variable whose name is
| given is LHS. This need to be performed only once if the LHS are
| constant.

I don't think you can do it just once unless you also modify Octave's
interpreter to determine that the values of the named arguments are
not modified somewhere in the function body.

I think I would implement it by making the following change to the way
function calls are evaluated:

  For each NAME := EXPR pair:

    evaluate EXPR to produce a VALUE

    add the NAME and VALUE pair to a list of named arguments to pass to
    the function

  Pass the list of NAME and VALUE pairs to the function eval code in
  addition to the normal argument values.  The function eval code
  would need to be modified to handle overriding default values given
  the list of NAME and VALUE pairs.

| Advantages:
| -more flexibility in the way the function works;
| -ability to add supplemental variables arguments without breaking
| compatibility with previous scripts
| -safer to program; doesn't require a lot of (dynamic) tests to decide how to
| take the arguments into account.

OTOH, maybe the style of programming where a single function can
accept many different argument lists (named or otherwise) is just bad
form because it complicates the language?

| Problems:
| -code a bit bigger
| -each function invocation will be translated into an initial code
| performing the variable setup, followed by a call to the function
| core.

Another problem is additional complexity of the language.  Is it
really needed?

And, as always, another problem with extensions like this is that they
cause trouble for us later if the MathWorks later decides to do
something similar, or to use the new operator that we choose (:=) for
another incompatible purpose.  Of course, since assignments in Matlab
do not produce values, they could use your proposal as-is, and if we
wanted to make Octave compatible, we would have to abandon the idea of
assignment-as-an-expression in Octave.

jwe