Re: Save a plot to .ps

[Daniel Heiserer]

> | function a b c
> |
> | should be the same as
> |
> | function('a','b','c')
> |
> | Which means that I can call a function with some arguments in two ways.
> | -bracket-style
> | -shell style
> |
> | Matlab has that feature in 5.3. As far as I can see this kind
> | is not used in octave right now, so it doesn't lead to incompatibility.
> |
> | The key thing is that it is NOT possible to pass variables in the
> | shell-style.
> | All arguments are taken as strings.
> |
> | See "load/save ...etc".
> | It is only a more general way of doing
> |
> | load myfilename
> | AND
> | load('myfilename')
> |
> | That is what I meant you could add.
> | Would be nice to have. ;-)
> 
> 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.

Of course there is. It is the same way it is in octave right now.
"bar" can be a function/m-file or a variable. 
The only thing that counts and on which the decision is made
is if "bar" is a function or a local variable. While the variable 
has precedence if both exist.
You are absolutely right that this can lead to unpredictable 
results depending on your local workspace. But that is how 
it is right now in ocatve anyway.
=======================================================
function tmp(a,b)
if nargin>0
a
b
end
=======================================================c
octave:1> tmp(-1,-2)
a = -1
b = -2
octave:2> tmp -1 -2
error: value on right hand side of assignment is undefined
error: evaluating assignment expression near line 2, column 8
octave:2> tmp=13
tmp = 13
octave:3> tmp -1 -2
ans = 10
octave:4> which tmp
tmp is a user-defined variable





> 
> I believe that the way Matlab gets away with this is that
> 
>   1. Functions can only be defined in .m files, so given the name bar,
>      Matlab can look to see if there is a file bar.m somewhere that
>      might define a function.  If so, it assumes that bar is a

matlab has also built in functions. Only the help  is in the m-files
than.

>      function.  But, as I see it, this `feature' causes trouble when
>      eval() comes in to play, because given the above functions,
> 
>        foo ('bar = 2; option = 2;');
> 
>      does something completely different than
> 
>        function foo
>          bar = 2;
>          option = 2;
>          bar -option
>        end
>        foo
> 
>      even though I thought evaluating a string with eval() is supposed
>      to be the same as having the commands evaluated in the current
>      context.
> 
>   2. It has some odd heuristics about what characters might introduce
>      options (I think, but it's been quite a while since I tried to
>      figure out what Matlab's rules might be).
> 


daniel



-- 
Mit freundlichen Gruessen
                                 Daniel Heiserer
-----
--------------------------------------------------------------
Dipl.-Phys. Daniel Heiserer, BMW AG, Knorrstrasse 147, 80788 Muenchen
Abteilung EK-20
Tel.: 089-382-21187, Fax.: 089-382-42820
mailto:address@hidden