Archive for April 2008

The Emacs client

I know that for most Emacs users out there this is not worth writing about, but I have been using Emacs for less than two years and I cannot help hiding my awe everytime I discover something like this. This time is the emacsclient program.

Unfortunately at work I am stuck with Windows. I am a long-time Vim user so I have it installed, which adds an “Open with vim…” entry to the Explorer shell. This opens a new Vim instance everytime it’s used. A similar approach won’t tempt Emacs users because you do not open Emacs everytime you open a file. You open Emacs once a week or once a month and keep it running. So enter emacsclient.

It acts as an independent program for an external caller. When started, this program looks for an already running instance of Emacs and connects to it, which then acts as a server and edits the requested file (to accept connections, server-start must have been run in Emacs. I have it in my .emacs file). When the user is done, he types C-x # in the server buffer. Then emacsclient exits and the external caller assumes the editing application has quit.

This is very useful, for instance, for writing commit log messages. My EDITOR environment variable points to emacsclient. Everytime I need to commit code in Subversion or Monotone, the log message appears as a new buffer in my running Emacs. It is also useful for the Firefox extension It’s All Text!, which allows one to use an external text editor to edit web forms. And, of course, I have added an “Edit with Emacs…” entry to my Explorer shell, so I can open any file into a running Emacs very quickly.

Instructions about how to add the shell shortcut can be found in the Emacs wiki.

DSLs are cool

One of the most promoted features of the Lisp dialects is how easy it is to create Domain Specific Languages with them. It is said that a Lisp programmer creates a language for the domain of his problem and then solves the problem as a particular case. That is why a lone developer or a small team can have so much power, because they are quickly dealing with a language customised
for them. In my case, one of the domains of my problems is the stock
market.

I am writing a very simple application in Scheme, with Gambit-C Scheme, for helping me trade stocks (nothing fancy, I am still an amateur). This application is going to have a comprehensive set of technical indicators which are calculated based on opening, closing, maximum and minimum stock prices as well as the volume traded, number of operations, number of stocks traded etc. Clearly these indicators must be first-class citizens of this small financial world. Once added to the system, I must know how many I have, what is the name the user should see for each of them and the parameters they take. Besides, its syntax must
allow users of the system to add indicators of their own without knowing the inner details of the system.

To accommodate those needs I have come up with a little language for my indicators. For instance, these are the Volume and Force Index indicators:

(indicator volume (x)
  "Volume"
  (volume x))

(indicator force-index (x)
  "Force Index"
  (if (> x 1)
      (* (- (closing (- x 1)) (closing x)) (volume x))
      0.0))

The indicator syntax allows me to give the indicator a user-friendly name, and to automatically add it to my indicator list. But there is something more subtle and interesting about them: the helper procedures. The procedures closing and volume are examples of procedures available to indicator writers. They cannot be lexically scoped, because they depend on the current stock being analised and the current sampling frequency (daily, weekly etc.). They must be bound to the appropriate procedures just in the scope where the indicators are being run. In Common Lisp this is easily done with special variables. In Scheme we have the SRFI-39, Parameter objects. But since the parameter objects act syntatically like closures, using them directly would demand that the indicator writer use a cumbersome syntax like:

(indicator force-index (x)
  "Force Index"
  (if (> x 1)
      (* (- ((closing) (- x 1)) ((closing) x)) ((volume) x))
      0.0))

This is very undesirable. The solution, in face of the lack of special variables, is to use a code walker. Due to the unique syntax of Lisp, this whole process can be combined into a simple macro:

(define-macro (indicator name args desc . body)
  (letrec ((helpers '(opening closing maximum minimum
                      volume num-operations num-stocks
                      num-samples))
           (walker (lambda (sexp)
                     (if (pair? sexp)
                         (let ((opr (car sexp))
                               (args (cdr sexp)))
                           (if (memq opr helpers)
                               (cons `(,opr) (map walker args))
                               (cons opr (map walker args))))
                         sexp))))
    `(let ((,name (lambda ,args ,@(map walker body))))
       (set! *indicator-list* (cons (cons ,desc ,name)
                                    *indicator-list*)))))

And that’s it. From now on I need to think only about indicators, and not where to put them, how to supply them helpers, what’s the frequency of their samples etc. They are high-level abstractions which are now part of my language.