Re: lvalue list optimizations

[Jaroslav Hajek]

On Thu, Aug 5, 2010 at 8:25 PM, John W. Eaton <address@hidden> wrote:
> On  5-Aug-2010, Jaroslav Hajek wrote:
>
> | Yes, definitely. I'd define DEFUNL(name, args, nargout, lvalue_list,
> | docstr) and have DEFUN call DEFUNL with empty lvalue_list name, so
> | that the corresponding parameter would end up unnamed. However, the
> | actual signature of all DEFUNs would change from
> | octave_value_list (*) (const octave_value_list&, int)
> | to
> | octave_value_list (*) (const octave_value_list&, int, const
> | std::list<octave_lvalue> *)
> |
> | i.e. code that relies on the former signature will no longer work
> | (code using the octave_builtin::fcn typedef will work). Additionally,
> | this will mean that there will be zero binary compatibility between
> | 3.2.x and 3.4.x. I don't think that matters, however.
> |
> | what do you think?
>
> Could the new argument be a reference instead of a pointer?
>

No. Null pointer is a valid case used when no lvalue list is formed
for the call.

> We never promised that using anything but DEFUN would work, so I don't
> see a significant problem.  We already don't have binary compatibility
> with 3.2.x so that doesn't matter.
>
> OTOH, maybe we can preserve the old interface?  What about something
> like
>
>  #define DEFUNL_INTERNAL(name, args, nargout, lvalue_list, docstr) \
>     inline DECLARE_FUN (name, args, nargout) \
>     { \
>       return F ## name (args, nargout, 0); \
>     } \
>     DECLARE_FUN_LVAL (args, nargout, lvalue_list)
>
> so that old and new signatures can both continue to work?  But this
> would only matter for people who have code that calls built-in
> functions directly, without feval, which is something we've always
> discouraged, so I don't see it as something that has to be done, and
> maybe it is just not worth the additional complexity.
>

This is a good workaround when Fxxx functions are called directly;
however, you still only want to store one pointer in octave_builtin,
and that will need to be the longer signature pointer.

> Will there also be DLD and X versions of the macro?
>

I suppose so. I would like to make the optimizations accessible to C++.

> Thinking about DEFUNX, maybe it should be renamed to "DEFUN_QUOTED" or
> similar?
>

Maybe...

> Should we have a slightly more descriptive name for DEFUNL?
>

If we do the above, then yes. I actually patterned DEFUNL after
DEFUNX. But maybe it can be done afterwards (after some more
discussion).

regards

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