Skip to content
Tech News
← Back to articles

Lent and Lisp

read original get Lisp Programming Book → more articles
Why This Matters

This article highlights the intersection of cultural calendars and computational tools, emphasizing how programming languages like Lisp can be used to explore astronomical and cultural date calculations. It underscores the challenges developers face when integrating complex calendrical computations into software, which is crucial for creating culturally aware digital applications.

Key Takeaways

Next post Previous post

After writing last week’s post about the start of Ramadan and Chinese New Year, I expected to hear from people asking why I didn’t include the further coincidence of Ash Wednesday. I was surprised that the only such feedback I got was an email from TJ Luoma. It makes sense that Lent would be on TJ’s mind—it’s a big part of his business calendar—but I had an answer prepared, and I wrote him back with my reasons.

As I typed out the reply, though, the reasons seemed weaker. Yes, it’s true that the full moon that determines this year’s date of Easter (and therefore Ash Wednesday) isn’t part of the same lunation that determines the start of Ramadan and Chinese New Year, so there was an astronomical reason to keep Ash Wednesday out of the post. But it’s also true that both Ramadan and Lent represent periods of self-denial, so there’s a cultural connection.

Adding a new bit of Emacs Lisp code to what I’d already written to include a check for Ash Wednesday wouldn’t be hard, but another thought was buzzing in my head: switching from Emacs Lisp to Common Lisp. The ELisp calendar functions were written by Edward Reingold and Nachum Dershowitz, authors of the well-known Calendrical Calculations. That book includes a lot of code that isn’t in the Emacs implementation, code that does astronomical calculations I’d like to explore. So it seemed like a good idea to write a Ramadan/Lent/Chinese New Year script in Common Lisp and use the functions from the book.

The problem with that idea was that the Common Lisp code I downloaded from the Cambridge University Press site, calendar.l , didn’t work. I tried it in both SBCL and CLISP, and calling

(load "calendrical.l")

threw a huge number of errors. I was, it turned out, not the first to have run into this problem. The workarounds suggested there on Stack Overflow didn’t help. There’s a port to Clojure that apparently works, but I was reluctant to use Clojure and have to maintain both it and a Java Virtual Machine.

What I found, though, was that Reingold & Dershowitz’s code would load in CLISP with one simple change. After many lines of comments, the working part of calendar.l starts with these lines:

(in-package "CC4") (export '( acre advent akan-day-name akan-day-name-on-or-before [and so on for a few hundred lines] yom-ha-zikkaron yom-kippur zone ))

Deleting these lines got me a file that would load without errors in CLISP,1 so I named the edited version calendar.lisp and saved it in my ~/lisp/ directory. I believe the problem with the unedited code has something to do with packages and namespaces, and if I keep using Common Lisp long enough, I may learn how to make a better fix. Until then, this will do.

... continue reading