Re: Help and ideas with C-like to C transformation tool (long)

haberg@matematik.su.se (Hans Aberg)
29 Dec 2001 13:23:03 -0500

          From comp.compilers

Related articles
Help and ideas with C-like to C transformation tool (long) Corey@Stup.net (2001-12-27)
Re: Help and ideas with C-like to C transformation tool (long) haberg@matematik.su.se (2001-12-29)
Re: Help and ideas with C-like to C transformation tool (long) rwaltman@verizon.net (Roberto Waltman) (2001-12-29)
Re: Help and ideas with C-like to C transformation tool (long) idbaxter@semdesigns.com (Ira D. Baxter) (2001-12-29)
Re: Help and ideas with C-like to C transformation tool (long) ralph@inputplus.demon.co.uk (2001-12-29)
| List of all articles for this month |
From: haberg@matematik.su.se (Hans Aberg)
Newsgroups: comp.compilers
Date: 29 Dec 2001 13:23:03 -0500
Organization: Mathematics
References: 01-12-162
Keywords: translator
Posted-Date: 29 Dec 2001 13:23:03 EST

Corey@Stup.net (Corey Stup) wrote:
>We have a legacy language, which is very C-like, but with some added
>features such as type'd defines, library function overloading and some
>other features. The "translator" was written in lex/yacc under Unix,
>and has a complete C-like grammar defined. It outputs valid C code
>that then is compiled by a commercial C compiler.
...
>However, this is a huge limitation. The language as written does not
>allow for any standard C datatypes (only our "built-in" ones) or
>structures, new function calls are not easily implemented, etc.


I began on a computer language that outputs C++, because of the
limitation of the latter. The translator is using Flex/Bison, first
parsing the input language, then combining that with a formatting file
using a special formatter macro language I also designed for this
purpose.


But, as I did not want to re-write all C++ language constructs, and as
I know that the output will be C++, I decided to have a construct for
verbatim inclusion of C++. I recall that I made that {{ ... }} causes
... to be verbatim inserted into the generated C++ code, the choice
being made because double "{{" and "}}" are quite uncommon in code. If
one wants something fancier, one can choose say the C++ construct
`extern "Language" { <code> }".


With this construct in hand, one would have to know what the
translator outputs in order to be able to use it, but the point is
that one can successive implement new features into your language as
they are needed: First write code in the target language, and when
certain patterns start emerging, implement it into your own language.


    Hans Aberg * Email: Hans Aberg <remove.haberg@member.ams.org>
                                    * Home Page: <http://www.matematik.su.se/~haberg/>
                                    * AMS member listing: <http://www.ams.org/cml/>


Post a followup to this message

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