merge :: Ord a => [a] -> [a] -> [a]
merge []     bs                 = bs
merge as     []                 = as
merge (a:as) (b:bs) | a < b     = a : merge as (b:bs)
                    | otherwise = b : merge (a:as) bs

We have two base cases where either one of the argument lists may be null, in which case we just return the other. For the recursive case, we just cons the lesser of the two list heads onto the rest of the list, and leave the other list head attached to its list in-place. Simple and elegant.

So the Stream version should be just as easy, right? Let’s see.

mergeS_wrong :: Ord a => Stream a -> Stream a -> Stream a
mergeS_wrong (Stream nexta sa0) (Stream nextb sb0) = Stream next (sa0, sb0)
    where
      next (sa0, sb0) =
          case (nexta sa0, nextb sb0) of
            (Done, sb) ->
                case sb of
                  Done        -> Done
                  Skip sb'    -> Skip    (sa0, sb')
                  Yield b sb' -> Yield b (sa0, sb')
            (sa, Done) ->
                case sa of
                  Done        -> Done
                  Skip sa'    -> Skip    (sa', sb0)
                  Yield a sa' -> Yield a (sa', sb0)
            (sa, sb) ->
                case sa of
                  Done        -> Done -- shouldn't happen
                  Skip sa'    -> Skip    (sa', sb0)
                  Yield a sa' ->
                      case sb of
                        Done                    -> Done -- shouldn't happen
                        Skip sb'                -> Yield a (sa', sb')
                        Yield b sb' | a < b     -> Yield a (sa', sb0)
                                    | otherwise -> Yield b (sa0, sb')

Looks like a wordier version of the first. We take the first element of each stream, and use a case expression to check each of our cases. The first two base cases are a little longer this time because we can’t just return the other stream, but instead have to either Skip or Yield over the remainder of the Stream. In the third case, we must Skip over the first Stream until we Yield a value, and then do the same for the second stream. We compare the two values, Yield the lesser, and return the two remaining Streams.

The only problem is that this won’t compile. GHCi gives us the following error message:

*Main> :load "/home/mike/Projects/Haskell_SVN/NumWords.hs"
[1 of 1] Compiling Main             ( /home/mike/Projects/Haskell_SVN/NumWords.hs, interpreted )

/home/mike/Projects/Haskell_SVN/NumWords.hs:59:53:
    Could not deduce (Data.Stream.Unlifted (s, s1))
      from the context (Data.Stream.Unlifted s1)
      arising from a use of `Stream'

What’s this Data.Stream.Unlifted type? Turns out that our Stream data type is encapsulated by a universally quantified type s that is an instance of the hidden type class Unlifted. The standard Haskell pair type (,) isn’t, unfortunately, an exposed instance of this class. Which means that we can’t make a Stream out of a pair of Streams, as we did on the second line of code with Stream next (sa0, sb0).

Or so I thought. That is, until I realized (after much hand wringing) that the library did expose a data type that would allow us to use our own types — or, indeed, all of the standard Haskell types, such as pair. The type we need is

data L a = L a
instance Unlifted (L a) where
  expose (L _) s = s

Now we have a wrapper data type that acts as a dummy instance of class Unlifted! So (after about four hours of head scratching), we can make the following small changes to our code:

mergeS :: Ord a => Stream a -> Stream a -> Stream a
mergeS (Stream nexta sa0) (Stream nextb sb0) = Stream next (L (sa0, sb0))
    where
      next (L (sa0, sb0)) =
          case (nexta sa0, nextb sb0) of
            (Done, sb) ->
                case sb of
                  Done        -> Done
                  Skip sb'    -> Skip    (L (sa0, sb'))
                  Yield b sb' -> Yield b (L (sa0, sb'))
            (sa, Done) ->
                case sa of
                  Done        -> Done
                  Skip sa'    -> Skip    (L (sa', sb0))
                  Yield a sa' -> Yield a (L (sa', sb0))
            (sa, sb) ->
                case sa of
                  Done        -> Done -- shouldn't happen
                  Skip sa'    -> Skip    (L (sa', sb0))
                  Yield a sa' ->
                      case sb of
                        Done                    -> Done -- Shouldn't happen
                        Skip sb'                -> Yield a (L (sa', sb'))
                        Yield b sb' | a < b     -> Yield a (L (sa', sb0))
                                    | otherwise -> Yield b (L (sa0, sb'))

All we had to do was wrap our Stream pairs in the type constructor L to give our Stream pairs access to “free” instance deriving from the Unlifted class. Easy? Well, once you notice that unassuming data L a = L a in the documentation. But hey, it sure beats trying to do something like this in C!

I’d like to combine this approach to concurrency with Hybrid Type Checking. While I’d prefer to do as much at compile time as possible, I have a suspicion that we’ll always need to do some locking and unlocking at compile time, and that a system using both static types and runtime contracts might be our best bet.

I’m taking a stab at implementing these ideas in Java — but instead of modifying the compiler itself, I’ll be writing an annotation processor that will run before the compiler. The idea is that we could extend the Java type system using annotations. We could even go so far as to generate code at compile time that could do either runtime contract checking, or even lock and thread management. This is similar to the project Java Defensive Programming. If I can get this project off the ground, I’ll have to see if Federico would like to incorporate some of my code in his project.

All of this sounds like a job for XML – though I’m sure some would find this more overkill than LaTeX. But with a simple XML language, or perhaps even XHTML with class and span tags, I think I can make this happen. There are already two open “standards” for the job, XML Resume and hResume microformats, but I use the word “standards” very loosely. The XML Resume project on SourceForge hasn’t been updated since 2005, and I’m not convinced that the microformats solution completely solves the problem of keeping content and formatting orthogonal – though it gives us the great benefit of having a fully indexable online resume.

My idea is to use either XML Resume or hResume (or some bastard of the two) to write the content of the resume, but then use an OO plugin to import the resume language into OO, where we can use it’s great formatting tools. If I can get this rolling, we could also write a corresponding plugin for MS Word, so that I can send off resumes to Microsoft shops.

Now that I think about it, this is basically the model-view-controller pattern. The model is the XML representation of the resume, and all the different data points that you may want to include at some point in a real resume. The word processor is the view, where you can make your resume look as pretty as you want. The controller is the plugin that allows you to have your pretty resume template backed by data in the XML file – and, if the plugin does what I want it to do, display certain bullet points while hiding others, change the order of items, etc.

I’d really like to get this project started, but every time I think about it it’s because I need to work on my resume. And so I find myself in the programmer’s endless dilemma: do I build a tool to solve the problem for me, or do I just solve the problem? My resume is looking pretty good, so I hope I’ll find some time to work on this plugin.

We studied Scheme in that class, which is why my prof recommended that we all use Emacs. Scheme is a variant of Lisp, which is the language that Emacs is built around. And Elisp, as it’s called, is a great embedded language for customizing Emacs. You could think of it as Visual Basic for Applications, which is Microsoft’s language for customizing Office products, but much more simple and powerful to use (as long as parentheses don’t scare you).

I’ve only got one or two friends that might consider themselves to be Emacs gurus, and one of them wrote me the other day with a challenge. “I believe this problem is trivial,” he said, which is never a good sign, “but I’ve only had 20 minutes to think about and I’ve got to run.” He had been working on an Emacs library to help him configure a massive Ant build script. Part of his build process involved him logging into numerous test and dev machines, and he wanted to automate that in Emacs. He had written a list of interactive functions that would allow him to rlogin into each machine by typing M-x machine (M stands for Alt, or Meta, in Emacs, and is used to specify commands from the keyboard). These functions were each defined with syntax like the following:

(defun machine1 ()
  (interactive)
  (rlogin "machine1" "*machine1*"))

This list of functions had grown quite a bit in the months since he implemented this feature, and he wanted to find a way to automatically define a function that would log him into a specified machine by simply typing M-x machine. Easy, right?

A first attempt

My first approach to this problem was to create an association list of functions and their names. We would create a single interactive function that would select and run the appropriate generated function.

(defun my-login (fn)
  (interactive "sWhich function? ")
  (funcall
    (cdr (assoc (read fn) my-fnassoc)))))

There are a few things going on in this function. The (interactive "sWhich function? ") statement tells Emacs that this function can be called interactively using the M-x my-login syntax. The strange string “sWhich function? ” is just a format string telling Emacs to prompt the user for a string argument (the “s”) with the prompt “Which function? “. If this were a multivariate function, we would simply break each format string with a “\n” character in order to prompt for each of our arguments. The read function just turns our argument string into a symbol, and the call (cdr (assoc (read fn) fnassoc)) looks the symbol up in the association list my-fnassoc. funcall executes the returned function. Now we just need to build my-fnassoc.

(defun mkfunls (name)
  (let* ((host (prin1-to-string name))
         (buff (format "*%s*" host)))
    `(,name . (lambda () (rlogin ,host ,buff)))))

