|Error message with bison and flex firstname.lastname@example.org (2014-04-07)|
|Re: Error message with bison and flex email@example.com (Kaz Kylheku) (2014-04-10)|
|Re: Error message with bison and flex DrDiettrich1@aol.com (Hans-Peter Diettrich) (2014-04-11)|
|Re: Error message with bison and flex firstname.lastname@example.org (glen herrmannsfeldt) (2014-04-12)|
|From:||glen herrmannsfeldt <email@example.com>|
|Date:||Sat, 12 Apr 2014 03:31:35 +0000 (UTC)|
|Organization:||Aioe.org NNTP Server|
|References:||14-04-005 14-04-007 14-04-008|
|Posted-Date:||12 Apr 2014 15:37:12 EDT|
Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
> In these cases the "source code" display may be even less helpful. IMO
> every application using parsers needs its kind of an IDE, that
> translates the syntactical errors into something meaningful to the user.
When I first started programming, with OS/360 compilers, it was usual
for the compiler to print an annotated listing file with some type of
numbering. Ones I remember printed ISN (internal statement number)
instead of input file line numbers, which you could match up on the
Fortran G prints a $ in the suspected error column on the next line,
where Fortran H gives the column number.
I suppose the printed listing file has some similarity to the full
screen display in an IDE.
The listing file also could contain a list of variables with their
address and line number in which they were used.
With cards, you had to print the file and look at it. With WYLBUR, you
could fetch the file back to an editing session, search through it
using editor command, such as search for the word ERROR, then purge
the file without printing it.
I don't know if any compilers still generate listing files with line
numbers and cross references.
Return to the
Search the comp.compilers archives again.