Helping the FSF

I like new gadgets and have been tempted many times to acquire some of them (like new Android phones and tablets). Usually these gadgets have a short life though (until it becomes obsolete, but still useful) and then newer gadgets come along. One can go on spending money and chasing these gadgets.

These days, I do a bit more analysis. I really think hard if I really need those gadgets and whether I can live without one. More things in one’s life definitely means less available time for doing other things (like spending time with family or reading books) and certainly more pain maintaining them.

Moreover, most of these gadgets do not respect the user’s freedom. When you buy a stock Android phone, chances are that the bootloader of that phone is locked. What this means is that only binaries of the bootloader signed by the manufacturer can be installed. This is true of most (all?) phones available in the market currently. Clever people have deviced ways to keep the bootloader intact and still load alternate OS images (like the excellent CyanogenMod firmware for Android phones).

When one runs these modern gadgets, the Applications (or apps, as they are called these days) are tied to the users account. The Application distributor (like Google or Amazon) can remotely kill any of those application or the phone itself. This kind of application distribution is very different from the way a desktop computer application is distributed.

These kinds of scenarios are coming to the good old personal computing as well. The UEFI comes with similar restrictions (I have to admit that I haven’t read in-depth about UEFI itself).

The good folks at the FSF have been doing a lot of work on Software Freedom and educating the users on these issues (in addition to supporting a number of Free Software projects and defending the rights of the copyright holders as well). They need to pay the staff, host the machines and support various campaigns (print documents, flyers etc). All these needs money. Projects like Android are successful because they are standing on the shoulders of the great work done for the past few years on various Free Software projects (eventhough Android strives hard to avoid GPL for the userspace projects).

Please consider donating some money to the FSF. I have been a proud associate member of the FSF for many years now. Contributing money is the easiest thing one can do to help the cause. A better way would be to work on Free Software projects itself.

If you are thinking of buying a gadget, think carefully if you really need one and if so, choose one which respects your freedom and don’t become a slave of the manufacturer. Also please think of donating 10% of the cost you plan to spend to organisations like the FSF.

Syndicated 2012-01-18 08:00:00 from Ramakrishnan Muthukrishnan

Using cKanren in Racket

cKanren is a wonderful system created by Clair Alvis and the group at IU for relational programming. The definitive work about cKanren is this paper. cKanren builds on another wonderful system called miniKanren created by William Byrd and Prof. Dan Friedman of IU.

Off late, I started reading “The Little Schemer” series and started reading the awesome ”The Reasoned Schemer”, also by the same team that wrote miniKanren. cKanren is written in R6RS scheme and is developed on Chez, evidently. Since I wanted to use Racket and DrRacket environment, I started looking at changes to be done to make it run on Racket. What follows below are the instructions to setup DrRacket for cKanren programming.

• Download my fork of cKanren

  $ git clone git://github.com/vu3rdd/cKanren.git

• Switch to the ‘racketification branch’

  $ cd cKanren $ git checkout -b racketification racketification

• Now, make cKanren module visible in the Racket ‘collections’.

  $ raco link .

• Now, fireup DrRacket. In the definitions window, use the following as the language.

  #lang cKanren

• Hack away in cKanren!

Syndicated 2012-01-09 08:00:00 from Ramakrishnan Muthukrishnan

Sicp Challenge Progress

2011 had been an extremely interesting year. I feel very happy to have made good progress on my Programming Language Theory learning. I am also qute happy with my SICP challenge project, which was my only noteworthy side project. I am somewhere in the initial portions of chapter 4 right now and it had been worth every minute I spent on it.

I also started reading many books connected with SICP and Programming Language theory, like TaPL and EoPL. Discovering the work of Dan Friedman was an eye opener and I hope to spend many many hours in the next few years learning from his books. I also read “The Little Schemer” and am well into “The Seasoned Schemer” and on to “The Reasoned Schemer” as soon as I am done. I will happily recommend these great books for anyone starting with Scheme.

Syndicated 2011-12-23 08:00:00 from Ramakrishnan Muthukrishnan

Object Orientation in Scheme

Guy Steele once said that ”A closure is an object that supports exactly one method: apply.”

When I read it a few days ago, I could not get much meaning out of it. While reading the SICP chapter 3, section 3.1.1, a bulb lit in my brain and I finally understood (atleast I think so) what he meant. I dug into other literature on the subject and found some more interesting stuff. Read on.

Let us consider the same example discussed by Abelson and Sussman in section 3.1.1, namely the withdrawal of money from a Bank account. One natural way of representing an account is to have an account object which has a way to represent the current balance. The following code reproduces it verbatim from SICP.

