Lisp in Small Pieces

Amazon.ca was having an unexpected sale on Lisp in Small Pieces, one of the best books on implementing lisp. For about a day it was selling better than Harry Potter. Hmm. I'm implementing lisp, and I could always use a new book. My copy will arrive in two to four weeks. Until that time, CarbonLisp is going on vacation. In the meantime, I'll work on and blog about other projects.

Roadblocks and Dynamic Coding

What's happened since my last posting?

• Google's identified this blog as a potential spam-blog and locked me out. I've gotten it unlocked. I guess i need to post more often.
• I've gotten most of the framework code for the DLR finished. Nothing exciting, and I'm sure it's bug-ridden, but it's a start.
• I've started on the lisp reader, and I realized I don't know what I'm doing. Fools rush in where angels fear to tread, and all that. Part of the problem is that I'm really doing exploratory programming, but in a static language. I'm not a big static language fan, anyway. I'm considering doing a toy implementation of lisp in Python to get started and to figure out what I'm doing.

I know, I know. That last point is just crazy talk. Of course, this whole blog has turned into the ramblings of a madman, anyway, so why the hell not get some traction by doing some exploratory programming in Python, then moving back to C#.

Back from Vacation and Names

Most of last week I was on vacation. The rest of the week, I've spent a little time digging into ToyScript and filling out the framework I'll need for implementing lisp on the DLR. More about that later. I've temporarily decided to call this project SiliconLisp. This roughly follows the convention of naming dynamic languages for the CLR as Iron-. I've just changed the element it's made out of. Actually, I was originally going to call it CarbonLisp, but I didn't want to confuse this with the Mac windowing library Carbon. I may go with CarbonLisp anyway. If you have a suggestion for the name, please leave me a comment.

Looking into ToyScript

I'm checking out John Lam's ToyScript. It's an implementation of a small scripting language, and it was written as an introduction to working on the DLR.

Lisp and .NET

The Truth about Lisp Why does that link matter? Because I've been thinking about implementing Common Lisp on the CLR and the DLR. When interpreted, it would primarily work with the DLR, but as declare statements are added and the Lisp code becomes more static, it would be able to leverage the CLR directly. At one point, I was thinking about implementing Scheme, but I've moved away from that. When I started learning Common Lisp, I thought that I preferred Scheme. But now I've done a project in Scheme (a simple todo-list manager, similar to todo.txt, and I've decided that I prefer Common Lisp after all. Scheme's still great. I have a nice clean feeling whenever I code in it, but I think I prefer CL's more complete language specification. It's still not really complete enough. (Hello? threads, networking, Hello?) Also, I'm beginning to grok continuations, but I don't have a clue how I'd implement them in .NET. So I'm just not doing that right now. Still, what craziness is this? Well, I've been doing a lot of .NET at work, and I'd like to be able to use a more powerful, sane (for some definition of sane) language. I'd also like to be able to produce assemblies that can be called from C# or whatever. Basically, I want a lisp that is a first-class citizen of the CLR. And I've been wanting to do more Lisp for my personal projects. I'll let you know how it goes. Or I'll put my head between my knees and breath deeply until this latest light-headedness passes.

Update

I've had a post about Erlang and thinking concurrently in the works for a month, while life and work have gotten in the way. That article's still in the works, but I'd also like to resurrect this and post about some other things.

Erlang: The Pros

I had meant to post this much sooner, but there's been this thing called work. It gets in the way. Finally, here is the second half of my overview of Erlang. Concurrency Given it's background, it's no surprise that concurrency is easy and cheap in Erlang. Here's a contrived example:

12> PrintRandom = fun() ->              
        {A, B, C} = erlang:now(),           
        random:seed(A, B, C),
        io:format("~p~n", [random:uniform()])
        end.
#Fun

13> lists:foreach(fun(_) -> spawn(PrintRandom) end, lists:seq(1, 10)).
0.664105                                                             
0.664137
0.664170
0.664203
0.993887
0.993920
0.993953
0.993986
0.994019
0.994052
ok

First, the state for the random number generator is stored in each process, and it's initialized from a standard value. (Actually, maybe the random module should be on my Erlang: Cons list, although having the random module not produce random numbers probably makes debugging easier.) Line 13 spawns 10 processes, each of which prints a random number. Not very useful, but it should illustrate how easy it is to create processes. Also, you can easily spawn a lot processes. This code generates a random number and throws it away a million times in a million processes, and it executes in about 3.5 seconds on my machine:

-module(timespawn).

-export([make_random/0, spawn_random/1, ts/1]).

make_random() ->
    {A, B, C} = erlang:now(),
    random:seed(A, B, C),
    random:uniform().

spawn_random(0) ->
    ok;
spawn_random(X) ->
    spawn(fun make_random/0),
    spawn_random(X-1).

ts(X) ->
    timer:tc(?MODULE, spawn_random, [X]).

Distribution Another nice aspect Erlang is how easy it is to distribute processing. This is partially due to its open security model, which I listed as a negative. For example, in two separate console windows, I can start two different instances of Erlang. As long as I pass both the -sname argument (with different values) and the -setcookie argument (with the same value), they can talk to each other, even if they're on different computers in the same network. Functional I've worked with functional languages in the past, but I haven't really drunk the functional Kool Aid until now. I'm enjoying it this time, though, and want to start working more with one of the Lisps (probably Scheme), Haskell, or ML. When I do start on one (or more likely, on all) of these, I'm sure I'll talk about it here. OTP The OTP (Open Telecom Platform) is the standard Erlang library, and it contains modules that make writing fault tolerant, supervised, client-server, and distributed applications easy and fast. Conclusion I'm glad I've gotten to do a lot of Erlang recently. It's changed the way I think about concurrency and distribution, and it's raised my expectations of other systems that tackle the same problem. Even if I do most of my concurrent programming primarily in other languages, this will give me a good basis. And really, what more can I ask for from a programming language?