Re: Save a plot to .ps

[John W. Eaton]

On 28-May-1999, Daniel Heiserer <address@hidden> wrote:

| The key thing is the parser line
| 
| 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.

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

If I'm wrong, and there is a way to handle this in a completely
unambiguous way, please clue me in.

| > | Ones that is done, I think we would have a 99.9% braindead solution
| > | soon. ;-)
| > 
| > For some, this is not really a goal.
|
| I don't think that sould be a goal. But octave is so general
| and cool that it shouldn't be a problem offering a braindead solution.

Well, it turns out that bug-for-bug compatibility is a problem, for
reasons that I think have been discussed here before.

jwe