Re: Function calls (Was: Save a plot to .ps)

[Andy Adler]

On Fri, 28 May 1999, John W. Eaton wrote:
> | Anyway, it seems that out of the ambiguity is simply to define a
> | precedence order. Something like
> | 
> | 1. If bar is a variable   bar -option is a substraction
> | 
> | 2. If bar is a function   bar -option => bar('-option')
> | 
> | 3. If bar is a function with no inputs that returns a value,
> |     then force the user to code this as bar() -option
> | 
> | Is this a reasonable solution? 
> 
> I don't think so.  When Octave parses a function, it has now way of 
> knowing that a symbol is a function or a variable, until the code is
> actually evaluated.  That's why you can write
> 
>   function foo ()
>     ...
>     bar ();
>     ...
>   end
> 
>   function bar ()
>     ...
>     foo ();
>     ...
>   end
> 
> in the same script file and have it work.  That's also why eval() can
> do the right thing.
> 
> Do you really want Octave to require you to only define functions in
> .m files?  Or to require that if you define them on the command line
> or in a script file, that you must define all functions before they
> are called?  That rules out any mutually-recursive functions defined
> on the command line or in script files and forces you to define other
> sets of functions from the bottom up.

John, I'm not sure I can follow your reasoning. (I may be missing
something really obvious here). I'm all for octave avoiding
inheriting bugs from matlab compatibility, but if there's a
clean way to do something (which I still think there is ) then
I think it should be considered.

What I'm arguing is that octave already handles the ambiguity
of function calls / matrix subscripting in a consistent way.
(And Matlab does not). Clearly, octave is capable of making
run time decisions about what an identifier represents.

I'm arguing that this run time capability can be extended to 
decide whether
    foo -option
is a function call or a subtraction. Additionally, this capability
could be defined in such a way that it had clear precedence rules,
and, as such, was unambiguous.

Am I missing something obvious here?

> FWIW, here is the way I think this should have been designed:
> 
>   * Function calls always have to use `()', even when there are no
>     arguments.
> 
>   * Indexing should have used a different operator (perhaps `[]')
>     instead of `()', so that there would never be any confusion about
>     whether an expression is a function call or an indexed variable.
> 
>   * The operator for building matrices should have been something
>     different too (perhaps `{}').
> 
> but of course, that is not the way Matlab works, so if you want
> compatibility, you are stuck with some annoyingly ambiguous syntax.

This isn't the worst ambiguity of matlab syntax. 
My vote for worst of Matlab is the 0,1 indexing feature, which gives

a=[2 3]; a([1 1])
ans = [2 2]

I've been bitten by this __feature__ many times


__________________________________________________________________
Andy Adler | address@hidden | AIT Corporation | (613)722-2070x1588