zslug

My first seven moths in Zürich have been packed with pleasant surprises. Among them, having the opportunity to meet two developers of two of my favourite lisps: Martin Gasbichler, of scsh‘s fame, and Juho Snellman, of sbcl‘s. I’ve already enjoyed several pleasant discussions with them (as well as with some co-workers interested in lisp), and it was only natural to go one step further and found the Zürich Scheme/Lisp Users Group.

The zslug will have its inaugural session next Monday 25th, 18:30 at The Lion. Besides beer (the raison d’etre of any users group), Juho will talk about the implementation of sb-cover, a code coverage tool for Common Lisp. If you happen to be in Zürich or whereabouts by then, just come in and join the fun!

Update: The actual address of The Lion is Oetenbachgasse 24. Hope to see you there!

The way to go

A long, long time ago, in what seems now another galaxy, Scheme (in its Guile incarnation) was destined to be Gnome’s extension language. It even featured one of the best window managers i’ve used, until its author disappeared under an apple tree (not that it uses Guile, i know, but it’s extensible using a Lisp dialect too). These Mono days, all those good intentions are forgotten, except for a few fine hackers like Andy Wingo. He’s been putting together an impressive set of Guile bindings for many libraries in the GTK+ and Gnome families and, recently, he’s started documenting them. A first stab is available here. Yeah, Guile is not the nicest Scheme around, nor is Gnome my favorite desktop environment, but still it’s good to see people striving to make our computer world a better place to live. Way to go, Andy!

Posted in Scheme. 2 Comments »

Scheme on the Erlang VM

Recently, someone in the Erlang-questions mailing list wondered about the possibility of writing a Scheme-to-Erlang compiler, possibly inspired on earlier work by Marc Feeley and Martin Larose on Etos, a Erlang-to-Gambit compiler (don’t miss the great article Compiling Erlang to Scheme about Etos’ implementation). Well, Marc has risen to the bait and produced a prototype implementation of Stoe: join the fun and get it here!

Playing with Eli’s toys

Some weeks ago, as a way to give a serious try to the PLT environment, i wrote my first (and only so far) PLT package, MzFAM, a File Alteration Monitor for MzScheme. MzFAM consists of a set of PLT-scheme modules providing utilities to monitor and react to filesystem changes. It exports a high-level interface consisting of monitoring tasks that run as independent threads and invoke callback procedures each time a file alteration is detected. These high-level tasks are implemented using either Linux’s FAM/Gamin monitors or, in systems where it is not available, a pure Scheme fall-back implementation. (A native implementation for BSD systems, based on the kevent/kqueue system calls (see also this nice article to learn more), is on the works.)

As you’ll see in the link above, i took the time to (try to) write a decent user manual, using tex2page (which is included in the PLT distribution, but can be used as a standalone program), a nice tool to write HTML manuals using TeX markup and, if you’re so inclined, embedded Scheme directives.

mzfam 2.pngMzFAM’s implementation served me as an introduction to a couple of wonderful Scheme libraries, both of them authored by Eli Barzilay. In the first place, i needed a foreign function interface to access FAM’s C library. Eli’s FFI is just a piece of beauty: aided by the magic of dlopen and friends, one can access C libraries without writing a single line of C code. See, for instance, this wrapper of the kevent/kqueue system calls, which will hopefully work as a non-trivial example while you read the FFI manual. Will Farr has also put the FFI to pretty good use recently.

MzFAM has to choose at run time among several underlying implementations of the monitoring, and i’ve used generic functions to fulfil this need. No rocket science here: run-of-the-mill polymorphism is enough, but i took the chance to play with the second of Eli’s jewels, namely, his implementation of CLOS for Scheme, Swindle. Now, Scheme object systems are a dime a dozen, and many of them claim some degree of resemblance to CLOS, but Swindle is, by a long stretch, the closest to the real thing i’ve used–why, there’re even some syntactical spots where it is actually nicer than CLOS itself, and is the only (besides Dorai Sitarm’s ScmObj) Scheme object system i know of that provides before/after/around advising. Swindle also comes with a fairly complete MOP implementation, and i’m looking forward to using it after reading Andreas Paepcke’s book on CLOS (which, incidentally, i bought after reading its freely available chapter 3, User-Level Language Crafting: Introducing the CLOS Metaobject Protocol (PS)). All that said, please don’t take MzFAM as a good example of putting CLOS to work: i’m just a beginner.