This function creates a single association pair of the form (host . login-function). Since our name parameter is a symbol, we need to convert it to a string using prin1-to-string. The Emacs rlogin command allows us to specify the name of the buffer in which we spawn the remote shell. We can use the format function to create a standard buffer name for each rlogin session we create.

The final line of mkfunls takes advantage of Lisp’s backquoting feature. The syntax looks a little strange at first, but if you can put up with Lisp’s other oddities then there’s no sense not learning about backquoting too. Quoting in Lisp, accomplished with either the quote special form or the abbreviation ' (a single apostrophe). Quoting prevents evaluation of the form being quoted, so evaluating (+ 1 2) returns the value 3, while evaluating (quote (+ 1 2)), or the equivalent '(+ 1 2), returns the value (+ 1 2) instead.

Backquoting accomplishes the same thing, but allows the programmer to selectively specify which parts of a list are to be evaluated and which parts aren’t. It’s called backquoting because we use a backwards apostrophe (` — found under the tilde) instead of quote or the regular apostrophe. We select the forms we want to evaluate using a comma. So the line `(,name . (lambda () (rlogin ,host ,buff))) evaluates the name, host, and buff variables but quotes all the rest of the symbols. So the call (mkfunls 'machine1) evaluates to (machine1 lambda nil (rlogin "machine1" "*machine1*")). Now all that’s left is to create our host/rlogin association list and we’ll be able to log in to remote hosts with a single command.

(setq my-fnassoc (mapcar 'mkfunls '(m1 m2 m3)))

This creates an association list with the host names m1, m2, m3 and sets the variable my-fnassoc. The function mapcar applies it’s first argument, in the case the function mkfunls, to it’s second argument, which must be a list.

Now when we type M-x my-login we receive the prompt “Which host?”, to which we can reply with any of the hosts we specified in the my-fnassoc list above.

But this doesn’t quite solve my buddy’s problem, does it? His list of login functions, while a little cumbersome to maintain, defined interactive functions at the top level, which allowed him to run M-x machine1 instead of the more indirect call to M-x my-login above.

A better solution

What we want is to automatically generate named, interactive functions. My initial thought was that this was a perfect task for macros, but it turns out that we don’t even have to bother with macros to make this work. Instead, we’ll use the backquoting syntax from above to build up defuns and then evaluate them.

(defun mkdefun (name)
  (let* ((host (prin1-to-string name))
         (buff (format "*%s*" host)))
    (eval
     `(defun ,name () (interactive) (rlogin ,host ,buff)))))

This is very similar to our mkfunls function above. Instead of returning an association list, we’re evaluating a defun. We use the backquote syntax to selectively evaluate the name, host, and buff variables. eval then evaluates the defun for us and creates a new top level definition. We can then map over a list of function names like we did before:

(mapc 'mkdefun '(m1 m2 m3))

mapc is like mapcar, except that it doesn’t return the a list of the results of the function evaluations. This is useful when we only care about a function’s side effect and not its results.

So now we have a simple method to automatically generate repetitive Emacs commands. All we have to do is append new function names to the list in the mapc command and we have a new function!