Hi,

I am thinking of taking a university course in compiler design. The
instructor has chosen a book that teaches compiler implementation in
Java. I always thought that compilers were usually written in C/C++.

Question - what languages are used to write compilers? My world is
Unix/Linux - should I wait until a course is offered using C/C++?

Many thanks,
Joe
[No. Compiler design is about algorithms and data structures, which
are the same no matter what language you're using. And anyway, for
most purposes Java is just C++ with some of the cruft stripped out and
garbage collection added. The GC makes it a lot easier to whip up
little sample programs. -John]

From:	Rafael 'Dido' Sevilla
Subject:	Re: Language used to write compilers
Date:	30 Dec 2004 00:56:22 -0500

On Wed, Dec 29, 2004 at 01:45:09AM -0500, Joe H. wrote:
> I am thinking of taking a university course in compiler design. The
> instructor has chosen a book that teaches compiler implementation in
> Java. I always thought that compilers were usually written in C/C++.
>

I imagine the course focuses on the techniques used for writing
compilers, which should be applicable no matter what language you use.
While historically compilers were indeed written in C/C++, that was
probably because there were few usable alternatives in the past. I
have had experience writing compilers in C, and I can say that it is a
messy job that obscures the details of compiler design. C in
particular has very poor string handling capabilities, and most
compilers will need to often perform complex string manipulation in
the course of their operation. It is necessary to also create your
own ad hoc symbol tables and other data structures crucial to compiler
design, because the language doesn't have anything standard that will
suffice.

Java is a better language for this task, because of the automatic
garbage collection, reasonable string handling, and the decent library
of data structures that can be readily adapted to compiler
applications. There is also the ANTLR parser generator which does for
Java what Lex and Yacc do for C.

Nonetheless, the best language IMHO for writing compilers has got to
be Objective Caml.

> Question - what languages are used to write compilers? My world is
> Unix/Linux - should I wait until a course is offered using C/C++?

No.

From:	Ira Baxter
Subject:	Re: Language used to write compilers
Date:	31 Dec 2004 13:08:07 -0500

"Joe H." wrote in message
news:04-12-148@comp.compilers...

> I am thinking of taking a university course in compiler design. The
> instructor has chosen a book that teaches compiler implementation in
> Java. I always thought that compilers were usually written in C/C++.
>
> Question - what languages are used to write compilers? My world is
> Unix/Linux - should I wait until a course is offered using C/C++?
>
> [No. Compiler design is about algorithms and data structures, which
> are the same no matter what language you're using. And anyway, for
> most purposes Java is just C++ with some of the cruft stripped out and
> garbage collection added. The GC makes it a lot easier to whip up
> little sample programs. -John]

In fact, compilers are programs just like most other applications,
and you can technically code them in any reasonable language.

The real question at hand is, what does a language offer to a compiler
designer to enable him to produce compilers quickly and reliably? On
this front, C, Java, and all the general purpose languages fare pretty
badly, because their primitive abstractions are not the ones that
"compiler writers" want. Granted, you can build up a big set of
procedures to provide those, but that's a lot of work, and the
language still doesn't understand your intent.

A good language for a task is one which describes the tasks in terms
sensible for the task, and groks those terms. (This is called a
"domain specific language). BNF is such a nice language for
describing syntax.

Because compilers are a complex topic, it is unlikely that you can
find a "single" language that describes the task well.

We have taken an approach with our DMS Software Reengineering
Toolkit in what a set of languages helps a compiler
(well, source code analyzer/optimizer/translator) builder
can express his intent. It has "little" languages for:
a) Syntax. Lexical and Grammatical.
b) Analysis. (Attribute grammars).
c) Optimization and Translation (Source-to-source rewrite rules).
A sublanguage describes side-effects on analysis results.
d) General purpose computation (Parallel programming language).
Each of these languages has its own syntax and semantics.
More importantly, they enable concise specification of
the task at hand, and they allow the tools to analyze that
specification for errors, as well as building optimized
programs for the specific tasks.

