Re: Re-implementation of inline functions

[Paul Kienzle]

On Aug 3, 2004, at 1:23 PM, John W. Eaton wrote:

> |   * 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).

A couple of comments: (1) I really appreciate the small footprint of
tcl/tk and the ability to bundle the scripts and program together into
a single file executable as it means I don't have to worry about 
conflicts
between what I'm shipping and what is available on the machine.  Please
try to keep types out of the core. However, (2) it would be nice to be
able to define as few primitives as possible on a new type (e.g., 
+,-,*,/, > ...)
and immediately have that type available in real/complex
scalar/vector/matrix/nD-array/sparse.  So maybe have the templates in
liboctave (along with support code so that the templates are as small
as possible), but keep the instantiation of each type separate in
DLD-FUNCTIONS?

> | 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).

Looking at the R14 changes, it looks like nested functions (and
inlines for that matter) share a common environment with the
top level wrapping function.  Each time you take a handle you
have to attach a copy of the current symbol table.  This finally
lets us do currying, which is very handy for throwing together
objective functions for optimizers.

I suppose this means the "@(args) expr" syntax also dereferences
its unbound variables when the inline function is called rather
than when it is defined, which is unfortunate since it means you
have to evaluate what are probably constant expressions (e.g.,
sqrt(2) ) each time you run, since the user can override the
definition of anything.  This is moot for now since we don't have
an optimizing compiler, but its a shame to cut off the possibility
before we even start.

- Paul