|TXL Experience E.J.Poole@newcastle.ac.uk (1994-02-10)|
|Re: TXL Experience firstname.lastname@example.org (1994-02-11)|
|Re: TXL Experience email@example.com (1994-02-12)|
|Re: TXL Experience firstname.lastname@example.org (1994-02-23)|
|From:||email@example.com (Nicholas Graham)|
|Organization:||York University, Dept. of Computer Science|
|Date:||Sat, 12 Feb 1994 05:28:19 GMT|
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
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.
Return to the
Search the comp.compilers archives again.