TXL, VHDL preprocessor (tree transformer) RESPONSES (SUMMARY)

Hi,


A week ago I posted a message asking people for alternative tools on
writing parsers, building parse trees and transforming parse trees.
Thank you for all the people who have responded to my message(s).
The following is a summary of the tools, and the comments on the use of
these tools + other implementation issues relating to my VHDL preprocessor
program.


Best regards


Wing C.




=========================================================================
Here is a quick summary to the alternative tools (which are probably
listed in comp.compilers.faq):


=========================================================================


Pccts : SORCERER and other pccts tools (look in the free.compilers faq list
for more info) are available at :everest.ee.umn.edu (128.101.144.112)
in /pub/pccts/1.2x




PRECC : PREttier Compiler Compiler - similar but more advanced than Yacc.
PRECC provides the ability of infinite lookahead and backtracking.
PRECC is available on ftp.comlab.ox.ac.uk /pub/Programs/preccx*
(both Unix and Dos versions are available).




TXL : Tree Transformation Language. Take a look in /pub/txl on
ftp.qucis.queensu.ca. Unfortunately, according to the author of TXL,
the funding on this project has stopped and so is the project.




Cocktail : It has a parser generator. It also got a tree
transformation language puma, which you can also use very
effectively for unparsing.


=========================================================================


I also asked for comments on TXL, and also advises on implementation issues
in my previous messages.


=========================================================================




Return-Path: <Joerg.Lohse@zfe.siemens.de>
Date: Tue, 11 Oct 94 15:57:26 +0100
Subject: Re: looking for experienced TXL users
Reply-To: lohse@zfe.siemens.de


Hello,


I'm no experienced TXL user. Actually, I've never used TXL. But I know a
little about VHDL:


To translate VHDL's enumerated values to numbers you need quite a lot of
type information. In VHDL, enumerated values are overloaded and overloading
must be resolved. Even without packages, the enumerated character literal '0'
for instance must be translated into number 0 for type BIT but into 48 for
type CHARACTER. If you use packages like the IEEE standard package, the third
possible value 2 for '0' is also to be considered. Therefore, there is no way
that a simple symbol table lookup is enough to do this translation. You need
to parse types, statements and expressions and annotate the expressions with
types to resolve overloading in order to translate enumerated types to their
equivalent numerical values.


*****Moreover, the publically available scanners and parsers do not support the
entire language: E.g., this is valid VHDL:*****


ENTITY test IS
      PORT (output: OUT bit);
      END test;


      ARCHITECTURE a OF test IS
      BEGIN
          output <= bit'('0');
      END a;


The scanner must figure that '(' is no character literal, but '0' is.


BTW, the paser and scanner source pointed to by comp.lang.vhdl's FAQ does
not support any attributes, i.e. the statement


    WAIT UNITL A'EVENT AND A = '1';


will cause a syntax error.


Hope this helps,


Joerg


------------------------------------------------------------------------------
Dr. Joerg Lohse phone: +49 89 636-45268 (MET)
Siemens Corporate R&D fax : +49 89 636-42284
m/s ZFE T SE 1
Otto-Hahn-Ring 6 Internet: lohse@zfe.siemens.de
81730 Munich
        Germany


========================================================================




Return-Path: <graham@otter.cs.yorku.ca>
Date: Thu, 13 Oct 1994 01:03:34 -0400
Subject: TXL




I've used TXL to create (among other things) an implementation of a functional
programming language similar to Haskell. The language is translated to
another functional language using TXL for implementation.


My comments on the TXL approach would be:


-- TXL is fast, but not as fast as hand-coded translators. If you are planning
        on translating programs measured in the hundreds to low thousands of lines,
        TXL is fine; in the thousands or tens of thousands of lines, maybe yacc is
        the better way to go.


-- Not having a TXL grammar for your language is not really a hinderance.
        Making grammars for TXL is very easy.


-- The above comment notwithstanding, it does take some time to get the
        feel of TXL, and learn what kinds of techniques work well with the
        language. Don't underestimate this startup time.


