From bug-octave-request at bevo dot che dot wisc dot edu  Mon Feb  5 11:57:26 2001
Subject: Re:  more parser bugs?
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: etienne at isr dot ist dot utl dot pt
Cc: bug-octave at bevo dot che dot wisc dot edu
Date: Mon, 5 Feb 2001 11:57:10 -0600

On  5-Feb-2001, Etienne Grossmann <etienne at anonimo dot isr dot ist dot utl dot pt> wrote:

|   My (humble) opinion is that using less characters increases
| readability.

I'd say that is not at all true.  Consider a language like Perl, which
has a lot of non-intuitive variable names and operators.  You can do a
lot of powerful things with very few characters, but then it is hard
(for nearly everyone, I'd guess) to decipher what the line noise means
unless you happen to have memorized the meanings of all the cryptic
variable and operator symbols.  If it bugs you that I pick on Perl
here, then choose some other cryptic language that uses just a few
characters with non-intuitive meanings to do powerful things, like the
regular expressions used by sed.

| #  all cases in the parser that accept optional separators (it would make
| 
|   Like the "," at the end of a "if" line?

I would change the grammar to have

 IF '(' expression ')' statement-list ENDIF

The only place you could put statement separators would be in the
statement-list.

The problem is when you see things like this:

  if complex-expression, statement-list end

because it can be hard to tell where the complex-expression ends (it
can be difficult to find the correct comma that marks the end of
the complex-expression)  If you require it to be

  if (complex-expression) statement-list end

instead, then you only have to match parens.  I agree that matching
parens can also be somewhat hard to do, but at least my editor can do
it fairly reliably and without a lot of difficulty.  I'd guess that
doing the same for a comma in a complex line of code would require a
substantially more complete parser for the language since it would
have to know what an expression is, etc.

| #  the grammar cleaner).
| 
|   And easier to parse, too.

Yep, that's the point.  It's easier for programs AND people to parse.

Anyway, bug-octave is not really the right place for this discussion.
Can you post any followups somewhere else?  If it is help-octave,
please give enough context so people can follow it.

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------