4 ms·

Another interesting thing to try (and maybe complementary as well) is building an interpreter or compiler for a language you like, trying to match the spec and

by austinz 12y ago

Another interesting thing to try (and maybe complementary as well) is building an interpreter or compiler for a language you like, trying to match the spec and feature set as closely as possible, and (hopefully) gaining more insight into the tradeoffs the language designers made when deciding why things are the way they are.

SloopJon 12y ago
Yes, I've written tools for existing languages, and found just getting the parser right to be a challenge, be it with Emacs highlighting, flex/bison, what have you. Real languages aren't as tidy as the textbook examples.
- seanmcdirmid 12y ago
  When I do PL these days, I always start with the editor; e.g. see: http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx http://research.microsoft.com/en-us/people/smcdirm/managedti... Co-designing your editor with your language allows for a better experience. You are right in that all of this is basically undocumented in textbooks. Even their presentation on on parsing is mostly unhelpful (if you want an error tolerant incremental parser for your editor, recursive descent works very well).
  - handojin 12y ago
    That is really cool. This focus on time is what draws me into the whole clojure/datomic world. We're ill equipped to handle it. Tools help. Does time itself reveal itself as the horizon of being?
    - seanmcdirmid 12y ago
      We can manage time one way or the other. Clojure does it with a focus on immutability, I'm doing it with a focus on mutability :) One thing that is cool is how time is related to observation, the same thing that happens in quantum entanglement. If you don't observe the state of an object, time doesn't really exist.
stormbrew 12y ago
I did that with Ruby[1]. I learned things nobody should ever have to learn. But I also came away with a much greater appreciation for the basic model it uses, most of the biggest warts are at the surface (flip-flops, bizarre rules around how arguments get passed to blocks when the block takes one argument, etc). The way metaclasses work is, imo, one of the most elegant object models I've seen for the amount of power it gives you. It only took a couple hundred lines of code to implement reasonably correctly [2]. And along the way, I wrote another language for expressing some of the higher level VM-stuff (object model, exception propagation, etc). I definitely recommend targeting languages that already have robust test suites. It makes things a lot easier. I was going to do a JS implementation a while ago, and there is a pretty solid suite for that from the ECMA[3], but it's kind of hard to extract. One of the things that made ruby so fun was that the test suite that existed at the time was rubyspec, which is actually written in ruby. Just getting to the point where I could run the specs was a huge moment where the implementation reached a measure of usability. [1] https://github.com/stormbrew/channel9 https://github.com/stormbrew/channel9 -- it's a perennial project for me, it can run an old version of mspec+rubyspec as a ruby 1.8.6 implementation. Note that I skipped the parsing, leaving that to an existing parser written in ruby, because parsing ruby is a bigger project than a ruby-compatible VM. [2] https://github.com/stormbrew/channel9/tree/master/environments/ruby/environment/kernel/alpha https://github.com/stormbrew/channel9/tree/master/environmen... -- see class.c9s and object.c9s for the vm specific script the fundamental implementation of language features is written in. [3] http://test262.ecmascript.org/ http://test262.ecmascript.org/

by austinz 12y ago

SloopJon 12y ago

Yes, I've written tools for existing languages, and found just getting the parser right to be a challenge, be it with Emacs highlighting, flex/bison, what have you. Real languages aren't as tidy as the textbook examples.

seanmcdirmid 12y ago
When I do PL these days, I always start with the editor; e.g. see: http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx http://research.microsoft.com/en-us/people/smcdirm/managedti... Co-designing your editor with your language allows for a better experience. You are right in that all of this is basically undocumented in textbooks. Even their presentation on on parsing is mostly unhelpful (if you want an error tolerant incremental parser for your editor, recursive descent works very well).
- handojin 12y ago
  That is really cool. This focus on time is what draws me into the whole clojure/datomic world. We're ill equipped to handle it. Tools help. Does time itself reveal itself as the horizon of being?
  - seanmcdirmid 12y ago
    We can manage time one way or the other. Clojure does it with a focus on immutability, I'm doing it with a focus on mutability :) One thing that is cool is how time is related to observation, the same thing that happens in quantum entanglement. If you don't observe the state of an object, time doesn't really exist.

stormbrew 12y ago

I did that with Ruby[1]. I learned things nobody should ever have to learn. But I also came away with a much greater appreciation for the basic model it uses, most of the biggest warts are at the surface (flip-flops, bizarre rules around how arguments get passed to blocks when the block takes one argument, etc). The way metaclasses work is, imo, one of the most elegant object models I've seen for the amount of power it gives you. It only took a couple hundred lines of code to implement reasonably correctly [2]. And along the way, I wrote another language for expressing some of the higher level VM-stuff (object model, exception propagation, etc). I definitely recommend targeting languages that already have robust test suites. It makes things a lot easier. I was going to do a JS implementation a while ago, and there is a pretty solid suite for that from the ECMA[3], but it's kind of hard to extract. One of the things that made ruby so fun was that the test suite that existed at the time was rubyspec, which is actually written in ruby. Just getting to the point where I could run the specs was a huge moment where the implementation reached a measure of usability. [1] https://github.com/stormbrew/channel9 https://github.com/stormbrew/channel9 -- it's a perennial project for me, it can run an old version of mspec+rubyspec as a ruby 1.8.6 implementation. Note that I skipped the parsing, leaving that to an existing parser written in ruby, because parsing ruby is a bigger project than a ruby-compatible VM. [2] https://github.com/stormbrew/channel9/tree/master/environments/ruby/environment/kernel/alpha https://github.com/stormbrew/channel9/tree/master/environmen... -- see class.c9s and object.c9s for the vm specific script the fundamental implementation of language features is written in. [3] http://test262.ecmascript.org/ http://test262.ecmascript.org/