Re: Parsing a simple BASIC language

stephan@pcrm.win.tue.nl writes:
> > A stack might not be the most appropriate data type, since it seems
> > that you do not approach the data Last In, First Out. Consider using
> > some other data type, e.g. an an array.


Michael Haardt <michael@moria.de> wrote in message
> Or store only the tokenized text. You need to invent a junk token,
> though, which attribute stores arbitrary text so you can load/edit
> syntactically invalid programs. You'd be surprised how many old
> programs contain syntax errors in rarely or never used code paths.


I now store the tokens in a TList of pointers, thus gaining an
appreciable speed increase. Whereas my test line (256 chars of string
expression and functions) took 3 milliseconds to parse 100 times, it
now takes 2 milliseconds to parse 500 times :) - but I have optimised
the parser somewhat since I used the old array.


> parsing during execution is not going to yield a very efficient result.
>


That is exactly why parsing should be carried out only once the return
key is pressed. My problem was that I wanted to perform a parse of the
current edit line every time the user pressed a key, and when you
reached about 200 chars, you had to wait for the parser to finish
before pressing another key :( I really needed help speeding it up.


> My interpreter stores programs tokenised. Before running a program,
> it makes a first pass to build the symbol table and a second to resolve
> symbol references and check types.


This is exactly what I intend doing. However, I have just spent about
6 months writing a parser. To be fair, I knew absolutely nothing about
parsing before that.


> A line-by-line check only works for one-line statements, but BASIC is not
> that simple at all. It only looks that way. ;)


How do you mean one line statements? I thought that statements could
only occupy one line at a time anyway? You *do* get big problems when
there are more than one statements on a single line however... I had
to consider whether the overhead of :


1) parsing the line.
2) storing which statements (if there was more than one) were correct.
3) checking where the line had changed, and which statement was affected,
4) subsequently reparsing from that point.


was worth it, or just to parse the whole line over from scratch.
Anyone know how to efficiently suspend parsing on an incomplete line and
then carrying on at a later time (ie, resuming the parse when more has been
added to the line by the user?)


Thanks
        Paul.

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