Re: HELP a newbie - Weird problem

[Ian Searle]

> and THEN do "conv(1,1)" you will get
> 
>       parse error near line 59 of file conv.m:
> 
>       >>>       x = [b, zeros (1, ly - lb)];
>                                  ^
> no doubt because it tries to evaluate "[b, zeros (1, ly - lb)]" as a
> matrix with columns  "b"  and  "zeros" and "(1, ly - lb)" (or somthing to
> that effect) because the "traditional" column separator in a Matlab
> literal matrix is the space.  (Can experts confirm that this reading is
> [approx] correct?).
> 

Yes this is almost correct... Matlab 4.2 does:

        >> x = [b, zeros (1, ly - lb)];
        ??? x = [b, zeros (1,
                            |
        A closing right parenthesis is missing. 
        Check for a missing ")" or a missing operator.

[other stuff sniped]

> Next, if <expr> is a valid expression, so is (<expr>). The problem would
> seem to arise from the parser asserting that "(1, ly - lb)" is not a valid
> expression (the parser having already decided that "zeros" is valid). The
> only get-round would seem to be to write a back-tracking parser which
> tried to apply rules like
> 
>     If     (<expr>)   is not a valid expression,
>            and   (<expr>)   is preceded by a name <name>
>     Then   try to parse   <name> (<expr>)   as a function call
>            <function_name>(<arg_list>)
> 
> This would be a pain: and since the problem really arises from trying to
> satisfy two different conventions (white-space where you like as in
> octave, versus white-space only when it can't cause trouble as in
> Matlab) at the same time, the real solution is for people to write their
> m-functions accordingly.
> 
> Any comment from the people who really know what goes on? The above is
> off the top of my head!
> 

I believe that the parse error is due to the comma, or the early ). It
looks like the expression x = [b, zeros (1, ly - lb)]; is parsed as

        x = [ b        zeros       (1,        ly - lb) ]

Thus Matlab and Octave are complaining about the (1 not being
completed properly. It is possible that a back-tracking parser is not
necessary, proper precedence, might do the trick. On the other hand it
might be that there are just too many ambiguities in this expression
for sensible parsing to occur. I would have to actually try writing a
parser for this to be sure (and I am not about to do that!).

Can you say "bad language design" :-) Machine languages with
ambiguities are acceptable, but when the ambiguities cause confusion
for humans, there is a design problem that cannot be fixed with a
better parser.

-Ian