Re: functions with 'named' arguments

[John W. Eaton]

On  3-Apr-2008, Dupuis wrote:

| I analysed R internals, more specifically the function src/bind.c which
| provides the implementation of the c(...) function, a general-purpose
| constructor for vectors. The only input argument is the "dotdotdot"
| operator, and it returns a vector. Basically similar to "[". 
| 
| It works as follows: the internal engine receives a list built the Lipsy
| way: a set of nodes, each node made of a header and data. The header
| contains:
| - a type indicator (float, complex, expression (formula), closure,
| environment, ...)
| - an optional tag (the intended variable name, the left part of the =
| operator)
| - pointers to previous and next element
| The data is an union of the various types
| 
| This list ends with a special node serving as end-of-list marker. The
| iteration is quite simple, process the actual node, then its CDR, until the
| special marker is encountered. 
| 
| With this approach, there is no (or better: I didn't find evidence of)
| nargin function, because the list is just processed linearly. The drawback
| is that the list length is not known in advance.
| 
| As I understand,  with a function like
| function RP(x=r*cos(theta), y=r*sin(theta), r=sqrt(x*x+y*y), theta=
| atan2(x,y)) {
|   return c(x, y, r, theta)
| }
| 
| Examples of this function calls:
| - RP(3, 5) : there are data for two arguments (positional matching), then r
| and theta are evaluated.
| - RP(r = 1, theta= pi/3) : r and theta are initialised from the elements
| with corresponding tags, then x and y are evaluated. 
| What is called 'lazy loading' is just delayed evaluation of expressions,
| permitting a very concise approach in this case at the level of definition
| and default values for the arguments.

We don't need nargin to make argument lists work in Octave.  But we do
need to be able to provide a nargin function, and it must remain
compatible with the way that nargin currently works in Octave and
Matlab.  It doesn't matter what R does or doesn't do.

If you want named arguments to work in Octave, then I think you should
provide a patch that makes it work.  If you don't want to do that, or
you can't do it, then at the very least provide a propsal or how the
feature is supposed to work *in Octave*.  You don't need to get into
implementation details.  You need to explain what the syntax and the
semantics of the feature should be.  Your proposal must not break the
current semantics of nargin, as doing that would break too much
existing code.  If you provide a complete proposal for how the feature
is supposed to work, then perhaps someone else who can implement it
will agree that it is a useful feature and do the work to prepare a
patch.

jwe