
Principles of Programming Languages (1997) [pdf] - matt_d
http://www.cs.nott.ac.uk/~pszgmh/popl.pdf
======
siraben
Denotational semantics are a great way to capture the meaning of a programming
language. If your language provides a denotational semantics it's a nice
exercise to implement them in a functional language. For instance, here's my
implementation of R5RS Scheme in Haskell following the spec's semantics.[0]

A lot of toy Scheme implementations omit call/cc for instance because it can
be hard to reason about and do correctly, whereas following the spec made it
really easy.

[0] [https://github.com/siraben/r5rs-denot](https://github.com/siraben/r5rs-
denot)

~~~
jpz
"Denotational semantics are a great way to capture the meaning of a
programming language" \- big claim - what is the meaning of a programming
language?

For example, if you able to capture what the meaning of a programming language
is, then could you please demonstrate by communicating what "the meaning of
the programming language" C is, for instance? This appears to be a nonsensical
combination of words, as I do not recognise a programming language as having
an intrinsic meaning?

~~~
nv-vn
I think you're thinking of the wrong definition for "meaning." OP is talking
about what code in a language means, i.e. when I see the code say `1 + 2` does
that mean that the numbers signed or unsigned? Are they arbitrary precision or
a certain size? What errors can result from the addition? Etc. It's
essentially saying that you can look at a piece of code and formally define
what it means to the computer

------
p0llard
This seems pretty good from a brief flick through; the author. Graham Hutton,
is pretty well known in the CS community.

Some other resources for people who find that this piques their interest and
that they want to go deeper:

* _Formal Reasoning About Programs_ ("FRAP") by Adam Chlipala - available for free here: [http://adam.chlipala.net/frap/](http://adam.chlipala.net/frap/). Forms the basis for 6.822 at MIT, and comes with an accompanying Coq formalisation (as well as psets in Coq).

* _The Formal Semantics of Programming Languages: An Introduction_ by Glynn Winskel.

~~~
siraben
I'd also add

* _Essentials of Programming Languages_ by Friedman and Wand [http://eopl3.com/](http://eopl3.com/)

It's quite accessible and has an emphasis on executable implementations.
Covers quite a wide variety of paradigms, FP, FP with mutation, type checking,
type inference, and objects and classes.

~~~
tom_mellior
Another good one is:

* _Concrete Semantics_ by Nipkow and Klein [http://concrete-semantics.org/](http://concrete-semantics.org/), which is also an introduction to the Isabelle/HOL proof assistant and formalizes all of the PL content in Isabelle

There's also:

* _Semantics with Applications: An Appetizer_ by Nielson and Nielson [https://www.springer.com/gp/book/9781846286919](https://www.springer.com/gp/book/9781846286919), apparently a newer edition of an older book I liked and which used to be available as a free PDF, but the link from my browser history is now broken

------
dang
If curious see also

2017 (1 comment)
[https://news.ycombinator.com/item?id=13575213](https://news.ycombinator.com/item?id=13575213)

The pdf is marked 2016 but probably dates from much earlier, so maybe it's
best not to put a year in the title.

~~~
stevesimmons
Late 1996 or early 1997, based on the PDF's reference to Hugs 1.3.

The Hugs 1.3 manual is dated August 1996. Hugs 1.4 is from 1997. And then came
Hugs98.

~~~
dang
Nicely done. Added!

------
mathgladiator
This is timely, I'm reviewing this deck just after working a grueling day on
my language and tuning the language runtime for performance.

What's interesting is how many things we can now intuitively take for granted,
but for each idea someone had to suffer and make it real. Their primary
barrier was people via communication and getting traction.

~~~
hn3333
I like your second paragraph. This is true for large parts of life and a good
reason to work hard and leave something behind for future generations.

