octave 3.2.0 parser

[John W. Eaton]

On 11-Jun-2009, Jaroslav Hajek wrote:

| after a bit of playing around and inspecting the Matlab docs (I have
| no more access to Matlab), I ended up with the following change:
| http://hg.savannah.gnu.org/hgweb/octave/rev/67fc970dad7d
| 
| This simplifies the lvalue-counting system inside pt-idx.cc using a
| new octave_value::numel (octave_value_list) method. By default, this
| simply calculates the product of lengths, substituting corresponding
| dimensions for colons, but can be overloaded. It is overloaded in
| octave_class, to first search for "numel" method and then do the
| default calculation, possibly using an overloaded "size" result.
| octave_value::size () (this existed before, but was not used anywhere)
| is now forwarded to octave_base_value and overloaded in ov-class, so
| it's a way to query for object dimensions while taking into account
| class overloads (dims() will always get the default dimensions). All
| this seems consistent with the Matlab docs.

Thanks for looking at this.  I haven't examined your patch, but is it
careful to avoid evaluating expressions more than once?  Maybe that
doesn't matter anyway, since lvalues should not be functions with side
effects, even for octave_class objects.

| So, for instance, the following is now possible with the polynomial
| example (was failing before)
| a = polynomial(1:3)
| [a{1:2},b] = deal(0,1)
| 
| note that polynomials are overloaded so that {} returns arrays, not
| cs-lists, and this is indicated by numel.
| The converse, overloading () (not followed by a dot) to return a
| cs-list, is impossible. I believe this is also true in Matlab, but I
| can't check.

I don't know whether this will cause trouble for exsiting code.  I
guess if it does, we just have to tell people that they will have to
fix their code in some way because we had to change this behavior in
order to provide Matlab compatibility.

jwe