Re: lvalue list optimizations

[John W. Eaton]

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?

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.

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

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

Should we have a slightly more descriptive name for DEFUNL?

jwe