Finally, let me mention another nice PLT feature i’ve used (although this one is not, as far as i know, an Eli’s hack): the PLaneT Package Repository. Extremely convenient, and a breeze to setup, both from the user’s and the developer’s perspective, and yet another reason for giving PLT a serious try.

Happy monitoring!

Posted in Scheme. 3 Comments »

Erlang, Termite and a Blog

In his soon-to-be-published book, Joe Armstrong proposes the following exercise:

Write a ring benchmark. Create N processes in a ring. Send a message round the ring M times. So that a total of N * M messages get sent. Time how long this takes for different values of N and M.

and he adds

Write a similar program in some other programming language you are familiar with. Compare the results. Write a Blog and publish the results on the Internet!

Since i happen to be learning Erlang and, besides, know of another programming language providing Erlang-like primitives, i thought i’d take Joe’s bait and give you a little taste of how Erlang feels to a newcomer.

This is my implementation of the ring in Erlang. If you’re an Erlang hacker, be prepared to be scared: this is my first longer-than-ten-lines program–but, please, do not hesitate to criticize it as deserved!.

-module(ring).
-export([make_ring/2]).

make_ring(N, M) -> spawn(fun() -> sender(N, M) end).

sender(N, M) ->
    FirstPid = self(),
    NextPid = spawn(fun() -> tunnel(N, 2, FirstPid) end),
    statistics(runtime),
    statistics(wall_clock),
    do_times(M, 0, fun(I) -> NextPid ! I end),
    NextPid ! done,
    receive done -> done end,
    {_, Time1} = statistics(runtime),
    {_, Time2} = statistics(wall_clock),
    U1 = Time1 * 1000,
    U2 = Time2 * 1000,
    io:format("Total time=~p (~p) microseconds~n", [U1, U2]).

do_times(N, N, _) -> done;
do_times(N, J, Fun) -> Fun(J), do_times(N, J+1, Fun).

tunnel(N, N, FirstPid) -> tunnel(FirstPid);
tunnel(N, J, FirstPid) -> 
     tunnel(spawn(fun() -> tunnel(N, J+1, FirstPid) end)).

tunnel(Pid) ->
    receive
        done -> Pid ! done;
        Any -> Pid ! Any, tunnel(Pid)
    end.

Here you can see some of Erlang’s niceties: first class, anonymous functions (using the fun() -> [body] end lambda constructor); function definition by cases (a la Haskell: guards are also admitted) and pattern matching; message mailboxes using receive (also using pattern matching) and the send operator !; easy process creation with spawn; and the pretty no-frills but extremely convenient module system (one would write ring:make_ring(A,B) to call our ring launcher: the Erlang shell will find and load the ring module as long as the file is in the load path). You may also have noticed that there is no variable mutations, or that lower case atoms (like done) are automatically interpreted as symbols. Tuples also make an appearance: they are constructed using braces (as in {_, Time1}) and you assign values to its components, again, by pattern matching. And, oh, those tail recursive calls to tunnel and do_times are properly optimized by the Erlang interpreter.

Although the above is just a subset of the language’s features, it’s enough to show why i like Erlang: it reminds me of Scheme in many ways, while borrowing some interesting bits from ML languages and even Prolog. On top of it, it fulfills Alan Perlis desideratum on programming languages: it changes the way you think, as recently noticed by one of my favourite bloggers. (It is also worth mentioning that Erlang comes charged with a pretty nice library, excellently documented, that has recently gained a slick search interface.)

But back to Joe’s problem. As it happens, there’s ‘one other language i’m familiar with’ (Scheme) that provides and Erlang-like library (Gambit‘s Termite), and rewriting the program was a breeze:

(define (make-ring n m) (spawn (lambda () (sender n m))))

(define (sender n m)
  (define (display-time msg start end)
    (display (list msg (- end start)))
    (newline))
  (let* ((fist-pid (self))
         (next-pid (spawn (lambda () (tunnel n 2 fist-pid))))
         (rt (real-time))
         (ct (cpu-time)))
    (let loop ((m m))
      (cond ((= 0 m)
             (! next-pid 'done)
             (recv ('done
                    (let ((nct (cpu-time))
                          (nrt (real-time)))
                      (display-time "CPU time: " ct nct)
                      (display-time "Real time: " rt nrt)))))
            (else (! next-pid m)
                  (loop (- m 1)))))))

(define (tunnel n j first-pid)
  (cond ((= n j) (send-recv first-pid))
        (else (send-recv (spawn (lambda () 
                                   (tunnel n (+ 1 j) first-pid)))))))

(define (send-recv pid)
  (recv
   ('done (! pid 'done))
   (x (! pid x) (send-recv pid))))

