Bleh

been sick. Still a little sick.

Bought a new macbook, it’s nice 🙂 Sad that I run into so many issues trying to get gnucash installed via macports on leopard (10.5).

LISP

Since I have nothing cool to say, I’ll just discuss a tidbit that kind of surprised me. Common Lisp is a “LISP-2”, opposed to scheme which is a “LISP-1”. The big issue (as far as I can tell, I’m still a newb) is that the symbols spaces for variables and functions are separated in a LISP2 (Harvard architecture) where lisp1 (and C, and, well, these x86 machines) use a shared memory (‘von Neumann’ or ‘Princeton’ architecture).

Pragmatically, this is a relatively minor but annoying difference in code. Where scheme my have code that looks like “((get-func) val)”, CL will have “(funcall (get-func) val)”. Resolving means wrapping using “(function symbol)” instead of just symbol. There is a shorthand, #’, which wraps the symbol in a function form. So you might have the scheme version “(apply 1 2 3)”, expressed in CL as “(apply (function ) ‘(1 2 3))” or “(apply #’ ‘(1 2 3))” (or perhaps “(funcall #’ 1 2 3)”). C has a sorta kinda almost similar-ish notion with function pointers, the dreaded “int (*func)(int arg)” that I oh so love to abuse 🙂

I imagine during implementation time, this MAY provide a minor speed-up in a rare corner case if your symbol resolution mechanism is pathetically weak, and I imagine some people may imagine that shadowing symbol names with different data attached depending on if you’re talking about methods or data might be a ‘feature’… but I’m not feelin’ it. I hope to come across a text that illuminates the reasoning behind this decision some day. Until then, this is an odd quirk. This is why there is ‘defvar’, ‘defun’ and such, opposed to schemes simple ‘define’. I d’no *shrug* 🙂