proposed parser changes

[John W. Eaton]

I'm thinking about modifying the parser to remove the special "command"
and "rawcommand" tags for symbols and instead use the surrounding
context to decide when the parser is looking at a command-style
function.  This change would improve compatibility with Matlab.

I resisted this kind of change in the past because I didn't like the
following behavior of Matlab:

Given a function foo, the expression

  foo -1

would call foo with the character string "-1" as an argument but

  foo - 1
  foo-1
  foo- 1

would all call foo with no arguments, then subtract 1 from the value
it returned.

Now I'm beginning to think the advantage of improved compatibility and
not having to tag functions as commands outweighs the trouble that
might be caused by this small inconsistency.

Also, we no longer mark any functions in Octave or Octave Forge with
the "rawcommand" tag.  It was only used to support the special syntax
used by gset/gplot/gsplot.  Now that those are gone I see no reason to
keep the "rawcommand" tag in any case.

Comments?

jwe

[Jaroslav Hajek-2]

On Thu, Mar 13, 2008 at 7:33 PM, John W. Eaton <jwe@...> wrote:

> I'm thinking about modifying the parser to remove the special "command"
>  and "rawcommand" tags for symbols and instead use the surrounding
>  context to decide when the parser is looking at a command-style
>  function.  This change would improve compatibility with Matlab.
>
>  I resisted this kind of change in the past because I didn't like the
>  following behavior of Matlab:
>
>  Given a function foo, the expression
>
>   foo -1
>
>  would call foo with the character string "-1" as an argument but
>
>   foo - 1
>   foo-1
>   foo- 1
>
>  would all call foo with no arguments, then subtract 1 from the value
>  it returned.
>
>  Now I'm beginning to think the advantage of improved compatibility and
>  not having to tag functions as commands outweighs the trouble that
>  might be caused by this small inconsistency.
>
>  Also, we no longer mark any functions in Octave or Octave Forge with
>  the "rawcommand" tag.  It was only used to support the special syntax
>  used by gset/gplot/gsplot.  Now that those are gone I see no reason to
>  keep the "rawcommand" tag in any case.
>
>  Comments?
>

I think it's a good idea, as writing custom commands previously
required adding mark_as_command to some startup script - I suppose
that will no longer be necessary.

>  jwe
>



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

[Søren Hauberg]

tor, 13 03 2008 kl. 14:33 -0400, skrev John W. Eaton:

> Now I'm beginning to think the advantage of improved compatibility and
> not having to tag functions as commands outweighs the trouble that
> might be caused by this small inconsistency.
>
> Also, we no longer mark any functions in Octave or Octave Forge with
> the "rawcommand" tag.  It was only used to support the special syntax
> used by gset/gplot/gsplot.  Now that those are gone I see no reason to
> keep the "rawcommand" tag in any case.
>
> Comments?

I'd say make the change. IMHO commands suck, and everybody (including
myself) really should be using functions. But since people don't it's
nice to be compatible with the other brand.

Søren

[Dupuis]

John W. Eaton wrote:

I resisted this kind of change in the past because I didn't like the
following behavior of Matlab:

Given a function foo, the expression

  foo -1
[...]

Comments?

Syntactic sugar. Sugar is bad for theeth.
Just to avoid typing two parens, this introduce a lot of uncertainties, and traps for the unwary.
I learned to program in Fortran, and to me:
foo is a variable
foo(-1) is a call to the function foo, with argument -1
foo() -1 is a computation using the output arg of function foo, called without input args.
The rest is unneeded complexity. Have a look at 'perldoc perlfunc'. Now figure out why "print 1+2+4" prints 7, and "print (1+2) + 4" prints 3 !

OTOH, I worked a lot with R recently, and I like their paradigm:
foo is a variable (scalar, vector, matrix, ...)
foo[something] is a slice, that is, part of a vector, matrix
foo[, 2] is the second column of matrix foo
foo() is a function call

the point is that the operator to access submatrices, "[", is different from he one used for functions calls, "(". The disambiguation is total, but I guess such change would break a lot of code in Octave.

Regards

Pascal
--
 

[John W. Eaton]

On 14-Mar-2008, Dupuis wrote:

| Syntactic sugar. Sugar is bad for theeth.

We already do something similar by providing "mark_as_command".  But
it is not compatible with Matlab.

| Just to avoid typing two parens, this introduce a lot of uncertainties, and
| traps for the unwary.
| I learned to program in Fortran, and to me:
| foo is a variable
| foo(-1) is a call to the function foo, with argument -1
| foo() -1 is a computation using the output arg of function foo, called
| without input args.
| The rest is unneeded complexity. Have a look at 'perldoc perlfunc'. Now
| figure out why "print 1+2+4" prints 7, and "print (1+2) + 4" prints 3 !
|
| OTOH, I worked a lot with R recently, and I like their paradigm:
| foo is a variable (scalar, vector, matrix, ...)
| foo[something] is a slice, that is, part of a vector, matrix
| foo[, 2] is the second column of matrix foo
| foo() is a function call
|
| the point is that the operator to access submatrices, "[", is different from
| he one used for functions calls, "(". The disambiguation is total, but I
| guess such change would break a lot of code in Octave.