If you’re a Schemer, you’ll readily understand the code above, which uses the same primitives as Erlang: !, recv (since receive is taken in Gambit) and spawn.

What about the comparison? Well, i love Scheme and, to my biased eyes, Gambit’s version is more beautiful. So let’s move to something that is not in the eye of the beholder: speed. Running ring:make_ring(5000, 1000) in my laptop gives the following output:

Total time=970000 (1520000) microseconds

while typing (make-ring 5000 1000) at the Gambit’s interpreter prompt yields:

CPU time: 19.442507999999997 secs
Real time: 19.780327081680298 secs

So, the Scheme interpreter is about 20 times slower than the Erlang interpreter (the factor seems to be more or less constant when you change the number of processes or messages sent). But Gambit has a secret weapon: it’s a Scheme to C compiler (why, it’s actually called Gambit-C!). So I compiled my program and ran it, with the following result:

CPU time: 2.3031090000000005 secs
Real time: 2.3484270572662354 secs

The interpreted Erlang code is still more than twice quicker than the compiled C code. Not bad: the more i look at that Erlang program, the more beautiful it looks!

Of course, this is just a toy benchmark which says nearly nothing about the real performance of either Erlang or Termite. I just thought it could be a way of whetting your appetite and get you started in these to systems that i’m just discovering. Googling for Erlang and Termite will direct you to several recent blog entries discussing them and helping you to join the fun, but, lest you miss it, let me recommend this Termite mini-tutorial by Marc Feeley.

And again, if you discover any of the silly things i could do better in the programs above, please leave a comment: i’m just learning!

Easter egg

After some years playing with other implementations, i’ve been using the PLT-Scheme suite assiduously during the last weeks (more on what for in future posts), and it’s becoming, slowly but surely, my default implementation. Eli Barzilay‘s extensions to make MzScheme play nice with Emacs were the trigger, but i must say that DrScheme’s macro stepper, debugger and syntax checker (all of which i had not seriously used before) are fine pieces of hackery. If you’re into scheme, you really should take a look at them. Another strong point of PLT scheme is its excellent documentation, which comes with a browser called HelpDesk. I use it all the time, and this morning it saluted me with an unexpected background:

200704090100

Let me join the toast, and wish Shriram a happy birthday too! (and, while i’m at it, thanks also for your wonderful PLAI). It must be nice being a PLTer, mustn’t it?

Scheme loops

If you’re a schemer, expressing iteration by means of tail-recursion and named lets has probably become second-nature to you. I find this idiom both natural and elegant, but as Olin Shivers points out in his DanFest presentation below, it has some drawbacks. For instance, the code in a typical named let will work only for a given sequence type (e.g., a vector or a list); and, as Olin explains, its ‘goto-nature’ does not mix well with lexical scope. In other words, tail-recursive schemy iteration is too low-level and, according to Olin, a higher-level abstraction hiding details and providing a modular interface and proper lexical scope is called for. In his presentation, he outlines his solution to this problem, which, as you will see, amounts to defining a looping domain-specific language (actually, a couple of them). A more detailed explanation is given in his paper The Anatomy of a Loop. As an extra, the first few minutes of the video below will get you acquainted with the mysterious  Dan effect.

But Olin’s is not the only solution to looping in scheme. Alex Shinn wrote and excellent survey on Scheme iteration methods in his Yow! LOOP macros are LOOPY!, which discusses at length current approaches to solve the problems mentioned above (like srfi-42 eager comprehensions or Jonathan Amsterdam’s iterate macro). For extra fun, Alex includes implementations for most of the loop constructs he reviews, a good way of improving your macro programming.

(Also worth reading in this context are Oleg Kiselyov’s thoughts on collection traversal APIs, where he draws a clear distinction between enumerators (such as scheme’s for-each or fold) and cursors (such as C++ iterators, i.e., objects maintaining internally the “current element” of the collection being traversed). As you will see, he makes a pretty good case for enumerators.)

