4 ms·

Principles of Programming Languages (1997) [pdf]

99 points by matt_d 6y ago

dang 6y ago
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 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - dang 6y ago
    Nicely done. Added!
p0llard 6y ago
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.
- matt_d 6y ago
  General Program Analysis Resources may also be of interest: https://gist.github.com/MattPD/00573ee14bf85ccac6bed3c0678ddbef#program-analysis-resources https://gist.github.com/MattPD/00573ee14bf85ccac6bed3c0678dd...
- siraben 6y ago
  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 6y ago
    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
mathgladiator 6y ago
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 6y ago
  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.
siraben 6y ago
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 6y ago
  "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 6y ago
    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

99 points by matt_d 6y ago

dang 6y ago

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 6y ago
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.
- deleted 6y ago
  [deleted]
- dang 6y ago
  Nicely done. Added!

p0llard 6y ago

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.

matt_d 6y ago
General Program Analysis Resources may also be of interest: https://gist.github.com/MattPD/00573ee14bf85ccac6bed3c0678ddbef#program-analysis-resources https://gist.github.com/MattPD/00573ee14bf85ccac6bed3c0678dd...
siraben 6y ago
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 6y ago
  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

mathgladiator 6y ago

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 6y ago
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.

siraben 6y ago

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 6y ago
"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 6y ago
  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