1 It's easy

newLISP is easy to download, install, and use. For most operating systems you'll find an installer and/or prebuilt versions. You won't have to build, compile, or make the software, and running it is as easy as typing its name.

It's easy to program in, too. The carefully-designed syntax aims for readability and write-ability, without introducing too many special forms and conventions. Obscure function names have been replaced by more English-like ones, and the temptation to make use of every punctuation mark known to humankind has been resisted, for the most part. Although sadly I don't think we'll ever be able to say goodbye regular expressions. And there are some great introductory tutorials too. (I wrote one of them, so I'm biased!)

'easy' isn't always the main reason for doing anything. Sometimes we do things not because they're easy, but because they are hard. Sometimes we have to use things that aren't easy to use to solve hard problems. But easy can be good when you're learning something new. You probably didn't learn to drive a car in a Ferrari...

2 It's small

It would be hard to find a memory card on sale today with a capacity too small to hold newLISP - if you can find a 512KB memory card you'll have plenty of room to spare.

More seriously: it's a compact language that tries to provide everything you need and dispenses with much that you don't. With about 350 functions, it's a reasonably complete basic programmer's toolkit without the complexity and advanced features of the larger languages. You can worry about making it bigger - or moving to a bigger language - later, when (or if) you outgrow it.

Yes, it hasn't got sub-atomic reference de-clustering, quasi-optimal cyclical redundancy, or meta-stable bytecode traversal, to name just a few of the language's most obvious omissions, but there's plenty of useful tools to get you started. (I made those up, by the way, but that doesn't mean that they don't actually exist...)

3 It's fast

newLISP is quick enough for most purposes, so you shouldn't have too many problems with speed. For extra performance you can learn how to link to compiled C libraries, or write assembly code (two things which I've managed to avoid so far). The 50,000 word introduction I mentioned above is translated in about 0.4 seconds, which is too quick for me - better to take 10 seconds so that I can drink some coffee...

4 It's versatile

Use newLISP to explore programming concepts, crunch numbers, write internet applications, analyze text documents, post rubbish to blogs, or compose music. You can learn many different styles of programming in newLISP: casual scripting (my favourite!), imperative programming, functional programming, object-oriented programming, and even a form of macro programming - you'll be working with newLISP for a long time before you've exhausted newLISP's potential and are ready to move on to bigger and more complex languages (if you want to). Instead of just following what other people tell you is the 'right' way, why not try the different styles and make your own mind up?

You don't have to be a computer scientist to use newLISP: musician, writer, artist, sysadmin, architect, web developer, surveyor, mathematician, tinker, tailor, soldier, sailor - if your work involves the computer, it could benefit if that computer works harder for you.

This is the sort of newLISP I use all the time:

