Re-implementation of inline functions

[John W. Eaton]

On  3-Aug-2004, David Bateman <address@hidden> wrote:

| Coming back to the Octave 3.0 ToDo list, the things on it that haven't
| yet been addressed are
| 
|   * some support for MPI

There is some work happening on this now.

|   * sparse matrices

Not sure about this.  My impression is that the current sparse code in
octave-forge would need some significant cleanup to be included in the
core Octave and that we might want to switch to using UMFPACK instead
of SuperLU (see for example the notes by Paul Kienzle here:
http://www.octave.org/mailing-lists/octave-maintainers/2002/219).

|   * finish implementation of cell arrays and struct arrays:
|       -- cell(idx) = [] to delete elements
|       -- a(1).x = 1; a(2).x = 2; a.x => c.s. list, [a.x] => num array
|       -- allow [x{:}] = f (...) to work
|       -- and other little details like this...

I've done some work on some of these problems but have not had time to
finish them.  The third item is a bit tricky and may require some
changes to the interface of the octave_value::subsasgn method, so this
is a priority for me if we are going to try to minimize internal
interface changes for the 3.x series.

|   * inline functions
|   * private functions

See my comments below.

|   * bring the manual up to date

This is now a big but not impossible job.  When I made the 2.0
release, the manual was out of date and I spent some time just
updating it.  I hope to be able to do the same again, and perhaps this
time around will have some help.

| As I don't understand all that needs to be done for private functions
| yet,

I think private functions are very similar to nested functions but
to support them properly will require some changes to the
file lookup code (the stuff in liboctave/pathsearch.cc).

| I thought I'd attack the question of inline functions and see
| what I could do. There is already a reasonable implementation within
| octave-forge, but it has the disadvantage that it defines as many user
| defined functions in the symbol table as there are inline functions,
| and can implement the argnames and vectorize functions in a matlab
| compatiable manner.

Shouldn't an inline function be more like a function handle?  The
latest Matlab release now has this syntax for anonymous function
handles:

  @ ( ARG_LIST ) EXPR

Given the rest of the language it is not terribly surprising that
this is so limited, but I think it would have been better if EXPR
could be some block of statements.

Along with the new way of invoking a function through a handle of

  function_handle ( PARAM_LIST )

isn't this more or less the same as an inline function?  I'm not sure
why both are included in the language, except that inline functions
already existed in earlier versions of Matlab.

In any case, if we implement the above, couldn't inline just be a
special case of an anonymous function handle?  Would anything but the
class name need to be different ("inline function" or whatever
vs. "function handle")?  I suppose the inline function itself (the one
you call to create an inline function object) would still have the job
of deciding what arguments to handle as arguments, but wouldn't that
be easily handled by a call to eval if we have already implemented the
new "@ ( ARG_LIST ) EXPR" syntax?

| I also included all of the missing functions such as vectorize and
| argnames that were missing. The only missing feature is the extraction
| of the argument name from a single argument call to "inline", as what
| matlab does seems a bit dumb to me. Also, as fsolve hasn't been
| adapted to allow function handles, and perhaps other functions, you
| can't yet do something fsolve(inline("1-x"),0).

Yes, these things need to be fixed.  If inline returns something that
is essentially the same as an anonymous function handle, then we
should only have to handle two cases (function name as a string and
function handle) rather than three (inline as well as the other two).

jwe