[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HELP a newbie  Weird problem
From: 
Ian Searle 
Subject: 
Re: HELP a newbie  Weird problem 
Date: 
Fri, 11 Aug 1995 12:34:47 0700 
> 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 getround would seem to be to write a backtracking 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 (whitespace where you like as in
> octave, versus whitespace only when it can't cause trouble as in
> Matlab) at the same time, the real solution is for people to write their
> mfunctions 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 backtracking 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