questions from using lint

Walter Bright bright at dataioDataio.UUCP
Tue May 20 06:50:15 AEST 1986


In article <473 at cubsvax.UUCP> peters at cubsvax.UUCP (Peter S. Shenkin) writes:
>What I'm waiting for is an interactive interpretive debugger that runs from
>vi.  The program would run interpretively until an error was encountered,
>then place you at the appropriate line in the source file with the error
>message displayed.  Then you could go into insert mode, make the necessary
>change, and resume execution.  Normally interpreted languages, like APL, 
>often have such facilities.  Are there insuperable difficulties with doing 
>this with a normally compiled language like C?  (I'm sure it could be done
>with FORTRAN, since FORTRAN interpreters are well-known... but why have we
>seen no C interpreters?)

Major difficulties are:

1) The preprocessor. At any line,
a macro could be changed, which could change the meaning of the entire
remainder of the source text. This means that 'incremental compiles' becomes
'compile from here to the end of the source text'. Of course, that means
the parser must have the state of the parse saved at every line..., which
obviously is impractical.

2) C isn't line oriented. This means that any line could be any part of
a statement or expression. Thus, the parser must be able to back up from
any point to find a 'synchronization point'. But C isn't backwardly
parseable...

Why BASIC and FORTRAN can be handled this way:

1) They don't have a preprocessor.

2) They are line oriented. All the parser has to do is back up to the
beginning of the line (or in FORTRAN to the first line that isn't a
line continuation).

3) Each line is more or less independently parseable from the rest of
the program.

Conclusion:

The only fully functional, practical way is to do a reparse of the complete
source file upon any changes (even on whitespace changes). Turbo Pascal
works this way, instead of attempting to incrementally compile, Borland
spent their efforts making the compile step really fast.

An incremental compiler could be made if numerous assumptions and
restrictions were made about what could be changed. I think the bugs
and kludges that would result would make it impractical, however.



More information about the Comp.lang.c mailing list