|how to write a new programming language? email@example.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? firstname.lastname@example.org (2003-03-31)|
|Re: how to write a new programming language? email@example.com (Joachim Durchholz) (2003-04-05)|
|From:||Joachim Durchholz <firstname.lastname@example.org>|
|Date:||5 Apr 2003 15:05:44 -0500|
|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.
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.
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
Currently looking for a new job.
Return to the
Search the comp.compilers archives again.