(define (make-account balance)
  (define (withdraw amount)
    (if (>= balance amount)
        (begin (set! balance (- balance amount))
               balance)
        "Insufficient funds"))
  (define (deposit amount)
    (set! balance (+ balance amount))
    balance)
  (define (dispatch m)
    (cond ((eq? m 'withdraw) withdraw)
          ((eq? m 'deposit) deposit)
          (else (error "Unknown request -- MAKE-ACCOUNT"
                       m))))
  dispatch)

Let us analyze what is happening in the above code. The make-account procedure creates an “account” object, so to speak, which is initialized with the balance, as follows:

> (define acc (make-account 100))
> ((acc 'withdraw) 50)
50
> ((acc 'withdraw) 60)
"Insufficient funds"
> ((acc 'deposit) 40)
90
> ((acc 'withdraw) 60)
30

A call to make-account with an initial balance value creates a closure with the variable balance together with the internal routines: withdraw, deposit and dispatch. The value returned by make-account is the procedure dispatch. To call a particular method of the object, we pass it as a message to the closure. The returned procedure is then called with the arguments. This is rather the message passing style of object orientation. Now, how does this relate to the comment made by Guy Steele that “closure is nothing but an object with a single method - apply” ?

The above code can be re-written as follows:

(define (make-account balance)
  (define (withdraw amount)
    (if (>= balance amount)
        (begin (set! balance (- balance amount))
               balance)
        "Insufficient funds"))
  (define (deposit amount)
    (set! balance (+ balance amount))
    balance)
  (define (dispatch m . args)
    (case m
      ((withdraw) (apply withdraw args))
      ((deposit) (apply deposit args))
      (else (error "Unknown request -- MAKE-ACCOUNT" m))))
  dispatch)

All we have done is to use the case special form and use apply. The interactions with this new procedure is shown below.

> (define acc (make-account 100))
> (acc 'withdraw 20)
80
> (acc 'deposit 120)
200
> (acc 'deposit 120)
320
> (acc 'withdraw 40)
280

As we can see, this is a neat and easy way to create objects and explains Guy Steele’s statement regarding closures vs objects. In another blog post, we will see how to implement inheritance and other OO concepts. As you can see, Scheme is really cool and is an excellent platform for language experimentations and prototyping of ideas.

Syndicated 2011-01-07 08:00:00 from Ramakrishnan Muthukrishnan

Not dead yet

I have been silent in the blogosphere for the past few months. Life continues to be very busy. The SICP study group is progressing well. I am having a lot of fun interacting with Tom, Pradip, Martin and others. I am close to finishing chapter 2. Almost all the exercises have been completed and tons of things learnt. I wonder how some people find time to do the problems and blog about them.

I also switched to Scheme from Clojure as my language for doing SICP exersizes for many reasons. One important reason is the fact that the purpose of the whole thing is to do SICP and general principles of Computation. I find Scheme to be an excellent vehicle for that purpose. Thinking back, I think it was emacs + slime which was holding me back from trying other alternatives. :-)

And then it happened. I bought ”The Little Schemer” by Dan Friedman and Matthias Felliesen and simply fell in love with it. In my opinion, this little book is a much more important book in computing than the mighty Knuth and K&R. True, they have their place. But this book conveys some of the most important principles in computation in a simple Q&A style. I had a smooth sail through it until I hit the chapter on Y Combinator (aptly titled ”… and again, and again, and again .. “) which I had to read about 4 times and experiment on the repl to finally get it. Reading this book also motivated me to take a serious look at Scheme. I managed to grok some of the fine papers written by Dybvig, Felliesen and the other fine and friendly folks at the PLT. The PLT community and the mailing lists are one of the finest and helpful group of folks I have seen.

I am currently looking at Guile, the FSF’s own Scheme implementation. There are many factors which makes guile interesting. Guile is small, but at the same time good enough to be very useful to write large systems. It has a good C FFI and has a good module system, something I haven’t seen in the other Scheme implementation and is the closest thing to Common Lisp packages, in my opinion. It has a nice VM and a compiler, which is evolving. I hope I can learn a lot more by working with Guile than any other Scheme. Guile is actively being developed by Andy Wingo and others who can also be interacted with at the #guile irc channel, which is great. I use Emacs and geiser to interact with Guile.

Clojure was fun. I will return back to it when I have a need. I almost finished writing a blog engine with it and had a lot of fun writing it. But for now, Scheme definitely serves my needs for learning programming language fundamentals.

At this point, some people in the Clojure community are busy trying to get all the attention they can (and also sell some books, more in the works, so we will see a proliferation of such posts for the next many months) by posting every blog post they find on clojure to HN, Reddit and also repost the HN url back to twitter! The result of all these is that, a lot of people think Clojure is the first Lisp in this planet! I mean.. grow up, people! I am sure, they will settle down. Can’t resist posting this XKCD strip. But overall, over exposure of Clojure is good for all the Lisps.

I have a bunch of books waiting to be read or partially read:

• On Lisp (almost finished it, but planning to read again).
• The Lambda papers by Steele and Sussman.
• To Mock a mockingbird.
• PLAI (Shriram Krishnamurthi)
• EOPL
• PAIP
• The Joy of Clojure.
• ...

Syndicated 2010-10-19 07:00:00 from Ramakrishnan Muthukrishnan