Re: how to write a new programming language?

Joachim Durchholz <joachim_d@gmx.de>
5 Apr 2003 15:05:44 -0500

          From comp.compilers

Related articles
how to write a new programming language? ahabma@yahoo.com (2003-03-30)
Re: how to write a new programming language? Nonahin@yaHoo.coM (LeeB) (2003-03-30)
Re: how to write a new programming language? torbenm@diku.dk (2003-03-31)
Re: how to write a new programming language? joachim_d@gmx.de (Joachim Durchholz) (2003-04-05)
| List of all articles for this month |

From: Joachim Durchholz <joachim_d@gmx.de>
Newsgroups: comp.compilers
Date: 5 Apr 2003 15:05:44 -0500
Organization: Compilers Central
References: 03-03-175 03-03-198
Keywords: design
Posted-Date: 05 Apr 2003 15:05:44 EST

Torben Ęgidius Mogensen wrote:
>
> 2) Write a compiler to an existing programming language.
>
> The second options isn't very much more difficult and you have the
> option of using different languages for the compiler and the
> implementation language, e.g., SML or Haskell for the compiler and C
> for the target language. Also, it makes it easy for your language to
> call functions in the target language.


The downside is that you'll have to live with any problems that your
target language has.
For example:
C - difficulties when detecting arithmetic overflows, some exception
models are difficult to get efficient.
Basic - syntax and semantics tend to be a moving target.
C++ - subtle semantic differences between compilers (aka compiler bugs).
Exotic languages - not everybody has the compiler.
Etc.


There's also a general problem: compiler-generated code tends to break
the assumptions of the programmers that programmed the target
compilers. There are loads of stories on compilers that crash when
variable names exceed 128 characters, switch statements have more than
4096 cases, internal tables that overflow when a function has more
than 1024 local variables, or optimizers that run in N^2 (or worse)
complexity where N is the number of variable uses in a function or
some similar characteristic. Since C is a well-used target language,
C compilers tend to be robuster than the norm, but even with these you
can experience nasty surprises. (For example, I know that some
compilers targetting C split large functions to keep optimizer time
under control. Which is, of course, an ugly hack since it will prevent
some optimizations that don't take much time.)


This doesn't mean that generating C (or any other language) is always
a bad idea. It's just things that you have to take into account when
selecting a target platform.


Personally, I think sticking with an interpreter is initially the best
choice; I'd try to skip the generate-to-C phase and go directly for
machine code generation. Since that's in the future, you might even
see pluggable machine code generators at that time. (People have been
trying to do that for years, and progress is slow and halting, but
it's there.)


Regards,
Joachim
--
Currently looking for a new job.


Post a followup to this message

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