1. 14
  1. 4

    This is a great talk, and I saw a lot of the issues first hand while hacking on the CPython interpreter for Oil (e.g. http://www.oilshell.org/blog/2018/11/15.html) The surprisingly complex semantics of “a + b” is one example I remember from the talk (which I watched a few years ago).

    At the beginning of the Oil project I thought I would reuse some of the CPython interpreter for Oil, but that’s no longer the case. That would be essentially importing a lot of undocumented semantics from a specific implementation, which I don’t want. Ironically, writing interpreters in C leaves a lot of room for bugs to hide, but writing interpreters in Python is less prone to that.

    Python is deceptively clean on the outside :) It has a nice regular syntax (with few of the oddities of say Perl or Ruby), but the semantics are full of corner cases. I think this is somewhat inherent in all languages, e.g. Rust too. Reading the source code is often the only way to understand the corner cases.

    The “specs” often approach the size of the source code, i.e. they essentially need to cover every if statement in the interpreter. That’s why I think executable specs have a lot to recommend them, in contrast to docs like POSIX or the C++ standard.

    1. 1

      Any new language should be designed (i.e. specified) “semantics-first”. Broken syntax is much easier to repair than broken semantics.

      1. 5

        Sure, let us know how that works out :)