Related articles |
---|
syntax checker/debugger ? ggriffin@mdc.net (Gary) (1997-06-24) |
Re: syntax checker/debugger ? karsten@tdr.dk (Karsten Nyblad) (1997-06-30) |
Re: syntax checker/debugger ? mzraly@athena.mit.edu (1997-06-30) |
From: | Karsten Nyblad <karsten@tdr.dk> |
Newsgroups: | comp.compilers |
Date: | 30 Jun 1997 22:59:01 -0400 |
Organization: | Tele Danmark Research |
References: | 97-06-092 |
Keywords: | syntax, tools, comment |
> [A syntax checker is little more than a parser, it's pretty easy
> regardless of whether the language is interpreted or compiled.
This is wrong. In a number of interpreted languages the syntax
depends on the values of symbols that do not get assigned before
runtime. In VMS' command interpreter, DCL, the value of a symbol
might be a string that contains half a procedure call. E.g. In DCL you
can write:
$ a = f$search("LOGIN.COM")
$ show symbol a
and VMS would first store the full file name of LOGIN.COM. Then
VMS would print it on your screen.
You can, with the same effect write:
$ b = "f$search("
$ c = ")"
$ a = 'b "LOGIN.COM" 'c
$ show symbol a
When interpreting $ a = 'b "LOGIN.COM" 'c, the interpreter would start
with substituting f$search( and ) for 'b and 'c. Then it would look
up the full file name of LOGIN.COM.
Languages like DCL are virtually impossible to scan and parse prior
to execution.
Karsten Nyblad
karsten@tdr.dk
Tele Danmark R&D
[Well, sure, you can't syntax check Unix shell scripts very well
either for the same reason. Can we agree that if you can parse the
language at all, a syntax checker is little more than a parser? -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.