-- TXL is very flexible. My source language changed a fair bit, and so did
        my translation schemata. TXL was very good at supporting this change.
        Another win was the ability to add optimizations in translation
        schemata. I can't imagine doing what I did here in yacc -- it would be
        possible, but would have taken so long, I probably wouldn't have done it.


-- TXL is not always good at context-sensitive checking of source programs --
        e.g., type checking in TXL is not trivial. If you want to implement
        good error checking and recovery, you probably want the flexibility of
        yacc + hand coding. (I may be out of date on this, however - you might
        want to check with Jim Cordy on the latest in this area.)


-- One other interesting result is that TXL is infectious. Once I'd taken
        the time to learn it, I found many other applications where I use TXL.
        Most of these I would have probably have done using sed if I hadn't
        used TXL, and just put up with less general results.


Hope this helps,


Nicholas Graham
Assistant Professor
York University
North York, Canada


========================================================================


Return-Path: <jardined@qucis.queensu.ca>
Date: Thu, 13 Oct 1994 13:56:36 -0400 (EDT)
Subject: TXL




I've written a lot of TXL transforms. I'm sure it will do what you want,
and since you wrote it you will also understand what you're doing.
There's a bit of a learning curve, but no much if you're familiar with
functional languages, since TXL transform rules are functions.


I've done some rather wierd transforms, and so have several others in
this department, as well as others elsewhere. I think it's MUCH more
understandable, and hence modifiable, than YACC.


It is designed as a prototyping tool, and therefore has some decent
debugging tools for the rules. Grammar errors are harder to detect, but
not really difficult.


Prof. Donald Jardine, Software Technology Laboratory, Comp. Sci. Dept.,
Queen's Univ. Kingston Ont. Ph (613) 545 6070 Fax (613) 545 6513


========================================================================


Return-Path: <brent@jade.ssd.csd.harris.com>
Date: Fri, 14 Oct 94 08:47:25 -0400
Subject: Using Lex/Yacc to transform a parse tree
Reply-To: Brent.Benson@mail.csd.harris.com


# From: wing@research.canon.oz.au (Wing Chung)
# Date: Tue, 11 Oct 1994 07:32:13 GMT
#
# My first question is, what is the simplest way to parse multiple files.
# E.g. In C, we have #include <filename>, and there is a similar statement
# in vhdl. The preprocessor will (at least) need to extract the constants
# and enumerated types defined in these included files, before processing
# the main source file. How can I do this in Yacc/Lex???


I would recommend running the the source through the C preprocessor
before handing it off to lex and yacc.


;Brent


========================================================================


Return-Path: <steve@cegelecproj.co.uk>
Date: Fri, 14 Oct 1994 17:46:31 +0000
Subject: Re: Using Lex/Yacc to transform a parse tree




In article 94-10-084, you write:
> My first question is, what is the simplest way to parse multiple files.
> E.g. In C, we have #include <filename>


whoa! you need to sort out the difference between file inclusion and a
preprocessor, first. If your included files just contain additional
declarations that could have been typed in directly, and conform to the
grammar, then fair enough. Goto include_file. On the other hand, if your
directive cause a transformation of subsequent input - such as C's #define
- then you need to separate this process into a preprocessor, because such
things aren't part of the grammar, and really screw up yacc.


As far as file inclusion goes, there are two options. The first (and easiest)
is to use bison, because that generates a reentrant parser. You just set up
yyin (I think), and recall yyparse(). If you're stuck with normal yacc, then
either add the inclusion directives into your grammar, and expand them later,
or generate two parsers, and do a global replace of yy to xx, to keep the
names separate. This is messy, and likely to lead to bugs, though.


steve
--
<Steve_Kilbane@cegelecproj.co.uk>
--
Wing Chung wing@research.canon.oz.au
Canon Information Systems Research Australia Phone +61 2 805 2976
P.O. Box 313 North Ryde, NSW, Australia 2113 Fax: +61 2 805 2929
--

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