On 'Language Design and Implementation using Ruby and the Interpreter Pattern'
Honestly my main thought regarding this work is that I personally took the Programming Languages course at ITESM CEM a few semesters ago and unfortunately I do not recall hearing about the SIF. (This is not to say that the course was lacking or that I did not like it. The course was great and I did like it. I think I would have appreciated a bit more/tougher technical challenge in retrospect.)
My thoughts on the framework itself are that I see it as a pretty good tool for teaching programming language concepts. At this point in time I don't think that I have a deep enough knowledge about compiler implementation to say with certainty exactly how much overlap there is
between the techniques used to implement SIF and the compiler we're currently working on. I expect this position to change in the near future as we move forward to studying the later phases of coimpiler implementation.
Going back to the programming languages course I do remember having a feeling of redundancy while implementing the meracircular evaluator in Clojure (an excercise that we did go through very thoroughly in class. So thorough that I kind of want to remember being tested about it, but I can't really recall) so I completely agree with this work's statements about that topic and how this ruby implementation of the interpreter pattern is.
What I liked the most about Mr. Ortiz' SIF is its ergonomics. The ease with wich it is demonstrated that one can easily hack on top of it, implementing things that would traditionally be considered 'advanced' features with little effort. However though (actually I think this opinion is based on a lot of what I learned in the PL course, NOT to discredit SIF) I get this feeling that the essence of this ease of extension comes more from S-expressions being Lispy and following the lisp model of computation than from anything else.
My thoughts on the framework itself are that I see it as a pretty good tool for teaching programming language concepts. At this point in time I don't think that I have a deep enough knowledge about compiler implementation to say with certainty exactly how much overlap there is
between the techniques used to implement SIF and the compiler we're currently working on. I expect this position to change in the near future as we move forward to studying the later phases of coimpiler implementation.
Going back to the programming languages course I do remember having a feeling of redundancy while implementing the meracircular evaluator in Clojure (an excercise that we did go through very thoroughly in class. So thorough that I kind of want to remember being tested about it, but I can't really recall) so I completely agree with this work's statements about that topic and how this ruby implementation of the interpreter pattern is.
What I liked the most about Mr. Ortiz' SIF is its ergonomics. The ease with wich it is demonstrated that one can easily hack on top of it, implementing things that would traditionally be considered 'advanced' features with little effort. However though (actually I think this opinion is based on a lot of what I learned in the PL course, NOT to discredit SIF) I get this feeling that the essence of this ease of extension comes more from S-expressions being Lispy and following the lisp model of computation than from anything else.
Comments
Post a Comment