[comp.os.vms] LIB$TPARSE question

terrell@musky2.MUSKINGUM.EDU (Roger Terrell) (07/28/88)

I think that I would like to use the LIB$TPARSE routine from VAX Pascal
in an application that I am writing; does anyone know anything about the
performance of it (good/bad ?), and could you give me an example of 
how to use it (pascal is best, but anything would be helpful)?

I understand that the state table must be created in either MACRO or BLISS.
Since we don't have BLISS here, I suppose I will have to go for MACRO.

--Roger

-- 

Roger Terrell
...musky2!terrell (UUCP) 
terrell@muskingum.edu (CSNet)

bcw@rti.UUCP (Bruce Wright) (08/02/88)

In article <121@musky2.MUSKINGUM.EDU>, terrell@musky2.MUSKINGUM.EDU (Roger Terrell) writes:
> 
> I think that I would like to use the LIB$TPARSE routine from VAX Pascal
> in an application that I am writing; does anyone know anything about the
> performance of it (good/bad ?), and could you give me an example of 
> how to use it (pascal is best, but anything would be helpful)?
> 
> I understand that the state table must be created in either MACRO or BLISS.
> Since we don't have BLISS here, I suppose I will have to go for MACRO.
> 
I have never coded a routine to call LIB$TPARSE from a higher level
language - I've always written the routine to call it in assembler.  For
this purpose the examples in the manual are reasonably good, although
perhaps a bit complex for use as a template for solving simple problems.

My experience is that LIB$TPARSE is reasonably efficient - although I
would have to know what you are planning to do with it to know whether
it would be reasonable in your application.  For simple command interpreters
and for parsing simple languages (such as regular expressions), it is
pretty good, but I would not particularly recommend building a higher-level
language compiler on it.

The issue is not so much the efficiency so much as it is the structure --
LIB$TPARSE is unable to deal with complex grammars on its own, and therefore
your action routines have to do a lot of work to maintain the state of the
grammar.  But then if you are building a really large language you could
use a table-driven parser designed for compiler writing or even just use
recursive descent.  Both of these tend to be more trouble than LIB$TPARSE
for simple grammars.

I suspect that the necessary tables can be coded in things besides MACRO
and BLISS but I have never tried to do it - there just hasn't been any
incentive since the tables are so easy to code in MACRO (you may also need
a small routine in MACRO to obtain the necessary table addresses in order
to pass them to LIB$TPARSE).  Not sure how you would try to code them in
Pascal since I'm not familiar with the DEC Pascal compiler and you would
probably need to take advantage of extensions;  however I thought (briefly)
about doing it for PL/I and C and although I never tried it I had the
impression that it wouldn't be too bad.

My recommendation would be to try coding your application (or at least the
part of it you think may be compute-intensive or involve complex grammars) 
in LIB$TPARSE and find out how bad it is, both in terms of the difficulty
of coding it and in terms of efficiency.  If you have never used a table-
driven parsing system before you probably want to start with something
small and play around with it for a while until you get the hang of it -
and as I mentioned before the examples in the book are pretty good although
a bit lengthy.  You should avoid action routines and subexpressions until
you are comfortable with coding simple state tables - instead specify flags
to be set when a transition is made that you want to record.

Hope this helps a bit - if you want I could probably dig up some examples
from my code and e-mail them but I have had trouble getting e-mail to a 
lot of sites on the net, and most of my programs are even more complex
than the examples in the book ...

						Bruce C. Wright