Re: TXL Experience

J.P.M.deVreught@CP.TN.TUDelft.NL ("Hans de Vreught") writes:
>Over here we have given Txl some serious consideration because it does
>everything we wanted it to do. However, the speed was completely
>unacceptable for our purpose and the backend was also too inflexible for
>us. We weren't able to parse a 200 *byte* program within a couple of
>hours. Furthermore we weren't able to link in our user defined functions
>in an efficient way. But the syntax was a definite pro: clean, simple, and
>powerful.


As a TXL user, I find these results surprising. I recently used TXL to
write a CPS-transformer for a subset of Haskell. As you can imagine,
Haskell's expression language is highly ambiguous, and in fact requires a
context-sensitive parse to get right. I used TXL's standard parsing to
get an initial parse, followed by transformations to introduce the
context-sensitive information, in turn followed by the CPS
transformations. The resulting system takes about 5-10 seconds to parse
and transform a 200 line program on my SS10 workstation. This isn't
production quality speed, but for a prototyping tool is quite acceptable.
I personally appreciate that the TXL parser supports general CFG's -- it
doesn't seem appropriate for a prototyping tool to burden a user with
hacking out a LALR grammar, especially when the input language may be
subject to design changes.


My experience is that using TXL's parser is a little like using Prolog --
you have the power to do anything, but you do have to pay a little
attention to how you write things if you want decent performance.




>We decided to change our existing tree transformer such that it has Txl's
>syntax. Our goal is to have a Txl like tool with a LALR parser in front
>and with a backend where we can simply link in user defined functions.


The tool you're proposing sounds a lot like Puma, which is available as
part of the Cocktail compiler construction toolkit -- Puma has been used
to implement a number of production compilers, and is definitely worth
looking at. For a prototyping tool, I still think TXL is the way to go.


Nick
--

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