So, you may learn how to build a compiler in a general purpose
language. You may also be forced to write one that way. But life can
be a lot easier if you use the right tool for the job :-}

--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com

From:	Nick Maclaren
Subject:	Re: Language used to write compilers
Date:	30 Dec 2004 00:58:39 -0500

Joe H. wrote:
>I am thinking of taking a university course in compiler design. The
>instructor has chosen a book that teaches compiler implementation in
>Java. I always thought that compilers were usually written in C/C++.
>
>Question - what languages are used to write compilers? My world is
>Unix/Linux - should I wait until a course is offered using C/C++?
>
>[No. Compiler design is about algorithms and data structures, which
>are the same no matter what language you're using. And anyway, for
>most purposes Java is just C++ with some of the cruft stripped out and
>garbage collection added. The GC makes it a lot easier to whip up
>little sample programs. -John]

Hmm. Firstly, I would say "a little easier" - compilers are pretty
simple programs in terms of memory management.

Secondly, and more importantly, ignoring those aspects leads to the
sort of abominable compilers that we are inflicted with today. Yes, I
manage two systems where the compilers make unreasonable demands on
the configuration - specifically that there be no memory limits (even
for compiling the null program).

Exactly how do I configure a system so that users who miscalculate
array sizes don't exhaust memory and swap, causing other users'
programs and even the system to crash, and still enable the use of
those compilers? There are similar problems with /tmp, too.

Yes, I know that I am not going to win on this one, but I do wish a
bit more effort would be put into teaching the software engineering
of compilers.

Slightly off-topic, but indicative, is the fact that almost no
compilers identify the line for both ends of a bracketting mismatch.
Why not? It is TRIVIAL to do in 95% of cases. But, for at least 50
years, it has been a blind spot for compiler writers. And yet it
is well-known to be a continual, low-level sink of effort for people
working on large codes.

Regards,
Nick Maclaren.

From:	Rafael 'Dido' Sevilla
Subject:	Re: Language used to write compilers
Date:	30 Dec 2004 21:59:56 -0500

On Thu, Dec 30, 2004 at 12:58:39AM -0500, Nick Maclaren wrote:
> Hmm. Firstly, I would say "a little easier" - compilers are pretty
> simple programs in terms of memory management.

Until you consider that compilers generally do plenty of string
handling, and that in C strings are second-class entities that you
must manually allocate and deallocate whenever needed. There are also
a lot of other complex dynamic data structures that must be maintained
by any compiler of serious scope, such as syntax trees, the various
graph structures used for code optimization, and so forth. I would
hardly call programs that used so many dynamic data structures "simple
programs in terms of memory management".

> Secondly, and more importantly, ignoring those aspects leads to the
> sort of abominable compilers that we are inflicted with today.

These aspects are not ignored. Automatic garbage collection and
memory management leaves these aspects in the hands of the machine,
which can do a reasonable job, leaving the programmer to concentrate
on the actual problem, not extra bookkeeping.

Perhaps it is because these aspects are truly ignored, implemented under
systems that don't support automating the process, that you have the
abominable compilers you describe.
--
kurayami de wa neko wa subete haiiro...
http://stormwyrm.blogspot.com/

From:	Nick Maclaren
Subject:	Re: Language used to write compilers
Date:	31 Dec 2004 13:03:21 -0500

Rafael 'Dido' Sevilla wrote:
>On Thu, Dec 30, 2004 at 12:58:39AM -0500, Nick Maclaren wrote:
>> Hmm. Firstly, I would say "a little easier" - compilers are pretty
>> simple programs in terms of memory management.
>
>Until you consider that compilers generally do plenty of string
>handling, and that in C strings are second-class entities that you
>must manually allocate and deallocate whenever needed. There are also
>a lot of other complex dynamic data structures that must be maintained
>by any compiler of serious scope, such as syntax trees, the various
>graph structures used for code optimization, and so forth. I would
>hardly call programs that used so many dynamic data structures "simple
>programs in terms of memory management".

