Re: Look for a LALR grammar for visual basic

genew@vip.net (Gene Wirchenko)
12 Sep 1997 21:12:22 -0400

          From comp.compilers

Related articles
Look for a LALR grammar for visual basic tsupplisson@suresnes.marben.fr (Thierry Supplisson) (1997-08-16)
Re: Look for a LALR grammar for visual basic thetick@scruz.net (Scott Stanchfield) (1997-08-19)
Re: Look for a LALR grammar for visual basic genew@vip.net (1997-08-20)
Re: Look for a LALR grammar for visual basic jrr@atml.co.uk (1997-08-24)
Re: Look for a LALR grammar for visual basic thetick@magelang.com (Scott Stanchfield) (1997-09-07)
Re: Look for a LALR grammar for visual basic genew@vip.net (1997-09-12)
| List of all articles for this month |
From: genew@vip.net (Gene Wirchenko)
Newsgroups: comp.compilers
Date: 12 Sep 1997 21:12:22 -0400
Organization: All USENET -- http://www.Supernews.com
References: 97-08-050 97-08-052 97-08-065 97-09-027
Keywords: parse, Basic

  Scott Stanchfield <thetick@scruz.net> wrote:
  >Unfornately, my NDA with them prevents me from saying much more about
  >it... I think I can say that it was a fairly nasty beast in some areas:
  >Think about
  >
  > IF x = 1 THEN
  > END
  > 100: END IF
  >
  >which would complicate a grammar significantly (yes, VB allows a label
  >on things like "END IF" -- yuck!


Gene Wirchenko wrote:
>> If you're going to allow goto, it makes sense to me to allow a
>> branch to the end of a block (from within the block only I hope).


Scott Stanchfield <thetick@magelang.com> wrote:
>I'd agree if the label were on the next statement _after_ the if block,
>as in
>
> IF x = 1 THEN
> END
> END IF
> 100


          If you allow that, make it simpler, namely the exit statement
that some languages have. From the Visual FoxPro 5.0a On-line Docs:


EXIT transfers control from within a DO WHILE ... ENDDO, FOR ...
ENDFOR, or SCAN ... ENDSCAN loop to the command immediately following
ENDDO, ENDFOR, or ENDSCAN.


          This doesn't affect an if though.


          loop is a similar command. It bypasses the rest of the loop and
"jumps" to the testing.


>or were on a separate line (a true null statement) before the END IF.


          Whether the label is attached to a null statement or the end if
makes no difference ever in execution that I can see. Do you have a
counterexample?


>I'm pretty sure your C example would need to be
>
> if (x == 1) {
> exit(EXIT_SUCCESS);
>target ; }
>
>(note the semi for the null statement.)


          What null statement? In C, semicolons (at the appropriate part
of the statement) terminate statements and are part of the statement.
Now, in ALGOL, semicolons separate statements and aren't part of
either statement.


>Labels are normally only allowed in front of a statement. END IF isn't
                        ^^^^^^^^
          I challenge your use of the term "normally". I know of no
reference to null statements in QBASIC, yet I can do
                    entrypoint:
                          print "This is a stub subroutine."
                          return
I usually do put labels on separate lines from statements.


>a statement, but a block terminator. Allowing labels at the beginning


          So why can't a branch target it? Simply define semantics for
what it means. You might have it mean exit the block if the block
isn't a loop construct (Example: then and else blocks) and go back to
the loop control if the block is a loop construct (Examples: for and
while blocks).


>of any line makes the language incredibly nasty to implement with no
>added benefit to a user...


          Why are my example semantics "incredibly ... user"?


          I do grant that I prefer exit and loop. (Is there an equivalent
to loop in QBASIC? It's certainly useful in xBASE.)


Sincerely,


Gene Wirchenko
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.