
How the first Pascal compiler was written - dchest
https://raw.github.com/gist/1535291/da3f7f01a2c015cda3901986c6be820c9abd0175/gistfile1.txt
======
tankenmate
"After this experience, it was hard to understand that the software
engineering community did not recognize the benefits of adopting a high-level,
type-safe language instead of C." -- N. Wirth

I suspect that the good programmers did notice the benefits of a strict
statically typed language, however the cost was probably deemed to be too high
at the time. Because C was a "mid-level language" and stayed close to the
metal it could efficiently use the limited resources of pre-LSI (let alone
VLSI) computers; effectively C allowed you to break the rules if you wanted or
needed to. These days obviously the performance difference is generally less
than a few percent and hence can be largely ignored.

~~~
kabdib
Pascal's I/O was broken. Strings were broken.

Every Pascal I ever worked with (with the exception of the Pascal I used in
school) had extensions to make it work in the Real World. Unextended Pascal
was a toy.

Apple was a Pascal shop in the 80s, but they extended it to the point that I
just translated (in my head) the C code that I wanted to write into the
variant of Pascal they'd implemented. Pascal had a couple of nice things that
C didn't (nested procedures, for one), but they weren't used all that much by
us.

Strings were still a pain. Str255 stunk, and everyone knew it, but nobody had
anything that was dramatically better.

~~~
pmiller2
I disagree. Unextended Pascal is not a toy: it's a tool to teach computer
science and structured programming. In a classroom environment in the 1970's,
it's not relevant that strings have to have a defined, fixed length. I'm not
100% sure what you mean by I/O being broken, but I'd wager that's not a big
deal in a classroom environment, either. In any case, evaluating unextended
Pascal as anything other than a teaching tool is like complaining that a
hacksaw isn't very good for screwing in screws. Talk about "wrong tool for the
job!" :-)

~~~
Avshalom
The quote -from Wirth himself- was not about classroom environments, it was
about software engineer(s|ing).

~~~
pmiller2
True. But, "high-level, type-safe language" need not refer to unextended
Pascal, and I see no evidence that it was intended to. He could have meant
Algol W. Depending on when it was written, he could have meant Modula 2,
Modula 3, or Oberon.

~~~
kabdib
Serious question: Why is it that we generally see only toy systems being done
in these languages.

I don't mean to offend. If I'm unaware of major pieces of software done in
Modula-N or Oberon, then feel free to correct me.

I only know of some teaching-level and research OS work, and some GUI work,
but little in the way of commercial stuff.

------
dchest
Full paper "Good Ideas, Through the Looking Glass" by Niklaus Wirth [PDF]:
[http://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas_ori...](http://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas_origFig.pdf)

~~~
ericbb
I just skimmed through it and there's a really controversial claim in there
that the functional paradigm was a bad idea!

I also found it surprising that he disliked Dijkstra's display idea since I've
used a variant of that to great effect.

Anyway, there's a lot of fun reading in there so thanks for the link! Here's a
discussion on Lambda the Ultimate: <http://lambda-the-ultimate.org/node/1773>

------
rpearl
I'm always a bit hazy on why people bootstrap languages by writing compilers.
I've always imagined it would be easier to write an AST-walking interpreter,
write the compiler in the source language, and then interpret the compiler
taking its source as input, to produce the first binary.

I guess I've never actually bootstrapped a compiler, but I've always found the
interpreters I've written to be easier to reason about than the compilers I've
written.

~~~
pjmlp
Bootstrapping a compiler is a good way to test how the language feels when
writing a big project like a compiler. It also helps to find errors in the
language/implementation.

~~~
rpearl
In my proposed way to bootstrap a compiler, you still write the compiler in
the language you wish to compile. You also write an interpreter, rather than
another compiler for the same source language, written in some other language
for which a compiler already exists. This means that the amount of code you
are writing to get the language up and running is smaller, since interpreters
are easier to write than a whole second compiler.

So what you say is true--it is a good way to see how the language feels--but
not relevant to the facet of language development I was musing about.

------
sdevlin
So they had three tools to choose among. One was broken, one was wildly
unsuitable, and one was unpopular. They chose the second for (apparently)
purely cultural reasons. I think it's not so surprising that they ran into
problems.

Don't discard unsexy solutions out of hand; choose the right tool for the job.

~~~
kd0amg
Was assembly really the right tool for this either? It seems like the
difficulty of translating Fortran to Pascal due to Fortran's lack of many of
Pascal's higher-level features would still apply to assembly.

~~~
sdevlin
I think so. Wirth called out Fortran's lack of pointers, records, and
recursion. You have (or can fake) all of these things in assembly. Recursion
is particularly important for building a compiler, since much of it involves
manipulating trees.

Also, consider the stated goal of the project. They wanted to write a
throwaway compiler so that they could bootstrap a Pascal version. In this
case, it's a bad choice to use a language (Fortran) that's so different from
Pascal. On the other hand, assembly is very flexible, so you can use whatever
idioms you think will apply in the Pascal code you later intend to write. This
will make the translation much simpler.

------
dugmartin
I'm not a big Lisp fanboy, but I wonder why it wasn't considered an option for
at least bootstrapping the compiler? I think even if no Lisp was available on
their machines that hand coding one in assembly and then using that would have
been much faster than other options (note: it's been 20+ years since my
college Programming Languages class (where ironically I built a Lisp-1 in
Pascal) so I may be mis-remebering my programming language history here)

------
JulianMorrison
Shoulda used Forth. It'd be fairly easy to go from assembler to an ultra bare
bones Forth, and that could be built up to _work like_ Pascal, until it looks
like Pascal-written-backwards. Then write the compiler in that, and the
translation and bootstrap would be trivial.

~~~
RodgerTheGreat
My first thought as well, but in 1969 Forth was still busy being born. Based
on the notes here[1], many of the core concepts of a modern Forth like
defining words and the structure of the dictionary were being actively
hammered out.

[1] <http://www.colorforth.com/HOPL.html>

------
guard-of-terra
I wonder which "high-level" features does Pascal have which C lacks. When I
looked into Pascal, literally everything useful there came from C. All things
originating in Pascal seemed useless.

~~~
weinzierl
Pascal has nested functions and supports a limited form of closures.

In Pascal, a function can be passed as an argument to another function, but
cannot be stored in a variable or data structure, cannot be returned from a
function, and cannot be created without being given a name. However, when a
function is passed to another function and later called, it will execute in
the lexical context it was defined in, so it is, in some sense, "closed over"
that context.

I also liked the I can pass parameters per value or reference without
explicitly using pointers.

~~~
guard-of-terra
In C a function pointer can be passed around, and usually a pointer to contect
structure is passed around. That happens to be more practical.

References are cool. That makes one point for Pascal.

~~~
barrkel
Nested routines in classical Pascal support downwards funargs; they are
closures lite, i.e. actually more expressive than C functions. But we are
talking classical Pascal; every practical commercial Pascal implementation
supports function pointers directly, just like C does.

------
billforsternz
I'm confused. He starts off by asserting there were only three options;
Assembly, Fortran or Algol. But then later on an essential part of the process
turns out to be "a syntax-sugared, low-level language, for which a compiler
was available". So why wasn't that apparently anonymous language one of the
base options ?

~~~
mayoff
I think that was the "compiler for a substantial subset of Pascal using
Fortran" that they originally planned to translate to Pascal after
implementing it in Fortran.

~~~
billforsternz
Ok, thanks, I guess that makes sense.

------
akkartik
_"Never contain programs so few bugs, as when no debugging tools are
available!"_

But that's for the initial draft. What of its later evolution?