I would. To address your points in turn:

Compilers do very little string handling, because they typically just
read in strings, and either keep them or turn them into a token or
pointer. They do very little dynamic creation and deletion, and the
total "string space" is usually small. If you think that C is bad,
try Fortran 66 - and string handling was not the main problem when
writing compilers in that :-)

The handling of syntax trees during optimisation is probably the only
aspect of a compiler that stresses memory management, which is why
almost all memory problems with compilers occur during that phase (and
why a common solution is to disable optimisation). But even it is not
hard, compared with many other applications.

The reason is that trees are a simple data structure. There are a few
more complex data structures in compilers (e.g. when attempting to
share code or data), but generally things are pretty simple. In
particular, it is rare for scoping to be the nightmare that it can be
in some applications.

For example, consider dynamic remeshing on a distributed memory
parallel machine with, of course, something like an electromagnetic
model to solve over it all.

>> Secondly, and more importantly, ignoring those aspects leads to the
>> sort of abominable compilers that we are inflicted with today.
>
>These aspects are not ignored. Automatic garbage collection and
>memory management leaves these aspects in the hands of the machine,
>which can do a reasonable job, leaving the programmer to concentrate
>on the actual problem, not extra bookkeeping.

I have been trying to kill that myth for 30 years, but I shall go to
my grave defeated :-(

No, that is not so. This being comp.compilers, here is one very
simple and very common problem that has been a nightmare for users for
40 years and probably more:

When a program goes haywire, such as being faced with input that
is exponentially hard to handle or because the compiler author failed
to delete a now-unneeded pointer in a recursion, the symptoms often
include memory leaks.

With explicit memory allocation, the programmer usually knows how
much allocation is reasonable, and can put in a check and diagnostic.
With automatic schemes, there are rarely suitable controls, and the
program runs until it exhausts resources.

There are only sometimes tools for the programmer to diagnose such
failures (see below), and almost never tools for the user of the
program (or his local expert, i.e. me) to do so. No, in real life,
those people CANNOT change the source of the compiler. We are then
typically faced with a resource exhaustion failure and no useful
diagnostics - and sometimes even a denial of service :-(

>Perhaps it is because these aspects are truly ignored, implemented
>under systems that don't support automating the process, that you
>have the abominable compilers you describe.

I know of no current operating systems that support control of the
virtual, physical and cache memory, TLB usage, I/O rate and so on. A
few do SOME of them, but not all - and you only have to have a
compiler run a system out of ONE critical resource to start causing
other users' jobs (or even the whole system) to fail.

Even for resources where the operating system does allow control, it
is very rare for this to be done competently either by the authors of
the automatic garbage collection system or by the authors of the
compiler. The reason is that such automation adds an extra level of
difficulty to diagnosis.

What is needed is that the compiler detects such problems, and relates
the resource exhaustion to the INPUT PROGRAM and what it being done to
it (including the options). Relating it to the source of the compiler
is only a half-solution - but we rarely get even that :-(

Please note that explicit resource allocation does not solve any of
the above. The ONLY difference is that it does not introduce a level
of obfuscation between the parts of the program causing the problem
and the parts that are in a position to do something about it.

Regards,
Nick Maclaren.

From:	Chris F Clark
Subject:	Re: error reporting, was Language used to write compilers
Date:	31 Dec 2004 13:05:34 -0500

Nick Maclaren wrote:
> Slightly off-topic, but indicative, is the fact that almost no
> compilers identify the line for both ends of a bracketting mismatch.
> Why not? It is TRIVIAL to do in 95% of cases. But, for at least 50
> years, it has been a blind spot for compiler writers. And yet it
> is well-known to be a continual, low-level sink of effort for people
> working on large codes.

I think this is a fairly valid gripe. I think part of the reason is
that most compilers have "too simple" of an error reporting mechanism.
The error reporting mechanism allows the report of an error as text
associated with one spot in the program. If one wants to report a
mismatch between two spots, one must output two error messages. I've
been facing this problem with the Verilog compiler I work on for my
day job. There are lots of times when the compiler gets in the
situation where a new fact disagrees with some existing knowledge
base. The simplest solution is to just print out that the new
information causes an error, and our compiler takes that cop-out far
too many times. The better solution is to track where the previous
knowledge was determined and print a message (even if it takes two
error messages to do do) showing both the site of the new information
and the old information. However, it often takes a fair amount of
work to track the appropriate old information, and it isn't the kind
of thing that adds "significant new functionality" like management
likes.

In any case, I am thinking about putting some features in Yacc++
(actually in the Language Objects Library) to simplify the reporting
errors that have "more than one relevant location". I know if it was
easier I would do it more often. More importantly, if I saw that it
was easy to do in one way, it would motivate me to find uses of the
feature. I doubt that I'm unique in that aspect.

Thanks for the motivation,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

From:	Louis Krupp
Subject:	Re: error reporting, was Language used to write compilers
Date:	9 Jan 2005 20:52:32 -0500

Chris F Clark wrote:

> I think this is a fairly valid gripe. I think part of the reason is
> that most compilers have "too simple" of an error reporting mechanism.
> The error reporting mechanism allows the report of an error as text
> associated with one spot in the program. If one wants to report a
> mismatch between two spots, one must output two error messages. I've
> been facing this problem with the Verilog compiler I work on for my
> day job. There are lots of times when the compiler gets in the
> situation where a new fact disagrees with some existing knowledge
> base. The simplest solution is to just print out that the new
> information causes an error, and our compiler takes that cop-out far
> too many times. The better solution is to track where the previous
> knowledge was determined and print a message (even if it takes two
> error messages to do do) showing both the site of the new information
> and the old information. However, it often takes a fair amount of
> work to track the appropriate old information, and it isn't the kind
> of thing that adds "significant new functionality" like management
> likes.
>
> In any case, I am thinking about putting some features in Yacc++
> (actually in the Language Objects Library) to simplify the reporting
> errors that have "more than one relevant location". I know if it was
> easier I would do it more often. More importantly, if I saw that it
> was easy to do in one way, it would motivate me to find uses of the
> feature. I doubt that I'm unique in that aspect.
>
> Thanks for the motivation,

gcc does something like that. Given this file (pt.c):

-------------------------------
static void f(void);

static void f(int x)
{
}
-------------------------------

It prints this:

-------------------------------
pt.c:4: conflicting types for `f'
pt.c:1: previous declaration of `f'
-------------------------------

Louis Krupp

From:	Chris F Clark
Subject:	Re: error reporting, was Language used to write compilers
Date:	14 Jan 2005 00:43:21 -0500

Yes, the gcc example is exactly what I was thinking of (and I think
gcc is the compiler which motivated my own thoughts along that line).
there are several examples where gcc tell you that x conflicts with y,
pointing where both location are.

The gcc compiler solution is to use two back-to-back error messages.
We use the same technique in the Verilog compiler I mentioned before.
For some errors like cycles of gates withot a state element, the list
of related errors can get arbitrarily long. Not necessarily the best
solution, although better than not having the information.

We also have a built-in debugger of the compiler's internal database
that developers can inspect and traverse to track down hard to
diagnose errors. However, that's hardly a good general solution.
Still, some kind of sanitized debugger of the compiler's information
would often be a better solution to finding certain problems.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

From:	VBDis
Subject:	Re: Language used to write compilers
Date:	9 Jan 2005 20:50:51 -0500

Im Artikel <04-12-158@comp.compilers>, nmm1@cus.cam.ac.uk (Nick Maclaren)
schreibt:

>Slightly off-topic, but indicative, is the fact that almost no
>compilers identify the line for both ends of a bracketting mismatch.

Where would that make sense? An opening bracket too much is mismatched
at EOF, and a closing bracket too much is mismatched at BOF?

DoDi
[There's more than one kind of bracket. If the parser sees a close
paren when it's expecting a close brace, that's an error. Perl tells
you where the open whatever was, and it's handy. -John]

From:	Nick Maclaren
Subject:	Re: Language used to write compilers
Date:	12 Jan 2005 22:56:13 -0500

>>Slightly off-topic, but indicative, is the fact that almost no
>>compilers identify the line for both ends of a bracketting mismatch.
>
>Where would that make sense? An opening bracket too much is mismatched
>at EOF, and a closing bracket too much is mismatched at BOF?
>
>[There's more than one kind of bracket. If the parser sees a close
>paren when it's expecting a close brace, that's an error. Perl tells
>you where the open whatever was, and it's handy. -John]

Yes. If you have merely one type, then simple counting will do, but
with as few as two types, there are many other errors. It is more
than just handy in a large code - I have often had to descend to
binary chop to find where a problem is in C - and remember that it can
be in a macro, so it not easily visible :-(

Actually, there are cases even with a single type of brackets where
it can help. But I agree that it is a minor issue.

Regards,
Nick Maclaren.

From:	Scott Moore
Subject:	Re: Language used to write compilers
Date:	31 Dec 2004 12:59:30 -0500

Joe H. wrote:

> Question - what languages are used to write compilers? My world is
> Unix/Linux - should I wait until a course is offered using C/C++?

Many compilers are written in Pascal. It is perhaps the only language
with a single character lookahead buffer built into to the language.
[I know that a lot of compilers used to be written in Pascal, but it's
my impression that C is now more popular if only because there is a
standard way to do separate compilation. -John]

From:	Mohd Hanafiah Abdullah
Subject:	Re: Language used to write compilers
Date:	3 Jan 2005 00:52:50 -0500

Scott Moore wrote:
>Joe H. wrote:
>
>> Question - what languages are used to write compilers? My world is
>> Unix/Linux - should I wait until a course is offered using C/C++?
>
>Many compilers are written in Pascal. It is perhaps the only language
>with a single character lookahead buffer built into to the language.

If you are coming from the UNIX/Linux world I would recommend C. C is
well integrated with UNIX, although you might want to also consider
C++. The other GNU tools that come with gcc are also C centric. And
if you are used to using pointers and linked lists again C (or other
Algol-like languages) come naturally, provided you use them with care.
You can look at C as a high-level language that was designed to also
have low-level features in order to do system programs such as OS or
compilers or device drivers relatively easier resulting in a less than
safe development environment as long as you are willing to live with
it. Most production quality C/C++ and even Java compilers were
written in C. But, it's good to learn Java for applications
development.

Napi

--
http://www.axiomsol.com
http://www.cs.indiana.edu/hyplan/napi.html

From:	Nick Roberts
Subject:	Re: Language used to write compilers
Date:	30 Dec 2004 22:54:24 -0500

"Joe H." wrote:

> I am thinking of taking a university course in compiler design. The
> instructor has chosen a book that teaches compiler implementation in Java.
> I always thought that compilers were usually written in C/C++.
>
> Question - what languages are used to write compilers? My world is
> Unix/Linux - should I wait until a course is offered using C/C++?

My advice for someone writing a compiler for the first time is to use
as high level a language as you possibly can. There are plenty of
languages readily available that are much higher level than Java (and
obviously vastly more so than C or C++).

There are three essential aspects to writing a good compiler (which
probably apply to most software anyway): it is well-designed; it is
correct; it is efficient. Of these three, the first two are far more
important than the third.

By "well-designed" I mean that the compiler has a good user interface,
in terms of switches, compiler directives, listing options, and (very
important) error diagnostics, as well as its implementation being
structured in a way that is conducive to testing and maintenance.

By "correct" I mean that the compiler always emits the right code: the
emitted code must have semantics compatible with the corresponding
source code, as defined by the source language (subject to any leeway
permitted by applicable compiler directives etc.).

A possible fourth aspect will be that the compiler emits
well-optimised code, if this is in fact a specific requirement of your
compiler.

You will almost certainly fail to produce a well-designed, correct
(optimising) compiler if you try to write it from scratch in a
low-level language (such as C or C++), however efficient it is.

To start with, forget efficiency, and concentrate on making the
compiler well-designed and correct. In particular, concentrate on
making the initial implementation highly testable/debuggable, and on
setting up a test mechanism that will give you very good assurance of
the compiler's correctness. Make sure that you can easily
trace/query/dump the internal state (e.g. of the symbol table and its
attributes) at any stage of the processing. It doesn't matter if,
initially, you use strings to store states, to make this sort of thing
easier. It doesn't matter if you use lots of phases, to make each
phase simpler. It doesn't matter if you use intermediate text files
between each phase, which you can then conveniently examine by
eye. Forget internal linking or emitting binary, to start with, and
just emit (pidgin) assembly.

Having achieved a well-designed, correct (optimising) compiler, you
can always then go on to concentrate on making it more efficient. Heed
my words! Good luck.
--
Nick Roberts

From:	Martin Ward
Subject:	Re: Language used to write compilers
Date:	31 Dec 2004 12:59:49 -0500

Nick Roberts wrote:
> "Joe H." wrote:
> > Question - what languages are used to write compilers?

Many languages are used to write compilers: I know of one compiler
that was written in COBOL: because that's all the compiler writer knew!

Perhaps you mean: what languages *should* be used to write compilers?

> There are three essential aspects to writing a good compiler (which
> probably apply to most software anyway): it is well-designed; it is
> correct; it is efficient. Of these three, the first two are far more
> important than the third.
> ...
> A possible fourth aspect will be that the compiler emits
> well-optimised code, if this is in fact a specific requirement of your
> compiler.

I would put the efficiency of the generated code higher than the
efficiency of the compiler. Generally, more CPU cycles are spent
executing compiled code than on running the compiler (with the
possible exception of Gentoo Linux systems...)

If the *language* you are compiling is well designed so that modules
can be compiled separately while still generating efficient code, then
compile times on modern systems are unlikely to be an issue. Good
debugging is *much* more important: how many recompiles are caused by
the need to track down bugs? Eliminating these recompiles is a bigger
gain than speeding them up!

--
Martin

Martin.Ward@durham.ac.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4

From:	Peter Flass
Subject:	Re: Language used to write compilers
Date:	1 Jan 2005 17:33:16 -0500

Martin Ward wrote:
>
>>There are three essential aspects to writing a good compiler (which
>>probably apply to most software anyway): it is well-designed; it is
>>correct; it is efficient. Of these three, the first two are far more
>>important than the third.
>>...
>>A possible fourth aspect will be that the compiler emits
>>well-optimised code, if this is in fact a specific requirement of
>>your compiler.

> I would put the efficiency of the generated code higher than the
> efficiency of the compiler. Generally, more CPU cycles are spent
> executing compiled code than on running the compiler (with the
> possible exception of Gentoo Linux systems...)

"It all depends"(tm). If you're writing a compiler for "production"
use, then true. If you're writing something for an educational
environment, than features like good diagnostics, speed of
compilation, etc. are the chief goals, and execution speed is far down
the list. The expectation is that a program in this environment will
be compiled many times, executed (successfully) once, then never run
again. PL/C is a good example of a compiler that did this very well.

[It seems to me that even places that care about performance do vastly
more compiling for debugging than for long runs, so even compilers
with whizzo back end optimizations would benefit from better
diagnostics. -John]

From:	Nick Maclaren
Subject:	Re: Language used to write compilers
Date:	3 Jan 2005 00:52:18 -0500

Peter Flass wrote:
>Martin Ward wrote:
>
>> I would put the efficiency of the generated code higher than the
>> efficiency of the compiler. Generally, more CPU cycles are spent
>> executing compiled code than on running the compiler (with the
>> possible exception of Gentoo Linux systems...)
>
>"It all depends"(tm). If you're writing a compiler for "production"
>use, then true. If you're writing something for an educational
>environment, than features like good diagnostics, speed of
>compilation, etc. are the chief goals, and execution speed is far down
>the list. The expectation is that a program in this environment will
>be compiled many times, executed (successfully) once, then never run
>again. PL/C is a good example of a compiler that did this very well.
>
>[It seems to me that even places that care about performance do vastly
>more compiling for debugging than for long runs, so even compilers
>with whizzo back end optimizations would benefit from better
>diagnostics. -John]

Indeed, yes. And they would benefit most of all for some diagnostics
that would help to track down the hard problems, such as those that
could be due to an ambiguity in the language standard, a subtle
programmer error or a bug in the compiler's optimisation.

Regards,
Nick Maclaren.

From:	Nick Maclaren
Subject:	Re: Language used to write compilers
Date:	31 Dec 2004 13:01:36 -0500

Nick Roberts wrote:
>My advice for someone writing a compiler for the first time is to use
>as high level a language as you possibly can. There are plenty of
>languages readily available that are much higher level than Java (and
>obviously vastly more so than C or C++).

The same applies to pretty well any other application, which is not
actually dominated by system interfacing or performance-critical,
low-level code. Many numeric programmers prototype in Matlab, and
Python has a lot going for it as a compiler development language.

Note Python and not Perl. The former has good error checking, and you
will usually be told "nonsense" when you make a simple mistake.
Mistakes in Perl are often other, legal constructs or (worse) illegal
ones that are not detected, with consequences that can be bizarre. In
THIS sense, Python is a much higher level language than Perl.

Regards,
Nick Maclaren.
[I would argue that perl with the -w option is about as high level,
and I don't find many bugs in my perl code due to one valid thing
being mistyped as another, but we can argue about that separately.
Perl definitely has much larger application libraries than Python,
but unless you want to do something like compile to XML, I can't
think of many that would be particularly useful in a compiler.
-John]

From:	stevenb
Subject:	Re: Language used to write compilers
Date:	30 Dec 2004 01:00:48 -0500

Joe H. wrote:
> Hi,
>
> I am thinking of taking a university course in compiler design. The
> instructor has chosen a book that teaches compiler implementation in
> Java. I always thought that compilers were usually written in C/C++.
>
> Question - what languages are used to write compilers?

What languages are not?

GCC is written in C, Open64 is written in C++, I've also seen
compilers written in Pascal, LISP, Perl, ML, Java, etc. I suppose the
most common languages for writing production compilers are C and C++,
but probably the reasons for that are efficiency, availability of
bootstrap compilers, and the history of the compiler - not the
superiority of these languages for writing compilers.

> My world is Unix/Linux - should I wait until a course is offered
> using C/C++?

No. You are not just going to learn how to build compilers in Java,
what matters is the concepts and ideas you will learn that matter.
Java is just a convenient language to get you started quickly.

Gr.
Steven

From:	VBDis
Subject:	Re: Language used to write compilers
Date:	30 Dec 2004 01:01:13 -0500

"Joe H." schreibt:

>I always thought that compilers were usually written in C/C++.

From the time before the invention of C it's a good tradition to write
an compiler in its own language. The first (stripped) version of an
new compiler can be written in any available language, then that
compiler can compile itself in the full featured version
(bootstrapping).

>Question - what languages are used to write compilers?

There exist(ed) several languages for the implementation of
compilers. The question is whether it's worth the time to teach the
use of such a language, in addition to teaching compiler construction
itself.

> My world is Unix/Linux - should I wait until a course is offered
>using C/C++?

IMO you learn more about compilers in general when you write an
compiler in and for other languages. Why would anybody ever write an
compiler other than for C/C++, if that language were sufficient for
all programming tasks? And why then would anybody want to implement
yet another C compiler, instead of using an existing one?

Take the chance to discover other worlds - else you'll never know what
you may be missing! ;-)

DoDi