[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed parser changes
From: |
John W. Eaton |
Subject: |
Re: proposed parser changes |
Date: |
Fri, 14 Mar 2008 08:07:59 -0400 |
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