Re: Default arguments

[Paul Kienzle]

On Dec 15, 2006, at 12:39 PM, John W. Eaton wrote:

> On 15-Dec-2006, Sean O'Rourke wrote:
>
> | I would propose that only arguments with default
> | values can be passed using keywords, since non-optional
> | keyword arguments are just strange.  That way there's
> | no impact on existing functions.
>
> OK, this makes sense.  I don't know why I was thinking
> that it would be meaningful to have keyword arguments
> without default values, since keyword arguments are of
> course intended to be optional.

The reason it may be used is for functions with a
large number of arguments, all of which are required.
The var:=value syntax makes it so that the user
doesn't have to remember the particular order. It also
serves a documentation function for future readers.
Even if there are only two parameters (e.g., lambda
and dims for a poisson distribution) it is convenient
if you don't have to remember which order they are in.

> In any case, I do agree that the maximum mixture of
> varargin, default values, and keyword arguments could
> make a real mess.  But these features are already
> used in some way or another.  So I don't see that
> we are adding complexity here.  Really, we are just
> making it more manageable because you currently have
> to do extra work to handle default values and keyword
> arguments.  Whatever.  If you want to take a shot at
> implmenting keyword arguments, please do so.  I'd
> consider a patch. Please use ':=' as the new operator
> for the function call.

You may want to define a new automatic variable to
collect extra keyword arguments (e.g., kwargin).  This
should be a struct so that you can access them easily.

This would allow you to write the struct() constructor
as:

  struct(a:=1,b:='hello',c:=[3,4,5])

which I find more readable than:

  struct('a',1,'b','hello','c',[3,4,5])

From there it is a small step to syntactic support
for structures (from the user's perspective at least):

  { a:=1, b:='hello', c:=[3,4,5] }

If you support unnamed keyword arguments, you will
want to be able to send them along to other functions.
That means extending struct so that it accepts {}
indexing, allowing you to write e.g.,

  function [varargout] = myf(varargin,kwargin)
    disp('Extension to function f');
    [varargout{:}] = f(varargin{:},kwargin{:});
  endfunction

To decide if you really want these features you
should talk to users of e.g., R and Python to
see if they help write maintainable code or make
it harder.  I know I found it convenient to be
able to hand off all the keyword arguments to
the underlying plot command when defining new
plotting functions without having to know ahead
of time what they are.

- Paul