(set 'dir (real-path))
(dolist (i (directory dir {^[^.]}))
 (set 'item (string dir "/" i))
 (set 'mod-date (date (file-info item 6) 0 "%Y%m%d-%H%M%S"))
 (rename-file item (string dir "/" mod-date i)))

which simply renames files based on their modification dates. But others are into newLISP like this:

 (let ((g (lambda (h) 
          (expand (lambda (n) 
            (let ((f (lambda (f n) 
                    (if (< n 2) 1 (* n (f (- n 1))))))) 
            (f (h h) n))) 'h))))
       ((g g) 10)) 

which is something to do with the Y function.

5 It's different

newLISP is certainly not your Dad's Lisp, and there's plenty of tutting in some of the online communities who get easily worked up by the different. But perhaps you're ready to find out for yourself what you think is good or bad, and perhaps you like to avoid doing the obvious and predictable. Or at least prove to your own satisfaction that your Dad was right all along.

6 It's friendly

On the newLISP forum, genuine questions usually receive genuine answers. You probably won't encounter the uncompromising attitudes that newcomers to other languages occasionally encounter. You might even get help from Lutz, the language's author.

7 It's not finished

newLISP is still developing. There's room for contributions from you: plenty of investigations and discoveries still to be made, plenty of code and applications still to be written, and many subjects for writing and blogging about. If you want to take an active part in its development, there are plenty of oportunities waiting for you. You might even get your own function included in the next release (but it will have to be a really good idea!). It won't be named after you, though.

8 It's fun

Is programming fun? It's not always fun; sometimes the code doesn't do what you thought you told it to do. But newLISP has got to be fun, because the slogan says it is!

9 It's free

Of course, sometimes the best things in life are free!

(if (unless nil nil true) (exit))

See if you can get your comment through the impassable barrier that is the newLISP Bayesian Comment Spam Killer below! (No, it won't kill Bayesian comemnts - although it might - but it tries to kill spam comments using Bayesian analysis.)

Naturally, though, I also use a small newLISP utility alongside these two: its purpose is to look only in places where there are newLISP-related files. I reworked this recently based on some suggestions in the newLISP forum. Here's the code:

#!/usr/bin/env newlisp
(context 'Look4)

(constant 'extensions '("lsp" "txt" "html")) 

(set 'places 
  (list (string (env "HOME") "/projects/lisp")
        (string (env "HOME") "/projects/webapps")
        (string (env "HOME") "/projects/guiapps")
        (string (env "HOME") "/projects/tech-writing")
        "/usr/share/newlisp"))

(define (string-ends-with L str) 
  (exists (fn (x) (ends-with str x)) L))

(define (look-in-file pn)
 (let (contents "" res '())
  (when (string-ends-with extensions pn)
     (set 'file (open pn "r"))
     (while (search file (string "(.*?" Term ".{10,20})") true 1)
        (push $1 res -1))
     (close file)
     (if res (list pn res)))))

(define (Look4:Look4 dir)
   (dolist (nde (directory dir "^[A-z]"))
     (set 'item (append dir "/" nde))
     (if (directory? item)
       (Look4 item)
       (when (set 'r (look-in-file item Term)) (inc 'counter) (push r results)))))

(when (>= (length (main-args)) 2) 
  (set 'Term (main-args 2) 'counter 0)
  (map Look4 places)
  (when results
    (sort results)
    (dolist (r results)
        (println "\n" (r 0) "\n\t\t\t")
        (dolist (e (r 1)) (println "\t" e)))
        (println "Found " counter " occurrences of \"" Term "\"")))

(exit)

You can see that I've hardwired the names of the directories to search in. That's not very flexible, but it may suit your working style.

On the command line, you run the script and supply a string:

$ look4 unless

and you'll see the results in a couple of seconds:

...
/Users/me/projects/lisp/tokenizer.lsp

    (unless txt (exit))

/usr/share/newlisp/guiserver.lsp

;; a Piano instrument unless the function 'gs:mi

/usr/share/newlisp/modules/smtp.lsp

      (unless (and (empty?  user-

/usr/share/newlisp/util/nanorc

color blue "([[:space:]()]|^)(trim|true|true\?|unicode|unify|unique|unless|unpack|until|upper-
...

Found 201 occurrences of "unless"
$ 

Since the search is a regular expression one, it might be possible to supply a regex-friendly string, if you escape all the regex characters, but I find that I rarely use regular expressions in this type of search. I'm more likely to be asking "Didn't I once write a binary function?".

• ۞
• ⱁ
• ᚅ
• Ꮈ
• Ϣ
• ܍

You'll also find the I Ching, Braille, alchemy, an alphabet funded by George Bernard Shaw, neo-pagan tree language, astrology, dentists, talking leaves, and much more besides.

Most of the technical aspects of Unicode escape me (supplementary planes, normalization, high surrogates, collation?) but it's useful to know the basics of using Unicode in newLISP, particularly now that it's the most popular encoding used on the internet.

newLISP is UTF-8 friendly by default on MacOS X, and UTF-8 versions are available for other platforms too (although I'm not sure whether the default versions are UTF-8). UTF-8 is a variable-length character encoding, which allows characters to use 1, 2, 3 or 4 bytes depending on their Unicode value.

One essential newLISP function for exploring the Unicode character set is char. This takes either a number or a character, and returns the matching character or number:

(char 63498)
""

(char "")
63498

Unicode characters are usually described using hexadecimal, so it's useful to know how to translate between hex and decimal. To convert a decimal integer to a hex string, use format:

(format "%llx" 63498)
"f80a"

To convert a hex string to a decimal integer, pass a hexadecimal string starting with "0x" to int :

(int (string "0x" "f80a"))
63498

When you're writing text, it would be good if you could easily insert these characters as you type. There are useful system tools for doing this (on MacOS X, there's the Character Palette), but for fun I've added the following two functions to the Markdown converter that I use to process my writing:

(define (hex-str-to-unicode-char strng)
   (char (int (string "0x" (1 strng)) 0 16)))

(define (ustring s)
  (replace "U[0-9a-f]{4,}" s (hex-str-to-unicode-char $0) 1))

So now I can type "U" followed by 4 hexadecimal characters, and the appropriate Unicode character is inserted automatically: "U f80a" is converted to "". (I had to insert a space after the U to prevent translation.)

You can happily use Unicode characters anywhere in newLISP code, if your text editor or console is up to the job. And if ustring is available, you can generate them easily too:

(constant (sym (ustring "U 2660")) 4  ; spades
       (sym (ustring "U 2661"))      3  ; hearts
       (sym (ustring "U 2662"))      2  ; diamonds
       (sym (ustring "U 2663"))      1  ; clubs
     )

(symbols)

(! != $ $0 $1 $10 $11 $12 $13 $14 $15 $2 $3 $4 $5 $6 $7 $8 $9 $HOME $args $idx $main-args ...  zero? | ~ ♠ ♡ ♢ ♣)

(println "(> ♢ ♣)? " (> ♢ ♣))
(> ♢ ♣)? true

(println "(> ♡ ♠)? " (> ♡ ♠))
(> ♡ ♠)? nil

Using descriptive Unicode characters for your symbol names could introduce a whole new level of readability to your code!

(constant (global '☼)  MAIN)
(context '☺)

(define (☻ ✄ ☁ ⍾)
   (print ✄ ☁ ⍾))

(define (‽) 
   (println {‽}))

(context ☼)
(set '℥ "what "  'ᴥ "the " 'ᴒ "dickens")
(☺:☻ ℥ ᴥ ᴒ)
(☺:‽)

Appropriately enough, that last function call returns "‽", which is the much-needed interrobang character.

The problem now is to remember all those four digit hexadecimal numbers that identify the Unicode characters. I whipped up a quick Unicode browser in newLISP:

This just shows a page of Unicode characters at a time, and lets you move up and down through the 'pages'. It has some problems when the character code exceeds FFFF - I don't know why‽

This post should display correctly on most modern browsers. If you see lots of boxes rather than characters, then you are using a browser or system that doesn't handle Unicode well. This applies to the iPhone and iPod Touch as well: it appears that Mobile Safari doesn't like Unicode as much as its desktop version. Apple - improve Unicode support please!

So far I've found it fairly useful, and it's meant that I haven't had to write my own blog search tool yet. However, it's been doing odd things with the HTML display of the page, generating thousands of Javascript errors and doing weird stuff like (apparently) loading the page more than once. Also, it fails to find things that I think it should, so I'm not convinced it's as good as Google engineers apparently think it is.

If anyone is at all knowledgeable about what the custom Google search engine is doing with its HTML, please help! The Google engineers can't be bothered to help anyone use their work it seems, so I'm on my own. Perhaps I'll have to write my own search engine after all...!

You can also read about how it's done, too, here.

Thanks, Seth, and good luck with the PMC challenge!

I was a bit surprised that, after installing the plugin, it took only 25 minutes for the first spammers to arrive and leave their tell-tale pharmacological trail. Google doesn't bother much with this site, but apparently spammers can immediately find any web page with a comments form - presumably they're searching the internet for anything with the word "comments" in? Perhaps I should have called it something different.

As it turned out, it wasn't too bad, because it gave me the chance to test some IP-blacklisting code I put together. This may or may not work, but I needed a bit of genuine spam to test against. I don't need any more, though. :)

I'm trying out a JavaScript utility called WMD. This lets you format your comments in Markdown and see what the results look like before they're submitted. Although there's a development version of Markdown written in newLISP here, I couldn't use this to generate a live preview in a web page - JavaScript still rules the browser.

The phone rings. GEORGE answers.

STEVE: (VOICEOVER) Hey, George, it's Steve. Any progress on the title? Gonna have to move forward on this real quick now.

GEORGE: Nothing yet, Steve. Still working through some suggestions. I got the final draft of the titlemaker code, just running it now.

STEVE: Uh huh, OK. What did you feed into it this time?

GEORGE: Those key words we talked about last week. Changed a few.

STEVE: Right. So, did we get any promising ideas?

GEORGE: Um ... let me see. Bit of problem with memory allocation. Ah yes. How about: "Indiana Jones and the Lost Kingdom of the Crystal Grail."

STEVE: I dunno. Sounds a bit ... er ... country and western.

GEORGE: Know what you mean. So what about "Indiana Jones and the Holy Crystal of the Doom Raiders". OK, don't answer... Try "Indiana Jones and the Doom Skull of the Lost Kingdom"? No? "Indiana Jones and the Lost Legend of the Holy Kingdom"?

STEVE: Yeah, yeah, it's not ... these are just not working for me. Although I like the first four words. They're, you know, strong. Are you sure that code's good, George?

GEORGE: Yup, got it from Hanson, out East. He's usually our number one guy for this kind of thing. Looks OK to me, I think we got the latest version...

Cut to computer screen, which shows the following programming code.

(define (mappend) (apply append (apply map (args))))

(define (remove1 elt lst) 
  (let ((elt-pos (find elt lst))) 
    (if elt-pos (pop lst elt-pos)) 
    lst)) 

(define (k-permutations k multiset) 
  (let ((pivots (unique multiset))) 
    (if (= k 1) 
        (map list pivots) 
        (mappend (lambda (p) 
                 (map (lambda (k-1-perm) (cons p k-1-perm)) 
                      (k-permutations (- k 1) (remove1 p multiset)))) 
               pivots)))) 

(set 'keywords 
  '("Lost" "Skull" "Kingdom" "Raiders" "Ark" "Grail" "Doom" "Legend" "Holy" "Crystal" "Kingdom"))

(map (fn (title) 
   (println  "Indiana Jones and the " 
     (title 0) " " 
     (title 1) " of the " 
     (title 2) " " 
     (title 3))) 
   (k-permutations (length keywords) keywords))

STEVE: Hmm, well it sure isn't doing the business for us yet. Run it some more - we'll just have to keep at it until something good turns up.

GEORGE: OK, Steve. What about "Indiana Jones and the Lost Skull of the Legend Kingdom"?

STEVE: Nah.

GEORGE: Uh, "Indiana Jones and the Grail Ark of the Holy Skull"?

STEVE: Holy skull? Christ, George, I think even Crystal Gayle's better than that.

FADE.

Cheers Rick!

(code)

• list
• list
• list

I wrote the first implementation of a LISP interpreter on the IBM 704 at MIT in early in 1959.

The 704 family (704, 709, 7090) had "Address" and "Decrement" fields that were 15 bits long in some of the looping instructions. There were also special load and store instructions that moved these 15-bit addresses between memory and the index regiseters ( 3 on the 704, 7 on the others )

We had devised a representation for list structure that took advantage of these instructions.

Because of an unfortunate temporary lapse of inspiration, we couldn't think of any other names for the 2 pointers in a list node than "address" and "decrement", so we called the functions CAR for "Contents of Address of Register" and CDR for "Contents of Decrement of Register".

After several months and giving a few classes in LISP, we realized that "first" and "rest" were better names, and we (John McCarthy, I and some of the rest of the AI Project) tried to get people to use them instead.

Alas, it was too late! We couldn't make it stick at all. So we have CAR and CDR.

Like Steve, I much prefer first and rest to car and cdr. This approach is evident throughout newLISP, which usually leans towards a user-friendly and abbreviation-free approach to function naming.

But, although car and cdr have been uninspired for nearly 50 years, they have survived because they offer an extra geeky ability: you can add more a and d letters between the "c" and "r", to produce functions with even weirder names. So caddr finds the car of the cdr of the cdr; you read from left to right, although the functions are applied from right to left as usual.

To be honest, I don't know how I've managed to write any code at all in newLISP without having this readable and user-friendly syntax at my fingertips. So it's time for newLISP to be 'cdadderized':

(define (car x) (first x))
(define (cdr x) (rest x))

(define (cdadderize x) 
  (inc 'x)
  (set 'results '())
  (until (= x 0)
     (push   (% x 2) results)
     (set 'x (/ x 2)))
  (set 'results (rest results) 'f-name results)
  (map (fn (a b) (replace a results b)) '(0 1) '("(car " "(cdr "))
  (push (string "x"  (dup ")" (length results))) results -1)
  (set 'results (join results))
  (map (fn (a b) (replace a f-name b)) '(0 1) '("a" "d"))
  (letex ((fnm   (sym (string "c" (join f-name) "r")))
          (body results))
    (define (fnm x) (eval-string body))
    fnm))

(for (i 3 1022) (cdadderize i)) ; we did 1 and 2 :)

Not the prettiest code, but let's run it and look at the new functions that have been defined:

(filter (fn (s) 
    (and (starts-with  (name s) "ca|cd" 0) 
         (ends-with (name s) "r"))) 
    (symbols))
;->
(caaaaaaaaaar caaaaaaaaadr caaaaaaaaar caaaaaaaadr caaaaaaaar caaaaaaadar caaaaaaaddr 
caaaaaaadr caaaaaaar caaaaaadaar caaaaaadadr caaaaaadar caaaaaaddar caaaaaadddr 
caaaaaaddr caaaaaadr caaaaaar caaaaadaaar caaaaadaadr caaaaadaar caaaaadadar caaaaadaddr 
caaaaadadr caaaaadar caaaaaddaar caaaaaddadr caaaaaddar caaaaadddar caaaaaddddr 
caaaaadddr caaaaaddr caaaaadr caaaaar caaaadaaaar caaaadaaadr caaaadaaar caaaadaadar 
caaaadaaddr caaaadaadr caaaadaar caaaadadaar caaaadadadr caaaadadar caaaadaddar 
caaaadadddr caaaadaddr caaaadadr caaaadar caaaaddaaar caaaaddaadr caaaaddaar caaaaddadar 
caaaaddaddr caaaaddadr caaaaddar caaaadddaar caaaadddadr caaaadddar caaaaddddar 
caaaadddddr caaaaddddr caaaadddr caaaaddr caaaadr caaaar caaadaaaaar caaadaaaadr 
caaadaaaar caaadaaadar caaadaaaddr caaadaaadr caaadaaar caaadaadaar caaadaadadr 
caaadaadar caaadaaddar caaadaadddr caaadaaddr caaadaadr caaadaar caaadadaaar caaadadaadr 
caaadadaar caaadadadar caaadadaddr caaadadadr caaadadar caaadaddaar caaadaddadr 
caaadaddar caaadadddar caaadaddddr caaadadddr caaadaddr caaadadr caaadar caaaddaaaar 
caaaddaaadr caaaddaaar caaaddaadar caaaddaaddr caaaddaadr caaaddaar caaaddadaar 
caaaddadadr caaaddadar caaaddaddar caaaddadddr caaaddaddr caaaddadr caaaddar caaadddaaar 
caaadddaadr caaadddaar caaadddadar caaadddaddr caaadddadr caaadddar caaaddddaar 
caaaddddadr caaaddddar caaadddddar caaaddddddr caaadddddr caaaddddr caaadddr caaaddr 
caaadr caaar caadaaaaaar caadaaaaadr caadaaaaar caadaaaadar caadaaaaddr caadaaaadr 
caadaaaar caadaaadaar caadaaadadr caadaaadar caadaaaddar caadaaadddr caadaaaddr 
caadaaadr caadaaar caadaadaaar caadaadaadr caadaadaar caadaadadar caadaadaddr caadaadadr 
caadaadar caadaaddaar caadaaddadr caadaaddar caadaadddar caadaaddddr caadaadddr 
caadaaddr caadaadr caadaar caadadaaaar caadadaaadr caadadaaar caadadaadar caadadaaddr 
caadadaadr caadadaar caadadadaar caadadadadr caadadadar caadadaddar caadadadddr 
caadadaddr caadadadr caadadar caadaddaaar caadaddaadr caadaddaar caadaddadar caadaddaddr 
caadaddadr caadaddar caadadddaar caadadddadr caadadddar caadaddddar caadadddddr 
caadaddddr caadadddr caadaddr caadadr caadar caaddaaaaar caaddaaaadr caaddaaaar 
caaddaaadar caaddaaaddr caaddaaadr caaddaaar caaddaadaar caaddaadadr caaddaadar 
caaddaaddar caaddaadddr caaddaaddr caaddaadr caaddaar caaddadaaar caaddadaadr caaddadaar 
caaddadadar caaddadaddr caaddadadr caaddadar caaddaddaar caaddaddadr caaddaddar 
caaddadddar caaddaddddr caaddadddr caaddaddr caaddadr caaddar caadddaaaar caadddaaadr 
caadddaaar caadddaadar caadddaaddr caadddaadr caadddaar caadddadaar caadddadadr 
caadddadar caadddaddar caadddadddr caadddaddr caadddadr caadddar caaddddaaar caaddddaadr 
caaddddaar caaddddadar caaddddaddr caaddddadr caaddddar caadddddaar caadddddadr 
caadddddar caaddddddar caadddddddr caaddddddr caadddddr caaddddr caadddr caaddr 
caadr caar cadaaaaaaar cadaaaaaadr cadaaaaaar cadaaaaadar cadaaaaaddr cadaaaaadr 
cadaaaaar cadaaaadaar cadaaaadadr cadaaaadar cadaaaaddar cadaaaadddr cadaaaaddr 
cadaaaadr cadaaaar cadaaadaaar cadaaadaadr cadaaadaar cadaaadadar cadaaadaddr cadaaadadr 
cadaaadar cadaaaddaar cadaaaddadr cadaaaddar cadaaadddar cadaaaddddr cadaaadddr 
cadaaaddr cadaaadr cadaaar cadaadaaaar cadaadaaadr cadaadaaar cadaadaadar cadaadaaddr 
cadaadaadr cadaadaar cadaadadaar cadaadadadr cadaadadar cadaadaddar cadaadadddr 
cadaadaddr cadaadadr cadaadar cadaaddaaar cadaaddaadr cadaaddaar cadaaddadar cadaaddaddr 
cadaaddadr cadaaddar cadaadddaar cadaadddadr cadaadddar cadaaddddar cadaadddddr 
cadaaddddr cadaadddr cadaaddr cadaadr cadaar cadadaaaaar cadadaaaadr cadadaaaar 
cadadaaadar cadadaaaddr cadadaaadr cadadaaar cadadaadaar cadadaadadr cadadaadar 
cadadaaddar cadadaadddr cadadaaddr cadadaadr cadadaar cadadadaaar cadadadaadr cadadadaar 
cadadadadar cadadadaddr cadadadadr cadadadar cadadaddaar cadadaddadr cadadaddar 
cadadadddar cadadaddddr cadadadddr cadadaddr cadadadr cadadar cadaddaaaar cadaddaaadr 
cadaddaaar cadaddaadar cadaddaaddr cadaddaadr cadaddaar cadaddadaar cadaddadadr 
cadaddadar cadaddaddar cadaddadddr cadaddaddr cadaddadr cadaddar cadadddaaar cadadddaadr 
cadadddaar cadadddadar cadadddaddr cadadddadr cadadddar cadaddddaar cadaddddadr 
cadaddddar cadadddddar cadaddddddr cadadddddr cadaddddr cadadddr cadaddr cadadr 
cadar caddaaaaaar caddaaaaadr caddaaaaar caddaaaadar caddaaaaddr caddaaaadr caddaaaar 
caddaaadaar caddaaadadr caddaaadar caddaaaddar caddaaadddr caddaaaddr caddaaadr 
caddaaar caddaadaaar caddaadaadr caddaadaar caddaadadar caddaadaddr caddaadadr caddaadar 
caddaaddaar caddaaddadr caddaaddar caddaadddar caddaaddddr caddaadddr caddaaddr 
caddaadr caddaar caddadaaaar caddadaaadr caddadaaar caddadaadar caddadaaddr caddadaadr 
caddadaar caddadadaar caddadadadr caddadadar caddadaddar caddadadddr caddadaddr 
caddadadr caddadar caddaddaaar caddaddaadr caddaddaar caddaddadar caddaddaddr caddaddadr 
caddaddar caddadddaar caddadddadr caddadddar caddaddddar caddadddddr caddaddddr 
caddadddr caddaddr caddadr caddar cadddaaaaar cadddaaaadr cadddaaaar cadddaaadar 
cadddaaaddr cadddaaadr cadddaaar cadddaadaar cadddaadadr cadddaadar cadddaaddar 
cadddaadddr cadddaaddr cadddaadr cadddaar cadddadaaar cadddadaadr cadddadaar cadddadadar 
cadddadaddr cadddadadr cadddadar cadddaddaar cadddaddadr cadddaddar cadddadddar 
cadddaddddr cadddadddr cadddaddr cadddadr cadddar caddddaaaar caddddaaadr caddddaaar 
caddddaadar caddddaaddr caddddaadr caddddaar caddddadaar caddddadadr caddddadar 
caddddaddar caddddadddr caddddaddr caddddadr caddddar cadddddaaar cadddddaadr cadddddaar 
cadddddadar cadddddaddr cadddddadr cadddddar caddddddaar caddddddadr caddddddar 
cadddddddar cadddddddddr caddddddddr cadddddddr caddddddr cadddddr caddddr cadddr 
caddr cadr car cdaaaaaaaar cdaaaaaaadr cdaaaaaaar cdaaaaaadar cdaaaaaaddr cdaaaaaadr 
cdaaaaaar cdaaaaadaar cdaaaaadadr cdaaaaadar cdaaaaaddar cdaaaaadddr cdaaaaaddr 
cdaaaaadr cdaaaaar cdaaaadaaar cdaaaadaadr cdaaaadaar cdaaaadadar cdaaaadaddr cdaaaadadr 
cdaaaadar cdaaaaddaar cdaaaaddadr cdaaaaddar cdaaaadddar cdaaaaddddr cdaaaadddr 
cdaaaaddr cdaaaadr cdaaaar cdaaadaaaar cdaaadaaadr cdaaadaaar cdaaadaadar cdaaadaaddr 
cdaaadaadr cdaaadaar cdaaadadaar cdaaadadadr cdaaadadar cdaaadaddar cdaaadadddr 
cdaaadaddr cdaaadadr cdaaadar cdaaaddaaar cdaaaddaadr cdaaaddaar cdaaaddadar cdaaaddaddr 
cdaaaddadr cdaaaddar cdaaadddaar cdaaadddadr cdaaadddar cdaaaddddar cdaaadddddr 
cdaaaddddr cdaaadddr cdaaaddr cdaaadr cdaaar cdaadaaaaar cdaadaaaadr cdaadaaaar 
cdaadaaadar cdaadaaaddr cdaadaaadr cdaadaaar cdaadaadaar cdaadaadadr cdaadaadar 
cdaadaaddar cdaadaadddr cdaadaaddr cdaadaadr cdaadaar cdaadadaaar cdaadadaadr cdaadadaar 
cdaadadadar cdaadadaddr cdaadadadr cdaadadar cdaadaddaar cdaadaddadr cdaadaddar 
cdaadadddar cdaadaddddr cdaadadddr cdaadaddr cdaadadr cdaadar cdaaddaaaar cdaaddaaadr 
cdaaddaaar cdaaddaadar cdaaddaaddr cdaaddaadr cdaaddaar cdaaddadaar cdaaddadadr 
cdaaddadar cdaaddaddar cdaaddadddr cdaaddaddr cdaaddadr cdaaddar cdaadddaaar cdaadddaadr 
cdaadddaar cdaadddadar cdaadddaddr cdaadddadr cdaadddar cdaaddddaar cdaaddddadr 
cdaaddddar cdaadddddar cdaaddddddr cdaadddddr cdaaddddr cdaadddr cdaaddr cdaadr 
cdaar cdadaaaaaar cdadaaaaadr cdadaaaaar cdadaaaadar cdadaaaaddr cdadaaaadr cdadaaaar 
cdadaaadaar cdadaaadadr cdadaaadar cdadaaaddar cdadaaadddr cdadaaaddr cdadaaadr 
cdadaaar cdadaadaaar cdadaadaadr cdadaadaar cdadaadadar cdadaadaddr cdadaadadr cdadaadar 
cdadaaddaar cdadaaddadr cdadaaddar cdadaadddar cdadaaddddr cdadaadddr cdadaaddr 
cdadaadr cdadaar cdadadaaaar cdadadaaadr cdadadaaar cdadadaadar cdadadaaddr cdadadaadr 
cdadadaar cdadadadaar cdadadadadr cdadadadar cdadadaddar cdadadadddr cdadadaddr 
cdadadadr cdadadar cdadaddaaar cdadaddaadr cdadaddaar cdadaddadar cdadaddaddr cdadaddadr 
cdadaddar cdadadddaar cdadadddadr cdadadddar cdadaddddar cdadadddddr cdadaddddr 
cdadadddr cdadaddr cdadadr cdadar cdaddaaaaar cdaddaaaadr cdaddaaaar cdaddaaadar 
cdaddaaaddr cdaddaaadr cdaddaaar cdaddaadaar cdaddaadadr cdaddaadar cdaddaaddar 
cdaddaadddr cdaddaaddr cdaddaadr cdaddaar cdaddadaaar cdaddadaadr cdaddadaar cdaddadadar 
cdaddadaddr cdaddadadr cdaddadar cdaddaddaar cdaddaddadr cdaddaddar cdaddadddar 
cdaddaddddr cdaddadddr cdaddaddr cdaddadr cdaddar cdadddaaaar cdadddaaadr cdadddaaar 
cdadddaadar cdadddaaddr cdadddaadr cdadddaar cdadddadaar cdadddadadr cdadddadar 
cdadddaddar cdadddadddr cdadddaddr cdadddadr cdadddar cdaddddaaar cdaddddaadr cdaddddaar 
cdaddddadar cdaddddaddr cdaddddadr cdaddddar cdadddddaar cdadddddadr cdadddddar 
cdaddddddar cdadddddddr cdaddddddr cdadddddr cdaddddr cdadddr cdaddr cdaderizer 
cdadr cdar cddaaaaaaar cddaaaaaadr cddaaaaaar cddaaaaadar cddaaaaaddr cddaaaaadr 
cddaaaaar cddaaaadaar cddaaaadadr cddaaaadar cddaaaaddar cddaaaadddr cddaaaaddr 
cddaaaadr cddaaaar cddaaadaaar cddaaadaadr cddaaadaar cddaaadadar cddaaadaddr cddaaadadr 
cddaaadar cddaaaddaar cddaaaddadr cddaaaddar cddaaadddar cddaaaddddr cddaaadddr 
cddaaaddr cddaaadr cddaaar cddaadaaaar cddaadaaadr cddaadaaar cddaadaadar cddaadaaddr 
cddaadaadr cddaadaar cddaadadaar cddaadadadr cddaadadar cddaadaddar cddaadadddr 
cddaadaddr cddaadadr cddaadar cddaaddaaar cddaaddaadr cddaaddaar cddaaddadar cddaaddaddr 
cddaaddadr cddaaddar cddaadddaar cddaadddadr cddaadddar cddaaddddar cddaadddddr 
cddaaddddr cddaadddr cddaaddr cddaadr cddaar cddadaaaaar cddadaaaadr cddadaaaar 
cddadaaadar cddadaaaddr cddadaaadr cddadaaar cddadaadaar cddadaadadr cddadaadar 
cddadaaddar cddadaadddr cddadaaddr cddadaadr cddadaar cddadadaaar cddadadaadr cddadadaar 
cddadadadar cddadadaddr cddadadadr cddadadar cddadaddaar cddadaddadr cddadaddar 
cddadadddar cddadaddddr cddadadddr cddadaddr cddadadr cddadar cddaddaaaar cddaddaaadr 
cddaddaaar cddaddaadar cddaddaaddr cddaddaadr cddaddaar cddaddadaar cddaddadadr 
cddaddadar cddaddaddar cddaddadddr cddaddaddr cddaddadr cddaddar cddadddaaar cddadddaadr 
cddadddaar cddadddadar cddadddaddr cddadddadr cddadddar cddaddddaar cddaddddadr 
cddaddddar cddadddddar cddaddddddr cddadddddr cddaddddr cddadddr cddaddr cddadr 
cddar cdddaaaaaar cdddaaaaadr cdddaaaaar cdddaaaadar cdddaaaaddr cdddaaaadr cdddaaaar 
cdddaaadaar cdddaaadadr cdddaaadar cdddaaaddar cdddaaadddr cdddaaaddr cdddaaadr 
cdddaaar cdddaadaaar cdddaadaadr cdddaadaar cdddaadadar cdddaadaddr cdddaadadr cdddaadar 
cdddaaddaar cdddaaddadr cdddaaddar cdddaadddar cdddaaddddr cdddaadddr cdddaaddr 
cdddaadr cdddaar cdddadaaaar cdddadaaadr cdddadaaar cdddadaadar cdddadaaddr cdddadaadr 
cdddadaar cdddadadaar cdddadadadr cdddadadar cdddadaddar cdddadadddr cdddadaddr 
cdddadadr cdddadar cdddaddaaar cdddaddaadr cdddaddaar cdddaddadar cdddaddaddr cdddaddadr 
cdddaddar cdddadddaar cdddadddadr cdddadddar cdddaddddar cdddadddddr cdddaddddr 
cdddadddr cdddaddr cdddadr cdddar cddddaaaaar cddddaaaadr cddddaaaar cddddaaadar 
cddddaaaddr cddddaaadr cddddaaar cddddaadaar cddddaadadr cddddaadar cddddaaddar 
cddddaadddr cddddaaddr cddddaadr cddddaar cddddadaaar cddddadaadr cddddadaar cddddadadar 
cddddadaddr cddddadadr cddddadar cddddaddaar cddddaddadr cddddaddar cddddadddar 
cddddaddddr cddddadddr cddddaddr cddddadr cddddar cdddddaaaar cdddddaaadr cdddddaaar 
cdddddaadar cdddddaaddr cdddddaadr cdddddaar cdddddadaar cdddddadadr cdddddadar 
cdddddaddar cdddddadddr cdddddaddr cdddddadr cdddddar cddddddaaar cddddddaadr cddddddaar 
cddddddadar cddddddaddr cddddddadr cddddddar cdddddddaar cdddddddadr cdddddddar 
cddddddddar cdddddddddr cddddddddr cdddddddr cddddddr cdddddr cddddr cdddr cddr 
cdr)

Some useful tools there - surely some of these functions would be proud to appear in any Common Lisp program? How about the stretch-limo caaaaaaaaar, for one ("My god, it's full of cars")? Then there's cadadar - north of the USA, if you have a cold. A few are useful in other ways, too: cdddddddddr provides excellent tonguing practice for woodwind players, especially the bassoonists among you.

By the way, for compatibility with Common Lisp, it's not necessary to go all the way up 1022. Call (cdadderize 14) to give you:

(caaar caadr caar cadar caddr cadr car cdaar cdadr cdar cddar cdddr cddr cdr)

whereas 30 gives you everything up to cddddr.

To be honest, I can't see myself using these very much. Well, OK: I will never use these. But I like the idea that the ever-adaptable Lisp was once written for vacuum-tubes and can still run like the wind on my iMac.

It gives a reasonable impression of what the problems are. Unless your eyesight is good (mine isn't), and the lighting conditions are good (they often aren't), it's hard to read the three lines of text at the top - artist, title, and album. Two of these lines are drawn in grey on a black background. A lower-case 'a' in the chosen font measures just over 1 millimetre, or about 3 points. The large area in the middle of the display can show you the album artwork, but if there's no artwork you see two big quavers on a light grey background. What really needs to be provided is a customizable display, where you can specify what information is shown, and how it's presented. It would be nice if you could ask for a display that contains the main information in a larger font, and easier to read graphics.

But, I hear you say, what's all this got to do with newLISP?

You know the answer.

I couldn't resist trying to persuade iTunes to create substitute album artwork that shows the music's details in larger type as album art when it's downloaded to the iPod... I can use newLISP for most of the work. But, unfortunately, the easiest way to talk to iTunes on MacOS X is by using AppleScript, that quirky and devious language whose syntax was once described as "similar to English spelling - not thoroughly thought through".

So let's get the AppleScript stuff over first. Here's a good place to start: get the current selection from iTunes. The necessary AppleScript can be wrapped up in a newLISP function call:

(define (itunes-get-selection)
    (let ((result (exec 
             (format [text]osascript -s s -e 'tell application "iTunes" to get selection'[/text]))))
         (set 'result (replace "{|}" (first result) "" 0))
         (parse result ", ")))

iTunes returns the information in an AppleScript list, which is easily changed into a newLISP list. Notice that extra '-s s' option flag in the osascript command. That appears to be significant. The result is a list of wordy track references (WTRs):

("file track id 15639 of user playlist id 13999 of source id 41 of application \"iTunes\"" 
 "file track id 15299 of user playlist id 13999 of source id 41 of application \"iTunes\"")

Given a WTR, it's possible to ask iTunes for more information about a track. As usual, I use the Unlikely Delimiter Ploy (UDP) when obtaining information from iTunes, mainly because iTunes track names can contain virtually any character. I've not yet seen four tildes used before, though, so I'm sticking with them for now:

(define (itunes-get-details-of-track file-track-id)
  (let ((result (exec 
            (format [text]osascript -s s -e 'tell application "iTunes"
              tell %s 
                set d to (name & "~~~~" & artist & "~~~~" & album & "~~~~" & duration & "~~~~" & year & "~~~~" & genre) as text
               end tell
             end tell '[/text] file-track-id))))
      (when result           
         (set 'result 
             (transpose 
                (list '(track-name artist album duration year genre) 
                (parse (trim (first result) {"} {"}) "~~~~"))))
          result)))

That's such an ugly function! But it works:

((track-name "Maiden Voyage") 
 (artist "Herbie Hancock") 
 (album "An Evening With Herbie Hancock and Chick Corea - In Concert CD2") 
 (duration "810.840026855469") 
 (year "1978") 
 (genre "jazz"))

There's just one more piece of AppleScript required, to change the album artwork. Apple could have made this nice and easy:

set artwork of track to "some-artwork.jpg" -- this doesn't work :)

but they didn't. The required newLISP-wrapped code is this:

(define (itunes-set-data-of-artwork file-track-id)
   (exec (format [text]osascript -s s -e 'tell application "iTunes"
      delete every artwork of %s
      set the_artwork to read file (((path to desktop) as text) & "artwork-canvas.pict") from 513 as picture
      set data of artwork 1 of %s to the_artwork
    end tell'[/text] file-track-id file-track-id )))

This looks for a graphic in PICT format at ~/Desktop/artwork-canvas.pict, strips the 512 byte header, loads the picture data, and applies the result to the track as album artwork.

I can't persuade newLISP-GS to produce PICT files, but luckily the Mac comes with the sips image processing tool, so converting PNG to PICT is easy.

(define (convert-to-pict file-name)
    (let ((new-file-name (replace {(.*)(\.)(.*$)} (string file-name) (string $1 ".pict") 1)))
          (exec (format "sips -s format pict '%s' --out '%s'"  file-name new-file-name))))

So now I can take off my AppleScripter's hat and switch to newLISP. To produce the graphics, I use a newLISP-GS canvas, after first setting up the graphics system:

(load (append (env "NEWLISPDIR") "/guiserver.lsp"))
(gs:init)
(gs:window 'Artwork 200 200 320 320)  
(gs:canvas 'ArtworkCanvas)
(gs:set-size 'ArtworkCanvas  320 320)
(gs:add-to 'Artwork 'ArtworkCanvas )
(gs:set-background 'ArtworkCanvas gs:gray)
(gs:set-visible 'Artwork true)

and then use commands such as set-font and draw-text to draw some more informative artwork. The main loop is simple enough, in theory at least:

(dolist (track (itunes-get-selection))
  (set 'data (itunes-get-details-of-track track))

  ; start drawing
  (gs:draw-text 'AlbumText (string (lookup 'artist data)) ...

  ; repeat for other information

  ; then:
  (gs:update)  

  (set 'temp-file (string "/Users/me/Desktop/" {artwork-canvas.png}))
  (gs:export temp-file)
  (convert-to-pict temp-file)
  (itunes-set-data-of-artwork track)

  ; delete all text
  (gs:delete-tag 'AlbumText)

  ; and start on the next one
  )

In practice there are various issues to address, such as timing - all these external processes appear to hamper a smoothly flowing script - so some sleep commands have to be added. Also, you might want to waste, I mean, spend more time adjusting the formatting and typography. I like adjusting the point size so that the line of type fits perfectly, and changing the colours to suit the genre. But that's another story!

There are basically three tasks to do: do the basic game mechanics, implement a user interface, and add a dash or two of intelligent strategy.

The game mechanics are simple enough. You need a board:

(set '*grid* (dup nil 9))

and a list of winning positions:

(set '*winning-positions* 
   '((0 1 2) (3 4 5) (6 7 8) (0 3 6) (1 4 7) (2 5 8) (0 4 8) (2 4 6)))

Each move places a 'X or 'O symbol in the grid, using set-nth or nth-set:

(set-nth (*grid* a-move) 'X)

There's also a function to find the moves still available:

(define (available-moves)
  (index nil? *grid*))

and a function to check whether a proposed move is valid:

(define (check-move move)
  (and (<= 0 move 8) (find move (available-moves))))

Here's a function to see if a player has won:

(define (won? player)
   (letn ((player-squares (index (fn (x) (= x player)) *grid*))
          (wins-for-player 
             (map (fn (win) (= win (intersect win player-squares))) *winning-positions*)))
      (if (exists true? wins-for-player)
          (set '*winner* (list player (find true wins-for-player))))))

This uses the intersect function, which I haven't used much before. The idea is that the set of grid squares occupied by a player might equal or contain the set of numbers which constitute a winning position:

(set 'win '(2 5 8))
(intersect '(2 5 8) '(2 3 5 7 8))
;-> (2 5 8)
(= win (intersect win '(2 3 5 7 8)))
;-> true

I wonder if there's a simpler way to see whether '(2 3 5 7 8) contains '(2 5 8)?

Add a game-over? function:

(define (game-over?)
  (or (won? 'X) (won? 'O) (empty? (available-moves))))

and the mechanics are mostly done.

I found the user interface task a bit harder. The problem is that you have to use an event-driven model, but the only event that's going to happen is the user clicking a square to place a 'X. So inside the main loop:

(do-until (game-over?) (gs:check-event 1000000))

everything has to be driven by mouse clicks. I ended up with something like this:

(define (do-human-move move)
  (and (not (game-over?) (= *turn* "human"))
       (check-move move)
       (set-nth (*grid* move) 'X)
       (display)
       (set '*turn* "computer")
       (do-computer-move)
       (display)))

which kind of works - and you can see now why I used set-nth. You might think that nth-set would do the job perfectly, and it does, but it returns the value of the replaced element, which, being nil, finished the and clause too early.

And what about the third task, adding the intelligent strategy? This is certainly the most interesting part of the job, but I haven't had the time to start it yet. I've been testing with the simplest possible strategy:

(define (generate-computer-move)
  (apply amb (available-moves)))

Here, amb has to be applyed to a list; unlike randomize, it takes single arguments rather than a single list.

Perhaps one day I'll get round to starting the third task. If you want to help me, get the file from the downloads page and get coding!

Each plug-in is just a newLISP context stored in a file, so the first relevant piece of code in the main script is this:

(set 'plug-ins '())
(dolist (i (sort (directory plug-ins-dir "\\.lsp")))
   (load i))

which loads every newLISP file in the plug-ins directory. The code for a plug-in file looks like this:

(context 'Whatever)
; ... function definitions
; and finally:
(push (context) plug-ins -1)
; eof

In the last line the plug-in registers its presence and willingness to participate by appending its name to the master list. The advantage of doing it this way is that you can modify the order in which plug-ins load, and execute, by adjusting the file names, rather than by changing any code. For example, given these plug-ins:

01debug.lsp
10html.lsp
20atom.lsp
30cache.lsp
default.lsp

you can play with the numbers to change the order of execution.

The following macro function in the main script runs through the plug-ins (ie the contexts) in order, executing the same function in each.

(define-macro (call-plug-in-function flag func)
  (catch 
    (dolist (ctxt plug-ins)
      (if (context ctxt func)
          (set 'result (apply (sym func ctxt) (args)))
          (set 'result nil))
      (if (and flag result) 
          (throw result))))
   result)

This tries to call function func in every available context, in the order the files were loaded. There's a flag argument to the macro which is used to specify whether only one plug-in can handle the task or whether all plug-ins can have a shot at the task. The result returned by each function also determines whether subsequent plug-ins can handle the task if for any reason the current plug-in can't cope.

All that's now required is for the tasks to be organized into functions, and for the functions to be passed to call-plug-in-function for evaluation in all contexts.

Here's an example of how it works, for the Atom news-feed plug-in, given the example set of plug-ins shown above. The main script decides that it's time to choose a template:

 (call-plug-in-function true "choose-template")

The call-plug-in-function macro looks for a choose-template function in every context. Only one template set can be chosen, so the true value tells all the plug-ins that the first one to handle it successfully will be the only one to handle it. There's no definition for choose-template in the first plug-in (ie Debug:choose-template doesn't exist), but in the next plug-in there is. However, HTML:choose-template decides that it doesn't want to handle anything to do with Atom, so returns nil. Next, it's the turn of Atom:choose-template, which should be able to complete its tasks successfully and return true:

; in context Atom:
(define (choose-template)
  (cond 
     ((= required-format "atom")
         ;
         ; choose suitable template set
         ;
         true)
    (true
         nil)))

No other plug-ins get the chance of choosing templates now.

Changes to the way Atom-formatted news is generated can be made to the Atom context. The Atom context can be removed altogether without affecting the behaviour of other parts of the application. I could write a different Atom context and try it out by changing the numbers in the filenames.

Notice that I've assumed that the main script provides enough information about the environment and the task in hand for the plug-ins to make intelligent decisions about what to do. I'm also assuming - obviously - that there's no malicious intent or desire to disrupt the whole set-up. It's not a good idea to load any plug-ins from an untrusted source...

It's possible to override built-in behaviour because even the basic tasks are handled by a plug-in file as well. This is loaded last, so it can provide default behaviour to be carried out when none of the other plug-ins have volunteered for tasks.

Some tasks can be handled by a number of different plug-ins one after the other. For example, a 'tidying-up' function is called from the main script with:

(call-plug-in-function nil "tidy-up")

and each plug-in can do some tidying up if necessary.

It's early days yet, but I'm interested to see how many different tasks I can get the plug-ins to handle until I have to make changes to the main script!

(define (help func-name)
   (if (find func-name "|+*-") (push "\\" func-name))
   (set 'html-text (join (find-all (format {<b>(syntax: \(%s.*?)</b>} func-name) 
      (read-file "/usr/share/doc/newlisp/newlisp_manual.html")) "\n"))
  (println (replace "<.*?>" html-text "" 0))
  (silent))

> (help "date")
syntax: (date)
syntax: (date int-secs [int-offset])
syntax: (date int-secs int-offset str-format)
syntax: (date-value int-year int-month int-day [int-hour int-min int-sec])

The first line of the function was a temporary fix for a puzzling bug, and it also offered a nice surprise. The bug was that it was impossible to get help on functions with names like | or + without listing way too much. I eventually realized (duh) that some newLISP symbols were also significant in regular expressions and needed to be escaped. Because no symbols use the period (.), I hadn't bothered to escape it. But it then becomes a useful option for searching for functions:

> (help "fi.")
syntax: (file-info str_name [int-index])
syntax: (file? str-name)
syntax: (filter exp-predicate exp-list)
syntax: (find exp-key list [func-compare | int-option])
syntax: (find str-key str-data [int-option])
syntax: (find-all str-pattern str-text [expr [int-option]])
syntax: (find-all list-pattern list-lists [expr])
syntax: (find-all expr-key list expr func-compare)
syntax: (first list)
syntax: (first array)
syntax: (first str)

The only thing left to do now is to work out how to avoid using silent. Although I want to suppress the value returned by println, I don't want the prompt to disappear as well. Unfortunately, silent does both. I bet there's a way, though!

A Date construct is an element whose content MUST conform to the "date-time" production in RFC3339. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset.

atomDateConstruct =
   atomCommonAttributes,
   xsd:dateTime

Such date values happen to be compatible with the following specifications: ISO.8601.1988, W3C.NOTE-datetime-19980827, and W3C.REC-xmlschema-2-20041028.

and here's ISO 8601:

The following profile of ISO 8601 dates SHOULD be used in new protocols on the Internet. This is specified using the syntax description notation defined in ABNF.

     date-fullyear   = 4DIGIT
     date-month      = 2DIGIT  ; 01-12
     date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                               ; month/year
     time-hour       = 2DIGIT  ; 00-23
     time-minute     = 2DIGIT  ; 00-59
     time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                               ; rules
     time-secfrac    = "." 1*DIGIT
     time-numoffset  = ("+" / "-") time-hour ":" time-minute
     time-offset     = "Z" / time-numoffset
    
     partial-time    = time-hour ":" time-minute ":" time-second
                       [time-secfrac]
     full-date       = date-fullyear "-" date-month "-" date-mday
     full-time       = partial-time time-offset
    
     date-time       = full-date "T" full-time

Important stuff!

In newLISP, you can get time in this format by using a suitable time format string with date. For example, the modification time of a file can be presented in RFC3339 date-time format with this:

(set 'modification-date (date file-mod-date 0 "%Y-%m-%dT%H:%M:%SZ"))

where file-mod-date is the file's modification date as a seconds-from-1970 value, obtained like this:

(set 'file-mod-date (file-info file 6))

The previous blogging tool I wrote made extensive use of compressed ISO 8601 identifiers:

20080419224533

which is a 14-digit number or string. It can be used as either:

(set 'p 20080419224533)
(dec 'p)
;-> 20080419224532
(set 'p "20080419224533")
(length p)
;-> 14

I used this both as the unique identifier for a post or blog entry, and as the publication date. To convert these compressed 14 digit ISO date-times (and others) to a newLISP seconds-from-1970 value, you can use parse-date:

(parse-date "20080419224533" "%Y%m%d%H%M%S")
;-> 1208645133

(date (parse-date "20080419224533" "%Y%m%d%H%M%S"))
;-> "Sat Apr 19 23:45:33 2008"

The first problem is that parse-date on MacOS X systems appears to have some flaws. Lutz reckons that libc.dylib on Mac OS X was broken for the strptime() function somewhere between MacOS X 10.4 (Tiger) and 10.5 (Leopard). It was apparently the case that, for some versions of newLISP and MacOS X, the conversion of compressed ISO8601 identifiers didn't work:

(parse-date "20080411234423" "%Y%m%d%H%M%S") 
;-> nil 

Suddenly being unable to read date strings without spaces, I spent a few minutes writing a parse-iso-date function:

(define (parse-iso-date s)
 (let ((y (pop s 0 4))
       (m (pop s 0 2))
       (d (pop s 0 2))
       (h (pop s 0 2))
       (mn (pop s 0 2))
       (sec s))
 (parse-date (format "%s %s %s %s %s %s" y m d h mn sec) "%Y %m %d %H %M %S")))

but it doesn't look like the right solution - just reformatting a string so that it has spaces between the components and then using parse-date. And later I found that I was converting between different date formats too often: from compressed ISO to Atom, or from compressed ISO to a familiar local representation, and then back into Atom again.

When you stare at a problem for long enough, you can often see a bigger problem hidden behind it. I started to dislike seeing these IDs. References to stories used to take the form:

index.cgi?post-id=20080411234423

which is computer-friendly but user-hostile, easy enough for a computer to produce but not easy for humans to recognise or decipher. I've typed enough of these in by hand to know that it's surprisingly easy to lose your place in a long string of digits when you're tired or in a hurry. Another problem is updating a post makes these date-based IDs less meaningful - but changing them probably isn't the right solution either.

So, for the current blogging script, I've adopted a different approach. Stories are referred to using more readable URLs - I read that this was A Good Idea. Dates are now a part of the metadata but extracted and displayed when required, with more emphasis on how old something is rather than the exact moment it was written. And hopefully it's no longer necessary to display weird date formats just because they're used internally by the software.

I'll have a go at fixing it in the next week.

I was quite pleased that the code to produce the Atom document was only about 45 lines, though.

Edit

I discovered how to make it work: I used a content type of text/xml:

(set '*content-type* "text/xml\n\n")

and claimed that I was generating it using a file called 'atom.cgi', although I'm not.

So now I can put this on my page, apparently:

Unfortunately, there are some features I've yet to get round to doing - the most obvious being the Atom newsfeed. Soon, perhaps.

I don't think I'll be enabling comments again, but the email address should be somewhere on this page so pelase write to me!

I've kept the old articles from the earlier blog here, for posterity, even though some of them are no longer applicable - or just plain wrong.

A sparkline is a little word-sized graph that shows a trend or sequence. Because our brains are so good at reading lower-case words, they also find it easy to absorb data trends if the information is represented in a wavy word-sized graphic - a sparkline. For example, this sparkline shows the changing size of the posts in this blog over time. And this one shows the time between each post since I first started in December 2006. Even though I haven't labelled the axes or provided additional information, you can easily pick out a message from the data - if there's a message to pick out. At least, that's the theory behind sparklines. I've been playing around with sparklines for fun, using newLISP. Here are my thoughts so far.

At first I assumed that the best way to draw sparklines would be to generate an SVG sparkline and embed it into the HTML. After all, SVG is a standard vector format using standard XML, and it should display well in all web browsers that follow current standards. Unfortunately, the standards guys have apparently painted themselves into a corner on this one, because XML isn't compatible with HTML (or XHTML) to the extent that you can just put one inside the other. One of the possible solutions is to change the way pages are served to browser clients, so I decided to try another approach.

Another drawback with the automatic generation of graphs from data is that you don't get a chance to play with your graph before publishing it. Sparklines, like anything else, can benefit from a little tweaking to make them look just right.

Here's my first attempt at a rudimentary Sparkline generator running in newLISP-GS:

At the top, there's the data-entry text box. Anything can be typed in here - non-numeric material is filtered out. This means that you can paste in comma-separated lists as well as plain newLISP-style lists. (This batch of numbers shows the "Coefficients of the '3rd order' mock theta function phi(q)" from the strange and wonderful On-Line Encyclopedia of Integer Sequences.

Next, there's the sparkline. The width of this sparkline 'canvas' changes according to how much data you input. There is, though, a limit to how much data can be plotted; in a 300 pixel wide window there's room for a 300 element set. That's probably enough for most sparklines. If you want more, you can edit the script to give you a wider window and canvas - but if you do, all the controls will move...

Below is a plethora of sliders ... probably too many. The top one changes the height of the sparkline canvas, so you can squeeze it down to 14 pixels and fit it easily into text. The checkbox at the bottom shows the location of the x-axis.

If you want to play with this code, it's on the downloads page.

Google Code is not the easiest of things to get working - I'm not up on this whole svn/code management thing - but it proposes a few advantages that I'm now starting to appreciate. Recently I spent some time looking for a piece of code that I'd deleted some months ago, and if the project had been in a subversion system like Google Code I could have found it more easily.

I'm also hoping that, one day, googling for 'newLISP' will find some of this web site. Currently I think I've reached page 8 or 9...

I'm still struggling to understand the basics of CGI and newLISP. Learning CGI isn't that easy when most of the examples are written in Perl. So I thought this would be good way to get some practice. For the purposes of this post, though, I've changed the example to a simple table that adds rows and columns and puts the totals in the last column and bottom row. Let's see if I can describe it in 10 easy steps.

Step 1: prepare ingredients

This one is easy:

#!/usr/bin/env newlisp
(load {/usr/share/newlisp/modules/cgi.lsp})

I want the cgi.lsp module - part of the standard newLISP install - mainly for the CGI:get function, which retrieves values from the incoming form. I've not looked at cgi.lsp much, so I don't know what's in it.

Step 2: set up a data store

This step sets up a small data storage area. The data submitted by the user will be loaded into the store for subsequent processing. I use a list of lists rather than an array because:

1. Lists are more flexible than arrays, and just as quick if they're not too big.

2. Er, that's it, really.

(set 'rows 10 'columns 10)
(set 'data (dup (dup 0 rows) columns))

To access the value of the cell at row 3 and column 4, I can use the implicit addressing technique: (data 3 4).

Step 3: process the data

In step 3, I can write the functions that actually do something with the data. When these functions are called, there will be data in the data store.

; get column n of data
(define (column n a-list)
  (map (fn (f) (nth (f n))) a-list))

(define (sum-rows)
    ; in each row, add cells and put value in final cell
    (for (r 0 (- rows 1))
       (nth-set (data r (- columns 1)) (apply add (chop (data r))))))

(define (sum-columns)
    (for (c 0 (- columns 1))
       (nth-set (data (- rows 1) c) (apply add (chop (column c data))))))

(define (class r c)
   (cond 
      ((= c (- columns 1)) "total")
      ((= r (- rows 1)) "total")
      (true "cell")))

The class function returns a suitable CSS class for a cell given its location. I can use this when building the HTML form to assign different colours to the various input boxes.

Step 4: extract data from the incoming form

This step feels like it's in the wrong place. I want to extract data from the incoming form, because it contains the numbers that the user has typed into the input boxes. But what form? What boxes? I haven't created them yet - they won't get created until step 8. Well, I think it's confusing!

; extract data from the form
(for (r 0 (- rows 1))
   (for (c 0 (- columns 1))
      (set 'raw (float (CGI:get (string r c))))
      (if (number? raw)
          (nth-set (data r c) raw))))

The data store is filled with numbers.

Step 5: do the calculation

If the user clicks the 'Calculate' button to submit the form, a call to CGI:get {recalc} will return true, so the main action part of the script can take place here.

(when (CGI:get {recalc}) (sum-rows) (sum-columns))

I haven't yet defined that form, though...

Step 6: tidy up

Before the data store's contents are displayed, I want to change the zeroes to spaces, purely for aesthetic reasons. I've used the set-ref-all function (new for version 9.3) to convert them.

(set-ref-all (data 0) "")

Step 7: generate HTML, part 1

The output consists of a header line followed by the HTML page. Most of the HTML is a simple form that uses the POST method to send the completed form to this script.

(print "Content-type: text/html\r\n\r\n")

(print [text]<html>
<head><title>A newLISP calculator</title>
<style>#calc .cell {background-color: #ffeeff; }
#calc .total { background-color: #ddffff; }
</style>
</head>
<body>
<form id="calc" action="index.cgi" method="POST">
[/text])

Step 8: generate HTML, part 2

I'm in the middle of the form. Instead of generating the form manually, I've got newLISP to do it for me. Each input box is named after its row and column, and is assigned a class name for styling. There's a simple data-fetch function in it too. newLISP's format function works fine here - originally I used a more complicated template function but this works well.

(for (r 0 (- rows 1))
  (for (c 0 (- columns 1))
    (println (format [text]<input type="text" class="%s" name="%s" size="6" value="%s">[/text] 
        (class r c) (string r c) (string (data r c))) ))

   ; next row
   (println "
\n"))

Step 9: generate HTML, part 3

The form has a 'Calculate' button which sends the 'recalc' message to this script - I dealt with the message in step 5 but this is where the message is defined.

(println
[text]    
    <p><input type="submit" name="recalc" value="Calculate"></p>
    </form>
</body>
</html>
[/text])

(exit)

Step 10: Serve hot

It looks like I made it in 10 steps. To test the script, start up a newLISP web server and point it at the right place. This is what I do on my Mac:

$ sudo newlisp -http -d 80 -w ~/lisp/cgi-test/

And then visit http://localhost/index.cgi in a browser and try it out. This last step is probably different on other platforms

Any tips or advice from the CGImen or CGIwomen out there will be welcome!

The latest version of newLISP, 9.3, is now available, and there are some great new features.

The new when function is going to replace if in a lot of the scripts I've written. I'm sure a lot of newLISP users have made the following mistake at least once:

(if expression
   (action1)
   (action2))

where they're expecting that both actions will be carried out if the expression is true. But with if it's either the first or the second. The syntax of if requires you to construct a block if you want two or more expressions to be evaluated in sequence:

(if expression
   (begin
      (action1)
      (action2)))

But now there's when, which will make this form easier to read and write:

(when expression
   (action1)
   (action2))

There are also many new powerful techniques for processing items in nested lists, including set-ref-all. For a great introduction to these, see Jeff's post at his newly relocated artful code site.

I haven't managed to prepare a major revision of my Introduction to newLISP for this release, but I tried to include examples of most of the new functions I was able to test. It's difficult to keep up with newLISP's pace of development sometimes. But it's much more interesting to describe a moving target than a static one! As each release adds more powerful functions, some of the examples I wrote last year has been rendered obsolete or - in a few cases - inoperative. For example, my example of writing a macro now provides an unnecessary alternative to the built-in when function.

Apparently, *when* was added to the development builds of newLISP is September 2007, but I never noticed it!

Another function that promises to be one of my favourites is find-all. find-all isn't a new function - it used to work on strings - but now it works with lists, and with lists of lists (or association lists). It can also, when working with lists, take action expressions and comparison functions.

First, here's the familiar original form of find-all working on a string:

(set 't {There are 60 seconds in a minute, 60 seconds in an hour, and 24 hours in a day.})
(find-all {\d+} t)
;-> ("60" "60" "24")

Notice that find-all in this form takes regular expressions without you having to tell it to.

Another form of find-all lets you search a list of lists for a list that matches a pattern. You can specify the pattern with wildcard characters. For example, here's a list of lists:

(set 'symphonies 
  '((Beethoven 9)
    (Haydn 104)
    (Mozart 41)
    (Mahler 10)
    (Wagner 1)
    (Schumann 4)
    (Shostakovich 15)
    (Bruckner 9)))

To find all the lists that end with 9, use the match pattern '(? 9), where the question mark matches a single item:

(find-all '(? 9) symphonies)
;-> ((Beethoven 9) (Bruckner 9))

You can also use this form with an 'action expression' at the end, after the list:

(find-all '(? 9) symphonies (println (first $0) { wrote 9 symphonies.}))
Beethoven wrote 9 symphonies.
Bruckner wrote 9 symphonies.

Here, the action expression uses $0 to refer to each matched element in turn. If you've used replace in newLISP, you'll be familiar with this idea.

There's a third form. For searching a plain list, rather than a list of lists, the syntax is different. Supply four arguments: the search key, the list, an action expression, and the functor, which is the comparison function you want to use for matching the search key. This time, don't use match-style patterns:

(set 'food '("bread" "cheese" "onion" "pickle" "lettuce"))
(find-all "onion" food (print $0 { }) >)
bread cheese lettuce

Here, find-all is looking for the string "onion" in the list food. It's using the > function as a comparison function, so it will find anything that "onion" is greater than. For strings, 'greater than' means appearing later in the default ASCII sorting order, so that "cheese" is greater than "bread" but less than "onion". Notice that, unlike other functions that let you provide comparison functions (namely find, ref, ref-all, ref-set, replace when used with lists, set-ref, set-ref-all, and sort), the comparison function must be supplied.

With the < function, the result is a list of things that "onion" is less than:

(find-all "onion" food (print $0 { }) <)
pickle

With different comparison functions, and the ability to use an action expression for each 'successful' comparison, you can do quite a lot with a single find-all.

Choose a word:

(set 'word "moonstarer")

Select a dictionary. On Unix it's probably in /usr/share/dict/words; Windows users can probably find something suitable here.

(set 'dictionary (parse (read-file {/usr/share/dict/words})))

Define a test for the anagram-ness of two words:

(define (anagrams? w1 w2)
  (= (sort (explode w1)) (sort (explode w2))))

Then use find-all to look for anagrams of the word:

(find-all word dictionary (println $0) anagrams?)

astronomer

newLISP does all the hard work for you. Notice how the comparison function receives two arguments automatically, one from the list, and the other the contents of *word*. Come to think of it, I don't need to continually explode and sort the first word, do I?. I'll leave you to improve it!

Arc is designed above all for exploratory programming: the kind where you decide what to write by writing it. Exploratory programming is the fun end of programming.

It's not for everyone. In fact, Arc embodies just about every form of political incorrectness possible in a programming language.

It's not a coincidence that we wrote a language for exploratory programming rather than the sort where an army of programmers builds a big, bureaucratic piece of software for a big, bureaucratic organization.

newLISP encourages experimentation and exploration, and that's made possible by the rich built-in function library, the design of the language, and the involvement of the newLISP community. I built the blogging engine that you're reading now by exploring and trying out ideas, and not being too concerned at first with the theoretical niceties of functional programming. I think that newLISP encourages that approach, as well as allowing for more serious programming.

I suspect that Messrs Graham and Morris would be very happy if people like me - not just Common Lisp initiates - were able to do the same thing with Arc.

Good luck, Arc!

(define (log-input x)
    (append-file log-file-name
        (string
            (date
                (date-value) 0 "%Y-%m-%d %H:%M:%S") { }
            (get-ip) { } x "\n")))

So whenever anyone types anything and clicks the 'evaluate' button, the date, time, their IP address, and what they typed are saved in a log file. So by looking at the log it's more or less possible to watch people arrive, enter stuff, get annoyed, and go away. This has provided a lot of entertainment - and some education - over the last few weeks, and I'll share some of it here.

2008-01-03 18:40:20 163.453.357.176 hello

(All IP addresses have been scrambled in this post.)

The big drawback of the Lambdalator is that, as with any programming language, if you don't get the format exactly right, the result will be, at the very least, unexpected. newLISP doesn't pretend to understand English, and the Lambdalator isn't an exercise in artificial intelligence or natural language parsing. It's just a simple online calculator-style utility expecting expressions using newLISP syntax; there's only 100 or so lines of code, and a chunk of that is HTML.

But I wish I'd added some extra code to handle input like this:

2008-01-03 15:06:48 33.453.30.235 how are you doing?
2008-01-03 15:07:14 33.453.30.235 What is the purpose of this?

or to respond to 'calculations' like this:

2008-01-03 12:08:24 84.43.89.37 Today I am going to work very hard

2008-01-04 21:48:59 93.453.398.228 sausages

2008-01-05 10:08:23 63.453.31.191 poop

Of the people that have actually tried to use it as a calculator, many have of course been thrown by the postfix notation, the compulsory parentheses, and the need for white space to separate functions and arguments. With no knowledge of what should be typed, and a reluctance to click the 'help' button, newLISP's responses are entertaining, enigmatic, irritating, or just baffling. Here are some examples - I've added the Lambdalator's replies so that you can sympathize - or not - with the questioner:

2008-01-06 22:43:06 83.453.359.133 (+22)
invalid function : (22)

2008-01-05 18:28:54 153.453.38.114 (+2 2)
illegal parameter type : 2

2008-01-04 12:42:33 63.453.381.231 (2 -3 2 2 6)
illegal parameter type : -3

2008-01-06 19:46:23 76.73.453.332 + 2 2
2

2008-01-06 21:11:36 73.453.303.239 61-8
-8

2008-01-05 04:01:22 166.70.39.75 add 5 65 46
46

2008-01-05 02:42:53 33.453.39.213 2*5
nil

2008-01-04 12:41:39 63.453.381.231 4 plus 2
2

2008-01-03 13:28:50 33.453.332.66 cos(x) + sin(y)
invalid function : (x)

2008-01-07 03:56:41 32.423.242.38 ( 6% of 70)
illegal parameter type : %

Many were confused by the fact that the Lambdalator returns the value of the last expression evaluated, but only the last. So + 2 2 returns the last 2 - not the expected sum.

Here are some optimistic entries, where people have expected more from my efforts than I could deliver:

2008-01-03 15:18:06 143.453.329.143 2x+3=40
nil

2008-01-03 15:18:48 143.453.329.143 x=2y+4
nil

2008-01-05 16:52:29 85.59.94.226 56+33*x=0
nil

2008-01-04 12:39:08 73.453.33.175 x2\y=9
nil

2008-01-03 05:29:36 68.73.453.30 1+x=9
nil

Luckily newLISP refrains from offering an opinion on such weighty matters. One day I'll write something that solves equations.

Some people have a different idea about what parentheses are:

2008-01-03 18:06:31 68.453.37.26 [2.3]+{4[6.3]}
nil

2008-01-04 13:21:50 193.453.355.48 [ + 2 2 ]
nil

One problem that I had anticipated is that in newLISP the standard arithmetic operators such as '+' and '-' are integer only, and you use the 'add' and 'sub' equivalents for floating-point operations. I've got used to this, and there's an easy way to re-define '+' to do the job of 'add', but I decided to keep the behaviour as close to the documented default as possible. But it's a pity that a good attempt like the following should have received the wrong answer:

2008-01-08 00:01:49 75.453.32.16 (+ (+ 1.234 91.3) (+ 1.234 91.3))
184

A few Lisp speakers have visited the site, and they obviously know the basics, although the whole thing is probably much too simplistic and toy-like for the Common Lisp folks. I seem to remember that 'car' is the equivalent of newLISP's 'first' function, and it's obviously a favourite (but not available by default in newLISP):

2008-01-07 03:25:17 72.453.32.16 (car '(a b c))
invalid function : (car '(a b c))

2008-01-03 19:40:50 83.453.305.64 (car (cons 1 "a" 3.45  'foo))
invalid function : (car (cons 1 "a" 3.45 'foo))

2008-01-07 03:25:01 73.453.32.16 (cons '(a b c))
((a b c))

2008-01-10 20:41:37 63.453.379.30 (foldr list 'end '(a b c d))
invalid function : (foldr list 'end '(a b c d))

I've not heard of 'foldr'.

But here's a fun entry that set me thinking:

2008-01-10 20:47:45 65.453.379.30 (apply (lambda (x) (* x 2)) '(1 2 3))
2

Why does this return 2 - and not 6, for example, which I might have expected, although I would have used 'map':

(map (lambda (x) (* x 2)) '(1 2 3))
(2 4 6)

The other big drawback with the whole idea of the Lambdalator is that it's not possible to have a persistent newLISP interpreter online in this way. Well, it's probably possible, but I know that my current host doesn't allow persistent processes, and I expect there are other issues to think about. At the moment the web page gives the illusion of some persistence, with the 'paper tape' feature of a typical desktop calculator keeping a record of what's been processed, but of course in reality every time an expression is submitted a new session is started with no record of any previous entries.

I think I'll keep the Lambdalator online for a few more weeks, since it's interesting to watch what people make of it, and I make use of it myself occasionally. I've yet to see anyone trying to hack the security, which will be interesting - and possibly worrying - to watch.

You downloaded this page on Fri Aug 29 04:14:59 2008.

The idea is that I can include some raw newLISP that gets evaluated only when the page is generated and displayed in the browser.

I stole this cool idea from Jeff's post in the newLISP forum.

The newLISP code goes between two tags. I'm using {% and %}, which looks like a reasonable choice.

This is the render function I'm using:

(define (render t)
    (replace {{ %(.*?)% }}
       ; spaces inserted between { and % !!!
        t (if (catch
                (eval-string $1) 'result)
            (string result)
            (string " [inline error: " $1 "] ")) 0))

Unfortunately, because this code contains the magic tags, it wouldn't have displayed correctly had I not put spaces between the "{" and "%" characters. The engineer hoist with his own petard, or something.

I also managed to write a bit of code this year, including this blogging engine (the LamdbaPress), various GUI apps, source-code formatting, a port of Markdown (I never want to look at that code again!), and a TEX to HTML translator that produces the Introduction to newLISP (which is kindly hosted at newlisp.org. None of this code would win any prizes for elegance or idiomatic Lispiness (or even reliability); but we all do what we're best at!

However, there are prizes to be won: don't forget to vote for some of the elegant and ingenious entries in the newLISP 2007 competition. You have a few more days to vote...

And if you didn't get round to submitting an entry for this year's competition, get coding for the 2008 competition!

As ever, a big thanks to Lutz and everyone in the newLISP community for your contributions over the year. 2007 has been fun.

Now for 2008!

I spent a few minutes trying to generate this calendar in languages other than English. (That "en" is a clue!) It was easy enough to produce the month and day names in the different languages, using newLISP's set-locale function:

(set-locale "nl_NL")

; netherlands
(set 'day-of-week
    (date start-date 0 {%A}))

;-> "woensdag"
(set-locale "C")

; quickly back to default locale

But unfortunately I think PostScript isn't very clever when it comes to Unicode, and it failed to translate the strings properly. It's not much of a problem for some languages, but it's more serious for others (and disastrous for Russian):

среда

so until I work out how to get Unicode strings from newLISP to PDF via PostScript, I'm going to stick with English. If you have any clues, please let me know - the internet has let me down, again!

To reduce the problem to its simplest case, suppose that we want to work through a list looking at each pair of items:

(set 't (sequence 0 13))

0 and 1
1 and 2
...
12 and 13

Solutions are easy to see now, but for some reason I could think only of using dolist or for, which are the more conventional tools for working through lists.

dolist keeps the current position in the list in a system variable $idx, so you can use that to find the next element, given that the loop variable i is the current element.

(dolist (i t)
    (println { processing } i { and }
        (t (+ $idx 1))))

Here, the implicit addressing (t $idx) returns the same element as i, so the next one is obviously (t (+ $idx 1)).

But there's a trap for the newbie:

processing 0 and 1
...
processing 12 and 13
processing 13 and 13

Helpfully, newLISP won't crash your scripts just because you overstepped the end of a list, but it definitely is your job to stop processing the list at the right stage.

So let's add a break condition:

(dolist (i t (= $idx
            (- (length t) 1)))
    (println { processing } i { and }
        (t (+ $idx 1))))

This now stops the loop when the penultimate item in the list has been processed.

How about for? This can also work:

(for (i 0 (- (length t) 2))
    (println { processing }
        (t i) { and }
        (t (+ i 1))))

It's easy to make mistakes if you're not concentrating; there are 14 elements in the list; we use index numbers 0 to 13 to get them; with for loops that means stopping at one less than the length; and as we're doing pairs we stop two before the length.

But there must be a better way. How about using apply?

(apply
    (fn (a b)
        (println { processing } a { and } b)) t 2)

See that last '2'. The anonymous function uses two arguments, and the 2 tells apply to use two arguments at a time. It looks like it works nicely:

processing 0 and 1
...
processing 12 and 13

But the newLISP manual says that the result of each application is re-used as the first argument for the next application. What's happening is that the result of that println expression was the last number evaluated (which was b), and that was also, conveniently enough, the value that we wanted to use as the first number for the next pair.

To see what's going on, make the lambda function return something else:

(apply
    (fn (a b)
        (string a { and } b)) t 2)

;->
 "0 and 1 and 2 and 3 and 4 and 5 and 6 and 7 and 8 and 9 and 10 and 11 and 12 and 13"

So I think it's possible to use apply to apply a function to pairs of items if you remember to return the value of the last member of each pair, so that apply can use it for the next pair.

And you could use map:

(map
    (fn (a b)
        (println a { } b))
    (chop t)
    (rotate t -1))

which uses two versions of the list, chopping the end of one and rotating the second. Helpfully, the extra element in the second list is ignored.

More solutions welcome!

(set 'theList (sequence 0 13))

(dolist (t (explode theList 2 true))
    (println "processing " (t 0) "and " (t 1)))

(map 
  (fn (x y) (println x " and " y)) 
  (0 -1 theList) 
  (rest theList))

(cond
    ((= start end)
        (push (list "white-space" source-string) token-list -1))

("left-paren" "(")

("code" "cond")

("left-paren" "(")

("left-paren" "(")

("code" "=")

("code" "start")

("code" "end")

("right-paren" ")")

("left-paren" "(")

("code" "push")

("left-paren" "(")

("code" "list")

("quoted-string" "\"white-space\"")

("code" "source-string")

("right-paren" ")")

("code" "token-list")

("code" "-1")

("right-paren" ")")

("right-paren" ")")