[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: local functions in file

From: John W. Eaton
Subject: Re: local functions in file
Date: Fri, 2 Aug 2002 11:32:21 -0500

On  2-Aug-2002, Mark P. Esplin <address@hidden> wrote:

| On Friday 02 August 2002 08:41 am, Teemu Ikonen wrote:
| >
| > At least I would find this feature very useful, it would make Octave much
| > more like a "real" programming language. And I would not mind seeing some
| > kind of module system also, but of course that would be even more work.
|       Although it seems a good idea to make Octave more like a
| "real" programming language, one needs to be careful not to
| complicate it.

Nested functions are already somewhat complicated, but I'm only asking
what is reasonable to do given the way Octave currently behaves and
with the additional constraint of Matlab compatibility.  Here is what
we have to consider:

  * Matlab only allows functions to be defined in .m files when the
    first non-comment/whitespace token is "function" (function .m
    files).  If the .m file begins with something other than
    "function" it is a script and can't define any functions.
    Functions can not be defined on the command line.

  * Matlab has no "end function" marker other than EOF, so I would
    guess that nearly all Matlab code that uses nested functions is
    written like (0)

      function f1 (...)
      function f2 (...)
      function f3 (...)

    with no "end" tokens matching the "function" tokens.  However,
    writing either (1)

      function f1 (...)
      function f2 (...)
      function f3 (...)

    or (2)

      function f1 (...)
      function f2 (...)
      function f3 (...)

    will give equivalent results, with warnings.  So, if we were to go
    for bug-for-bug compatibility, I don't think there is any way to
    have real nested functions since in the case of (2), there would
    be no way to tell which behavior was intended, and I don't think
    it seems right to make (2) behave differently if the "end" tokens
    are replaced by "endfunction".

  * Octave allows functions to be defined on the command line or in
    script files.  It seems that we should allow nested functions to
    be defined there as well.  If so, then they have to be of form
    (2) because otherwise, there is no way to tell they are nested.
    If we allow things like (2) to appear in script files or at the
    command line, then why should we limit the nesting to just one
    level deep?  If you put another function inside f2, why shouldn't
    it be local to only f2?  To me, that kind of arbitrary limit seems
    much worse than any additional complication associated with making
    Octave more like a "real" programming langauge.

We can handle (0) above by initially parsing it so that f3 is nested
in f2, and then patch the symbol tables when we encounter the <EOF>
before finding any "end" tokens to match the "function" tokens.

Since Matlab complains about the "end" tokens in function M-files, my
preference is to assume that any code like (2) above is not Matlab
code, and to nest the functions more logically.  This only matters
when the nesting level more than one deep.

For (1), I'm not sure what to do.  These would not have to be nested
functions in Octave, and because of the warnings in Matlab, they are
unlikely there too, so it could simply be an error.  Or we could parse
these as Matlab-like subfunctions.

I don't care so much about this last case, but I do think that if we
are going to allow nested functions, we should be able to write them
anywhere (command line, script file, function file).


Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]