So, you see, there’s many a way to loop a cat!

Posted in Scheme. 2 Comments »

Classic Texts in Computer Science

Babar Kazar has compiled an awesome (and i mean awesome) list of Classic Texts in Computer Science. There one finds almost every paper to read if one is serious about computers. The list is too long to put it all here, and virtually all of them are interesting in one way or the other, so i won’t make a selection right now: just take a look at them, and try to pick one: i bet you’ll have a hard time deciding!

Although it’s a bit late for new year’s resolutions, here is mine: i plan to at least skim through all these texts, read many of them, and, of course, keep you informed.

A (video) celebration

On December 3 and 4 of 2004, the Computer Science Department at Indiana University hosted a conference on the occasion of Dan Friedman’s sixtieth birthday. It brought together many of his former and present students, colleagues, research collaborators, co-authors and friends. That is, it brought together many of the big names in the Lisp/Scheme community (not in vain Shriram Krishnamurthi once imagined the Scheme community “a brotherhood of Dan”). Guy Steele delivered a one hour keynote, which was followed by more than twenty half-an-hour talks by people like Sussman, Dybvig, Shivers or Kiselyov, just to name a few.

The extremely good news is that, in the conference’s webpage, one can find the videos for almost all these talks! So, don’t be surprised if i’m missing during a few days! Besides the obvious interest in their contents, i’ll also find amusing to connect names with faces (it’s funny how one makes up fictitious faces for the authors of papers one reads and re-reads)… how many of them do you recognise?:

(I admire the work of many of these people, and i was convinced i wouldn’t be able to single out one among them… but to my surprise, and with all due respect to all schemers, i can: to my amusement, one of the participants is one of my few personal heroes. I’m not sure about the connection between him and Dan, but i’m very pleased to know there’s one. Surely you can spot this (to me, at least) rara avis?)

Quantum hype

One of the things i would really, really like to see some day is a working quantum computer. Quantum mechanics is deep magic that nobody really understands, but we have learnt a lot about how to use it during the last century–including its application to some kinds of computation. As you surely know, the most outstanding quantum algorithm is Shor’s prime factorization, which allows factoring a number N with a time complexity O({(\log N)}^3). That means that we go from exponential to polynomial time when going from classical to quantum for this particular problem (and related ones: the Wikipedia article on QC gives a pretty good survey; see also David Deutsch’s introductory lectures). I’m stressing the last point because there’s a widespread misconception that quantum computers will be able to solve NP-complete problems in polynomial time. Not so. On the contrary, experts are almost sure by now that this won’t be the case (note, by the way, that factoring is not NP-complete).

The most recent examples of such bogus claims are the reports on D-wave’ demos of their ‘quantum computer’, which are surrounded by piles of hype. So please, before taking them at face value, see Scott Aaronson’s The Orion Quantum Computer Anti-Hype FAQ (more here here here). Scott Aaronson is an expert in the field and the author of a PhD thesis under the title Limits on Efficient Computation in the Physical World (for a less technical introduction to quantum computing, see his nice Quantum Computing Since Democritus lectures). For an executive summary, here’s the first entry in the FAQ:

  • Q: Thanks to D-Wave Systems — a startup company that’s been in the news lately for its soon-to-be-unveiled “Orion” quantum computer — is humanity now on the verge of being able to solve NP-complete problems in polynomial time?
  • A: No. We’re also not on the verge of being able to build perpetual-motion machines or travel faster than light.

The old rule applies: no silver bullet. But, of course, their limitations notwithstanding, quantum computers would (will?) be an interesting challenge for us programmers, and we do not have to wait for the hardware to play with them: see this Brief survey of quantum programming languages, or a more in-depth description of how an imperative quantum programming language looks like, although, if you ask me, functional quantum languages like QML are nicer. Simon Gay has also put together a comprehensive Bibliography of Quantum Programming Languages.

Finally, if you’d rather write some code, there’s André van Tonder’s Scheme simulator (which will work with any R5RS scheme), and a QML simulator written in Haskell. Haskellers will also enjoy Jerzy Karczmarczuk’s Structure and Interpretation of Quantum Mechanics: a functional framework.

Happy quantum hacking!

Follow

Get every new post delivered to your Inbox.

Join 29 other followers