Re: functions with 'named' arguments

[Jaroslav Hajek]

On Wed, Mar 19, 2008 at 10:31 AM, Dupuis <address@hidden> wrote:
>
>
>
>  Jaroslav Hajek-2 wrote:
>  >
>  > Indeed. But in Octave (and C,C++) it would create a syntax clash.
>  >
>
> > Perhaps. Unfortunately, it would also add a level of confusion for
>  > those not used to
>  > keyword argument calls, but used to assignment expressions.
>  >
>  >
>  For the first remark: a grep on all files under /usr/share/octave/3.0.0/
>  showed that the pattern
>  '([^<>!=)]*=[^=)]*)' is only found within strings or if clauses. So the
>  pattern of default arguments seems not yet used inside Octave sources.
>

I didn't mean it was used in Octave itself. Even if it was, that could
easily be remedied. Still, there may be many scripts out there using
this construct.

>  For the second remark: after reading a R tutorial, the notion doesn't look
>  confusing at all.
>

Nor does it seems after reading a Python tutorial or Fortran (95)
tutorial. It is even simulated in the Boost library for C++ (though I
doubt it is used much).

>  Now for some more substancials comments. A possible target for this 'named
>  arguments' paradigm is low-level functions. That is, functions which are
>  called often. Using such paradigm within the octave interpreter means faster
>  execution. Using parseparams means more code, more function calls, more
>  computer cycles, and so forth.
>  My vision is that this named argument paradigm brings a level of simplicity.
>  You have f.i. to cope with various statistical functions, you know they have
>  parameters called 'mean' and 'sd'.  You just construct  the calls this way:
>  somefunc(mean = this, sd = that). The interpreter will perform the matching.
>  So if you have two sets of functions written by two teams with different
>  calling conventions, you don't have to construct the call accordingly and
>  use either if construct either eval(). Handled within the Octave
>  interpreter, it's faster.

Yeah, no objections to that. No doubt it would be faster than using
cell arrays (& parseparams), but the question is how faster. I'd say
that unless someone implements
this and evaluates the speed improvements, this is too little of an argument.
Further, even if you did, one can as well implement parseparams as a
built-in or DLD,
and I bet it would be a competitive speed improvement (but much
smaller scale change).

>
>  Regards
>
>  Pascal
>  --
>  View this message in context: 
> http://www.nabble.com/functions-with-%27named%27-arguments-tp16095584p16141847.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