This blog post was originally posted on my blogpost blog at this URL, and was later migrated to this place. There may be some comments at the original URL.
Starting this week, I am going to try an experiment in blogging, where I would write about some of the interesting things I came across in previous week and my thoughts about those. I can’t promise to be regular about this, but I am definitely going to try. :-)
I have been relatively offline for past some time, so there aren’t many items on the list below, but I hope for this to change in near future.
A typical approach to writing interpreters involves modelling an AST with algebraic data types, and then using pattern matching and combinators to process it. This is very convenient and powerful, but has flaws that we may have missed but which couldn’t sweep past Oleg’s eyes. :-) This paper discusses an alternate approach where AST nodes are modelled as abstract functions bundled in a module (in this case, a type-class). The paper goes on to show how this approach improves upon the ADT approach, in terms of extensibility, and for making a “computational context” explicit. The latter bit is especially interesting, and to understand it, you are going to have to read the paper.
I have known about dependent types for fairly long now, but still haven’t gotten around to exploring them. They are on my list, but they’re likely going to have to wait a couple more years. (I am too busy now with err… other stuff.)
Nevertheless the post was quite interesting to me. It’s good to see the kind of things one can put types to use at.
See Robey Pointer’s post on using Scala code as config.
As application grows, configuration needs go on becoming more and more complex. Most configuration formats and libraries of the day show a surprising lack of many features you’d want in configurations. My colleague Mushtaq pointed me to this post by Robey Pointer where he proposes using Scala code as configuration. I am not entirely convinced this is a great idea, but something worth considering surely.
On a similar note, Clojure world has come up with EDN (extensible data notation). This pursues an opposite goal (kinda): Taking a “data” subset of your programming language (Clojure), and using it to represent configurations. The prime benefit here is syntactic and conceptual congruity between code and configurations.
Lighttable is written in Clojurescript, and lives up to the Lisp spirit of using it to “create a language in which to write your program”. Chris Granger first built a custom object system suitable for his goals (comprising of three main elements which he refers to as “objects”, “behaviors”, and “tags”), and then built rest of the application on top of it.
Apparently this system makes writing plugins for this IDE very easy. There has been a wave of Lighttable plugins. This is one of those. You can find others, for OCaml, Haskell etc, by some googling and githubbing (I would be a teensy bit disappointed if latter isn’t a thing yet). Should you feel tempted to write a plugin, here is a tutorial that may get you started. (Warning: Haven’t read it myself yet.)