On UTF-16 vs. UTF-32

It'd be more space-efficient [to use UTF-16] in most cases, and less time-efficient in all cases (either "somewhat so" or "grossly so".) Using UTF-16 internally is probably not nearly as far down the Bad Idea scale as... oh, Huffman-coded arrays would be. ("Newly created arrays are full of 0s! Why waste 31 or 63 extra bits? Of course, this makes (SETF AREF) hard, but you could have a bit somewhere!")

Gary Byers in openmcl-devel, discussing (here and here) why variable-length encodings are a bad idea for the internal representation of Lisp strings. An enlightening read, as usual.

Gugla Kodsomero 2007

Mi ĝojas pro tio, ke mi estis akceptita de Guglo por partopreni ties programon Kodsomero 2007. Tio estas programo kies celo estas doni eblon al studentoj labori en liber-programaraj projektoj ricevante iom da mono dum la (nord-hemisfera) somero.

Mi jam partoprenis antaŭe, en 2005, kaj estis bonege. Ĉi tiu blogero, en la angla, havas pliajn detalojn pri mia ĉi-jara projekto. Ĉu partoprenos ankaŭ aliaj esperantistoj?

Sweet Summer of Lisp

Yay! I have been accepted into Google's Summer of Code 2007 thanks to LispNYC. The project I will be working on is IOLib and you can check out my proposal. Any suggestions you may have for this project are welcome!

If I had to pick the single most important event during my participation in the 2005 edition, it would have to be when Christophe Rhodes suggested I should have a look at James Bielman's then recent project CFFI. Hadn't he done that, I wouldn't have had the great pleasure of getting to know James, working with him, learning from his code, etc... So, please, send those great suggestions to luismbo at gmail dot com!

I had sent another proposal, “Metaobject Sealing for CLOS”, which was a very cool idea suggested by Christophe (again) and I was actually expecting that one would be picked instead. I already had some code and was avidly reading the AMOP, not to mention that I even printed out SBCL's PCL source code. Oh well. If nobody picks that idea up, I would love to work on that after the summer. <blink>Perhaps ITA or Clozure could fund that.</blink>

You can see the list of accepted Lisp projects here.

One last thought. While I realize that it's not easy for Google to work around this, I find it pretty sad that students from Iran, Syria, Cuba, Sudan, North Korea or Burma aren't allowed to participate in this program. I sure hate politics.

XCL

Peter Graves, of ABCL fame, has been working on this new Common Lisp compiler for a while now. Here's how he describes it:

XCL is a new, native-code CL implementation that features a kernel written in a very restricted subset of C++ and an optimizing compiler, written in Lisp, with backends for x86 and x86-64. It runs on Linux and Windows [...]

XCL supports threads on both Linux and Windows, and in principle the compiler is re-entrant.

Recently, and this is the actual news, Peter made available a link to a source code snapshot in #lisp. I couldn't resist trying it out, so here are some superficial first impressions:

• It has an interpreter written in C++ and it uses that to bootstrap itself. This is similar to what ABCL does, though it seems that, at this point, it doesn't actually compile (all of?) its own Lisp code. Also, Peter says he's working on getting it to bootstrap SBCL.

• Friendly REPL similar to Allegro's.

• It features a neat, readable disassembler.

  CL-USER(10): (disassemble (compile (defun inc (x) (1+ x))))
  ; Compiling INC
  ; Disassembly of #<FUNCTION INC {F84820}>
  ; Constants:
    NIL
  ; Code:
    E1BF50: 55                 push    %rbp
    E1BF51: 48 89 E5           mov     %rsp,%rbp
    E1BF54: 57                 push    %rdi
    E1BF55: 48 83 EC 08        sub     $0x8,%rsp
    E1BF59: 48 89 F8           mov     %rdi,%rax
    E1BF5C: 48 89 C7           mov     %rax,%rdi
    E1BF5F: A8 03              test    $0x3,%al
    E1BF61: 75 08              jne     L0
    E1BF63: 48 83 C0 04        add     $0x4,%rax
    E1BF67: 70 02              jo      L0
    E1BF69: C9                 leave
    E1BF6A: C3                 retq
  L0:
    E1BF6B: BE 04 00 00 00     mov     $0x4,%esi
    E1BF70: E8 AB 47 60 FF     callq   0x420720   ; SYSTEM:TWO-ARG-+
    E1BF75: C9                 leave
    E1BF76: C3                 retq
  ; 39 bytes
  NIL

• Similarly to CLISP, its fasls are readable S-exps and pretty short too. They even start with -*- Mode: Lisp -*-, heh. The actual assembly code looks something like this:

  (COMPILER::GENERATE-CODE-VECTOR
   '((:BYTE 1 85)
     (:BYTES 3 (72 137 229))
     ...
     (:JMP-SHORT 2 (:NZ #$G7248))
     ...
     (:EXIT 2 (201 195))
     (:LABEL 0 (#$G7248))
     (:BYTE 1 190) ...)

• It managed to load ASDF—though not yet compile it—and use that to load and compile a simple system such as split-sequence. Given that (lisp-implementation-version) returns "0.0.0", and comparing to some other lisps that crash so easily with ASDF, I find this very impressive.

Incidentally, this is my first post to Planet Lisp. Hello world! I'm sure I've screwed it up in some way or another. In case you're wondering, the rest of my blog is in Esperanto.

Ĵazbando

En tiu bildo, homo petas al la ĵazband-membroj pisi en la ujon por kontroli ĉu ili uzis drogojn. Tio memorigas min pri unu fojo kiam, post koncerto, spektanto donacis rulaĵon al ni. “Ĵazmuzikistoj kiuj ne volas kanabon?!”, li ŝokite komentis kun siaj amikoj post ni rifuzis.

Cetere, mia kontrabaso estas denove sana! Tio kio malgluiĝis estas gluita denove. Feliĉe, oni ne bezonis malfermi la kontrabason. Tio estus malbona afero kaj plikostigus la riparadon. Mi ĝojas.