resources on PL design

139 views
Skip to first unread message

Stephen De Gabrielle

unread,
Jun 28, 2019, 8:13:17 AM6/28/19
to us...@racket-lang.org
Hi,

I'm looking for resources on PL *design*., i.e. deciding what to make and how to assess/test those design decisions,  before moving onto how to make it. 

Any additions, opinions or advice appreciated:

Programming Languages: Application and Interpretation by Shriram Krishnamurthi  https://www.plai.org/

Programming Language Pragmatics by Michael L. Scott

Practical Foundations for Programming Languages by Professor Robert Harper

Design Concepts in Programming Languages (The MIT Press) by Franklyn Turbak

Kind regards,

 

Stephen

 

* the languages are not important but FYI: Cobol, vb6, vb.net, C/C++, PHP, Python, c#, Java, MUMPS & JavaScript. 

Stephen De Gabrielle

unread,
Jun 30, 2019, 7:24:26 AM6/30/19
to Racket Users
I've added EOPL and some others. I obviously haven't read all these, but have added them because they refer to PL design or implementation in description or TOC.
Thanks to those who responded.

Books

  • Programming Language Pragmatics by Michael L. Scott
  • Practical Foundations for Programming Languages by Professor Robert Harper
  • Principles of Programming Languages: Design, Evaluation, and Implementation by Bruce J. MacLennan
  • Advanced Programming Language Design by Raphael Finkel
  • Lisp in Small Pieces by Christian Queinnec and covers 'semantics and the implementation of the whole Lisp family of languages, namely Lisp, Scheme and related dialects. It describes 11 interpreters and 2 compilers'
  • Structure and Interpretation of Computer Programs - teaches computer science by teaching students how to implement interpreters. (see also the Racket #lang sicp designed to go with the book)

Stephen De Gabrielle

unread,
Jun 30, 2019, 8:22:19 AM6/30/19
to Racket Users
Hi,

More contributions tacked on the end. Suitability for developers embarking on designing and implementing and language is yet to be assessed.

I find it hard to determine if some of the PL design advice I see on the web is backed by any evidence. Some linked material may be authors opinion or personal taste.

Thanks again to all who helped. Corrections welcomed.

S.


Other

I don't know whether these fit the bill:

"Growing a Language" by Guy Steele https://www.youtube.com/watch?v=_ahvzDzKdB0 The remarks on language design begins at the 40 minute mark. (If you haven't seen it before, don't skip the beginning of the talk)

Brian Kernighan on Language Design: https://www.youtube.com/watch?v=Sg4U4r_AgJU

Also interesting, but not on language design: Anders Hejlsberg on the gap between how compilers are taught and how modern compilers work. https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction

ACM Programming Usability SIG meeting 2016http://www.cs.cmu.edu/~NatProg/programminglanguageusability/ 2016 meeting notes: http://tinyurl.com/ProgLangUsabilitySig (Google docs)

Special Interest Group on Programming Languages The ACM Special Interest Group on Programming Languages (SIGPLAN) explores programming language concepts and tools, focusing on design, implementation, practice, and theory. Its members are programming language developers, educators, implementers, researchers, theoreticians, and users.https://www.acm.org/special-interest-groups/sigs/sigplan


Sam Caldwell

unread,
Jun 30, 2019, 10:32:36 AM6/30/19
to Stephen De Gabrielle, Racket Users
I'd add the HOPL proceedings to the mix:

https://hopl4.sigplan.org/track/hopl-4-papers#History-of-HOPL

Where the designers of languages often talk about their motivations, why they made particular decisions, and what kinds of effects those decisions seemed to have.

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAGHj7-KOEDGxyXfQ3m2p%3D1rAHsaqTWRBHYGfmriv_Lq%3DpXdPAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Stephen De Gabrielle

unread,
Jun 30, 2019, 12:05:25 PM6/30/19
to Sam Caldwell, Racket Users
Thanks. Added. 
(despite horrible ACM paywall)

Kind regards 
Stephen
--
----

Matthias Felleisen

unread,
Jun 30, 2019, 5:47:59 PM6/30/19
to Stephen De Gabrielle, Sam Caldwell, Racket Users

Sam’s advice is good. You might be able to find draft versions of ACM HOPL articles on the authors’ web sites (or likely others who taught from these articles, because many of these articles appeared before the web and some of the authors are dead). 

In general, I think we lack a design theory for PL. What we have is an analysis theory (which is often written down with interpreters and/or horizontal lines combined with Greek letters, and some Hebrew thrown in on occasion because we run out of the others). 

We also lack a design empirics, even though some first articles and dissertations in this direction are appearing. I just happen to be extremely skeptical of the results. I just don’t think we know how to ask the questions properly. See https://felleisen.org/matthias/Thoughts/The_Laffer_Curve_of_Types.html for an idea of what I mean. 

— Matthias





Neil Van Dyke

unread,
Jul 1, 2019, 8:54:12 AM7/1/19
to Stephen De Gabrielle, Racket Users
Lots of earlier HOPL papers are experience writeups relevant to the
question of PL design.  (For example, Alan Kay did a great history of
Smalltalk, which talks about more than just the language design itself,
and the language design was influenced by the other things.)

Separate from what's in HOPL, there are other related writeups floating
around.  Most recently, I saw Kent Pitman did an interesting one on
Common Lisp standardization (you'd also want look at whatever Guy Steele
says about that, John McCarthy's HOPL on Lisp in general, and various
other Lisp people's reports):
http://www.nhplace.com/kent/Papers/cl-untold-story.html

Closer to home, there's Scheme.  I don't know all that's currently
written up about Scheme history (and it's ongoing, including with RnRS
and various implementations), but most of the players are still around,
and they should probably be encouraged to write if they haven't
already.  Olin Shivers wrote an account of T:
http://www.paulgraham.com/thist.html

Then there's various papers and writeups on other Lisps (Clojure, Arc,
Dylan, more researchy), which might be interesting in what they chose to
change (not just added features), and why.

Separate from PL histories, and various models of computation, I think
we start to get into human issues like linguistics and aesthetics, and I
don't think that's well-understood in PL, nor does it seem to be the
same for everyone.  (For example, simply from looking at how people use
Racket syntax, put roughly, it looks like some people seem to use visual
while others seem purely verbal or mathematical; what happens when
someone from one of those categories tries to design an intuitive or
convenient language for everyone, but everyone isn't processing the
language the same way?)

Neil Van Dyke

unread,
Jul 1, 2019, 8:54:12 AM7/1/19
to Stephen De Gabrielle, Racket-Users List
(This is a resend.)

Neil Van Dyke

unread,
Jul 1, 2019, 10:56:49 AM7/1/19
to Matthias Felleisen, Stephen De Gabrielle, Racket Users
That entire famous Smalltalk issue of Byte magazine is now online, as
good-quality scans, so you can read all the articles, and juxtaposed
with ads of a magazine of the time:

https://archive.org/details/byte-magazine-1981-08

This was before my time, and, when I was reading this issue recently, I
was struck by the effort that PARC made to reach out to mainstream
industry practitioners and enthusiasts.

This was shortly before the home microcomputer explosion, when everyone
ended up getting BASIC instead of Smalltalk.  (Though you could see a
lot of interest in education, even with some of the nice BASIC books
some vendors bundled with each computer, but not all the various PARC
goodness.)

We did get the Macintosh a few years later, though it was out of the
budgets of many people, and it didn't adopt a lot of the PARC thinking.

Matthias Felleisen

unread,
Jul 2, 2019, 5:43:15 AM7/2/19
to Neil Van Dyke, Stephen De Gabrielle, Racket Users

Stephen, since Neil mentioned Alan Kay’s highly informative(*) HOPL essay, let me also point you to Ingalls’ essay (which Robby pointed out to me about a year ago):

http://web.archive.org/web/20070213165045/users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html



(*) One of his guidelines is “abolish assignment statements”. I loved it when I could use this in my ECOOP keynote way back :)
> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/8cab8e8a-593e-a7d2-fa56-ef9b163503c5%40neilvandyke.org.

Stephen De Gabrielle

unread,
Jul 4, 2019, 3:25:08 PM7/4/19
to Neil Van Dyke, Matthias Felleisen, Racket Users
Thank you everyone. I go so many good suggestions that I had to split the page into four pages; 

"The Racket [[language development toolchain]] for [[Creating Languages]] includes the Racket language(s), command line tools, IDE and a range of packages to support developing languages."

[[language development toolchain]] https://github.com/racket/racket/wiki/language-development-toolchain summarise the tools for language construction

https://github.com/racket/racket/wiki/Language-Design has Racket specific resources on creating language

[[Language Design]] https://github.com/racket/racket/wiki/Language-Design Covers lists on language design including the HOPL papers, Lisp, smalltalk and other materials, including https://archive.org/details/byte-magazine-1981-08 


I'm not particularly happy with the splits or arrangement so feel free to make suggestions - no matter how radical - or 'have at it' and have a go at editing. It's easy enough that I can do small edits using my phone while commuting - if you make a mistake it is easy to rollback. As I mentioned on slack the reason I do this is because it is easy, and I believe the dominance of GitHub means it will be how some programmers first come across Racket. 

Thanks again, 

Stephen

Reply all
Reply to author
Forward
0 new messages