To be compatible with Matlab, we don't get to choose the syntax.

jwe

[WMennerich]

Hy,
I'm afraid of a debugging situation, if the 'bug' is only a whitespace to much
together with a bad named variable, i.e. a functionname,
which is not in the matlab-path at my machine, but
on the machines of my colleagues...

W.M

[John W. Eaton]

On 20-Mar-2008, Wolfgang_M wrote:

| I'm afraid of a debugging situation, if the 'bug' is only a whitespace to
| much
| together with a bad named variable, i.e. a functionname,
| which is not in the matlab-path at my machine, but
| on the machines of my colleagues...

I don't understand what you mean.  Can you please give an example that
demonstrates the problem you are thinking of?

Note that I'm not proposing some new untested syntax/semantics.  This
way of parsing "commands" has been in use by Matlab for many years
now.  All I'm suggesting is that we finally be compatible with it.  I
suspect that this change will break very little Octave code.

jwe

[WMennerich]

John W. Eaton wrote:

On 20-Mar-2008, Wolfgang_M wrote:

| I'm afraid of a debugging situation, if the 'bug' is only a whitespace to
| much
| together with a bad named variable, i.e. a functionname,
| which is not in the matlab-path at my machine, but
| on the machines of my colleagues...

I don't understand what you mean.  Can you please give an example that
demonstrates the problem you are thinking of?

Given the function 'foo' which is defined like:
****
function result=foo( vect, mean)
      result=(mean -vect)

end %end of function
****

Called with only one argument, the variable 'mean' will be treated as a function with the negative
argument 'vect'. This will not throw an error, but give completly wrong results.
In this case with the matlab-function 'mean', it is clear  what happens and you might find the problem of
this constellation immediately. But if you have a similar function 'foo( vect, srcBar)'
and 'srcBar' is the name of a function on my machine in the matlab path but not at your computer,
you will never be able to reconstruct the wrong results I could get with this function.
Furthermore, if you work with objects (maybe in octave 3.1?)  you might often use
function names as variables.

By the way another case which is already making trouble in matlab:

Try in R2007a:

mean-1
mean -1

(second comand with whitespace between 'mean' and '-1')
the first command throws an error (like expected), but the second one gives out '47' on my computer.
I dont know whats happening there, but if this stuff makes already trouble in matlab,
it might not be an advantage, if also octave does similar things.

W.M

[John W. Eaton]

On 20-Mar-2008, Wolfgang_M wrote:

| Given the function 'foo' which is defined like:
| ****
| function result=foo( vect, mean)
|       result=(mean -vect)
|
| end %end of function
| ****
|
| Called with only one argument, the variable 'mean' will be treated as a
| function with the negative
| argument 'vect'.

No, that should not happen.  First, because mean is named in the
argument list, it is a variable in the function even if foo is only
called with one argument.  Also, if you rewrite your function as

  function foo (vect)
    result=(mean -vect)
  end

so that mean must be a function, then this should still not call mean
with the argument '-vect' because the command syntax should only be
recognized at the beginning of a statement.

| In this case with the matlab-function 'mean', it is clear, what happens and
| you might find
| this constellation. But if you have a similar function 'foo( vect, srcBar)'
| and 'srcBar' is the name of a function on my machine in the matlab path but
| not at your computer,
| you will never be able to reconstruct the wrong results I could get with
| this function.

No, because any variable named in the argument list is treated as a
variable inside the function, independent of whether you pass a value
for the argument when you call the function.

| Furthermore, if you work with objects (maybe in octave 3.1?)  you might
| often use
| function names as variables.

If you mean by using function handles, then I think that's a separate
issue.  Also, you can't call a function through a function handle with
the command syntax.  For that, you must use the function call syntax.

| By the way another case which is already making trouble in matlab:
|
| Try in R2007a:
|
| mean-1
| mean -1

Yes, this is well known, and apparently doesn't cause too much
trouble.

| (second comand with whitespace between 'mean' and '-1')
| the first command throws an error (like expected), but the second one gives
| out '47' on my computer.
| I dont know whats happening there,

With the command syntax, the function is passed the arguments as
character strings.  So

  mean -1

is equivalent to

  mean ('-1')

and in Matlab, '-1' in a numeric context is equivalent to the numeric array
[45, 49] (i.e., the decimal ASCII values of the characters in the
character array).

| in matlab,
| it might not be an advantage, if also octave does similar things.

It is an advantage to provide compatible behavior, and I think many
people coming to Octave from Matlab would like to be able to define
functions that can also be called with the command syntax without
having to declare them specially (by using the mark_as_command
function in Octave).

We already provide the possibility for functions to be declared as
commands, so the sort of confusion caused by "mean -1" can already
happen[1].  The question is whether we should allow this for all
functions or just those that have been specially tagged.

jwe

[1] However, Octave's mean function rejects character string arguments
    and I don't think anyone has complained, so I guess calculating
    mean values of the ASCII values of character strings is not a
    widely used feature.

[WMennerich]

Of course, you are right. I forgot the fact that all arguments are already defined in the argument list.
In that case, the parser changes may be a good idea. To make octave more compatible to matlab.
I do not use this syntax for programming, but there may be a lot of matlab software wich does.

Best, W.M.