PicoLisp in a chroot

Picolisp has a nifty feature where you can include inline c code, and it will be automatically compiled for you, and just work.

Unfortunately I'm on a 64 system, and pico dosn't at the moment compile under 64 bit. Now I'm told that if I install the right things and tweak the right options I can get 32 bit binaries to compile anyway. But that involves modifying the upstream source and I don't like doing that, unless I plan to submit a patch.

In this case It seemed somewhat pointless. So I though I'd try setting pico up in a chrooted environment. I came accross the following post on the matter: Installing apps in a 32-bit chroot in AMD64 Debian systems.

I followed most of step 1, with the following exceptions:

• I skipped step 1.3 (decided not to mess with my main gcc instalation.
• Installed gcc, and build-essentials into the chroot. (also locals and less which didn't get installed by default.
  
• Installed dchroot into my real system ( I think this is soemthing the tutorial does later).
• Compiled picolisp in the chroot enviroment and installed it to /usr/local/
  
• Added some scripts to my real path which would execute picolisp and psh in the chroot.

All in all it was a surprisingly easy process and at the end of it I have a fully functional picoLisp. which is accessible form anywhere. even the scripting is easy.

!#/bin/bash
dchroot --preserve-environment <> "$@"

This lets me run pico the same way weather I'm in the chroot or in the main system. And there are no gremlins. I started a picolisp server in the chroot, started firefox (I mean Iceweasel) in the main system, and everything worked, even the ondemand compilation of c from inside pico.

Partially I did this because I wanted to learn how to do it, and now that I have a 32 bit chroot I'll probably move my IceWeasel into it and install flash.

Hmm, I wonder which I'll see first, 64 bit PicoLisp or 64bit Flash? I have it on good authority that they are both in development.

PIcolisp Cookbook

One thing which picoLisp needs is a Cookbook. A set of recepies on how to use its quite rich set of primitives to solve particular problems. Currently most of this information is somewhat implicit in the Reference docs. And requires making some big inferences after considering which sets of functions have links to each other.

All of the built in functions are documented, what is missing at the moment however is the various idioms for using them in practice. Thankfully you can usually get a prompt answer on the mailing List.

I came acrose one such are the other day. I was trying to break a circular list, built by fifo, into a plain list. In Common Lisp I'd do this with set. so I tried it to no avail. In Pico (set (cdr A) NIL) actually sets the 2nd element of the lsit A to nil.

It turns out that to set the cdr portion of a cell I want a function called con. My first reaction to that was ... well that's annoying. But then I got to thinking that its not actually a bad thing. Essentially we have to setting functions which are subtly different.

set: is used for setting values, and con is used for manipulating structure. Yes things get a little confusing if you use cells to build a tree structure where both the car and cdr contain pointers to other cells. That aside I when reading code I can assume that calls to set will change values but not alter the underlyign datastructures, while calls to con will alter structure.

The more I think about it the more I like this distinction. It adds something usful to the code. In the end the only thing which tripped me up was documentation. The Picolisp docs are good as far as they go, but missing a few bits.

Alex, the maintainer of PicoLisp, seems somewhat reluctant to make the official documentation more verbose. Well we may have to agree to disagree on that one. But there has been talk of building a picoLisp wiki (powered by picoLisp). And this may go some way to adding the Cookbook style reference that appears to be needed.

Anonymous Recursive Function

I thought I'd give the 99 Lisp Problems a spin as a way of exploring Pico Lisp. One of my first outings came up with the discovery that if you call a function without enough arguments the remaining arguments get set to NIL this can be used to do default arguments as follows:

(de fun (X Y)
(let (Y (or Y 5))
  (+ x Y)))

(fun 1 2) -> 2

(fun 1) -> 6

I did this to simulate an accumulator argument in a recursive function. But then i got to thinking, I'm executing the let on each recursive call, which seems kind of a waste as it is only needed on the first call. Well Pico has an answer for this recur and recurse which allows you to define an anonymous recursive function. Now this is something you don't find in your garden variety common lisp!

a list reverse (yes I know its built in but it see the 99 Python problems above) is then implemented like this;

(de my-rev (lst)
 (let (res ())
   (recur (lst res)
          (if (pair lst)
            (recurse (cdr lst) (cons (car lst) res))
            res))))

That is one neat way to make do without auxiliary functions.

Lisp is addictive

A week or so of Pico Lisp and I'm addicted again. Now the label was right, this is no common Lisp. Part of this means that a lot of built in functions have different names but then lets be honest, 'filter' is a much better name then 'remove-if-not'. I also found that there is no 'reduce' function but it was trivial to implement.

I have to say that having having one name space for functions and variables works, and using quote as lambda is growing on me. Pico lisp is proving to be a very succinct lisp to program in, which is a good thing.

Time permitting I'll be doing a lot more pico lisp hacking in the near future, port a few scripts I've done in python as practice and then on to some more interesting stuff. I've got some pointers on how to mix pico lisp and c code, which will is bound to prove useful

Been away from Lisp too long.

Yes I'm sad to say that I've spent too long without messing about in Lisp. Now that I'm trying with pico lisp theres a lot of basic logic which seems to be bogging me down, such as when to quote and unquote things (though Pico lisp seems to be a little different in this regard).

Another omission, from the point of view of convenience, is the lack of a well developed string formatting function. Granted the built in symbol manipulation primitives are more general then a format function but in simple cases they lead to more verbose code. Note Pico Lisp does have a function called format but it is restricted to formating a single number as a fixed precision decimal.

Still I'm working slowly in adapting some examples from a Common Lisp book into Pico Lisp, and if nothing else its an enjoyable exercise.

It looks like I am on the Pico lisp mailing list, though I never got notified that my subscription request was accepted. Still I got to ask my question now, which is good.

Pico Lisp

In my continuing search for a language to play with, other than python, I came accross Pico Lisp the other day. A very intriguing lisp dialect for several reasons:

• Fully interpreted and yet faster then compiled lisp in some usecases
• Persistent storage (essentially an object database)
• built in Prolog.
  
• built in web server and support for online applications.
  
• No floating point numbers ?
  

That last point seems a little curious. but then i got to thinking how many applications out there really need floating point numbers? Well there are really a lot of applications that don't. In my day job I deal with online payments. No floating point numbers here, just express things as cents and be done with it.

Using floating point in financial circles is in general a big no-no, people get a lttle tucky when your working with money and make rounding errors. Also its a little hard to do anything with a fraction of a cent.

Graphics. Well yes and no. Fixed precision might be quite good enough. Heck there's a 3d flight simulator application to prove it even. The Documentation claims it can be easily extended with C, including writing C functions inline, unfortunately exactly how this is done, or what the limitations are, is not explained. Once I get onto the mailing list I plan to ask.

First impressions are that this is a very small, neat and yet still useful language. Time will tell if I can do something interesting with it though.