[Top][All Lists]

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

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

From: Andy Adler
Subject: Function calls (Was: Save a plot to .ps)
Date: Fri, 28 May 1999 10:02:16 -0400 (EDT)

>| The key thing is the parser line
>| function a b c 
>| should be the same as
>| function('a','b','c')
>This is not possible for Octave.  The reason is that I see no good way
>to unambiguously parse the following:
>  function foo (a)
>    eval (a);
>    bar -option
>  end
>  function bar (option)
>    fprintf ('%s\n', option);
>  end
>because there is no way to tell whether to parse
>  bar -option
>as a function call with an argument, or a subtraction expression.
>If I'm wrong, and there is a way to handle this in a completely
>unambiguous way, please clue me in.

  The current situation is ambiguous
  function foo (a)
    eval (a);
    bar (a);

  function bar (option)
    fprintf ('bar=%f\n', option);

If we call 
  >> foo('bar=[3,4];a=2');

Then is bar a matrix or a function call?

In this situation:

1) OCTAVE      octave:16> foo('br=[3,4];a=2;')
               ans = 4 

2) MATLAB      >> foo('br=[3,4];a=2;')

( So it seems that matlab is precompiling the functions and ignores
  the output of eval )

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 think that the convenience of being able to call
function without having to press the shift-("') keys (which are
a pain for a vi user like myself) would be really nice.

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

reply via email to

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