Re: functions with 'named' arguments

[Jaroslav Hajek]

On Tue, Mar 18, 2008 at 3:01 PM, Dupuis <address@hidden> wrote:
>
>
>
>  Jaroslav Hajek-2 wrote:
>  >
>  >
>  > What I'm trying to explain is that
>  > hello(closing='bla') already *has* a meaning in Octave, and it is
>  > *not* what you have
>  > on mind. In R, this is no problem because the assignment is not "=".
>  > In Fortran and Python, this is no problem because assignment is not an
>  > expression (not sure about Python, but I think so).
>  >
>  > It is perfectly legal in Octave (and sometimes useful) to write things
>  > like
>  > x = exp (y = -y)
>  > A possible solution would be to implement keyword arguments using
>  > different character than "=", but I think that the standard workaround
>  > using a cell array (of the form {"name", value, "name", value}) is
>  > already good enough.
>  >
>
>  OK, I see more clearly the point. In R, "=" is an assignment operator, which
>  can be used at top level, or as a subexpression in a braced list of
>  expression.
>
>  My opinion is that having an assignment of an variable expressed in the
>  middle of a function call is a bit strange.
It is simply modelled after C and its descendants - C++, Java, D, JavaScript ...
There are a lot of syntactic features of C/C++ that may be considered strange.
Still, many programmers are used to them.

> OTOH, the semantic meaning
>  "initialize the function parameter with the corresponding name" makes more
>  sense.
... to you.

> If you look at R, Python or Perl, this adds a level of clarity, both
>  for the programmer, because the bindings are performed automatically, and
>  for the user, because each arguments and their default value are evident
>  from the function definition.
>

Indeed. But in Octave (and C,C++) it would create a syntax clash.

>  With the list of names and values approach, and given the availability of
>  functions like "parseparams", it is up to the programmer to test for valid
>  and invalid cases. From the user perspective, default values and allowed
>  names are to be searched for inside the function body.
>

Not really. They should be documented in the function's inline documentation,
and in good functions, they will be. And notice that there may be more
complicated
rules than a simple expression. (like: "if x is not present but y is
supplied, x is calculated via the following formula ....)

>  So, having named args 'à la Python/R/...' would add a level of clarity.

Perhaps. Unfortunately, it would also add a level of confusion for
those not used to
keyword argument calls, but used to assignment expressions.

>  Regarding the other use, i.e. mixing variable assignment and function call,
>  this can be accomplished by x = exp((y=-y)) : the parens ensure the
>  assignment is performed first, and the "return" value, the new assigned var,
>  used as function parameter.
>

Sure, it's a workaround. The cell array is a workaround for keyword arguments.

>  I insist on this because I was Java programmer in a previous life, and
>  dealing with objects usually means playing with a lot of so-called
>  attributes. To this end, objects were created, and numerous calls were
>  performed to modify attributes one-by-one. This was a nightmare to devise
>  and to use. Later, I had opportunities to touch Python scripts, and found
>  their approach of named args cleaner and safer.
>
>  Greetings
>
>  Pascal
>  --
>  View this message in context: 
> http://www.nabble.com/functions-with-%27named%27-arguments-tp16095584p16121881.html
>
>
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>
>
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz