Pascal Costanza, a Lisp programmer and researcher, hosts his Common Lisp guide and papers on context-oriented programming and dispatch.
HN commenters cite his opinionated Lisp guide on the LOOP macro, and his filtered dispatch paper as an influence on Clojure's dispatch.
Also worth mentioning is Peter Norvig's and Kent Pitman's style guide. It's got a bunch of examples but I've found the presentation helpful when thinking about style in general for other languages, too: https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf
The code in Norvig's book "Paradigms of Artificial Intelligence Programming" is enjoyable to read as well. As a pdf the book itself is freely available: https://github.com/norvig/paip-lisp
And then of course there's the classic Costanza guide at http://www.p-cos.net/lisp/guide.html (not so much about style per se) that contains an important remark, "There cannot be "the one definitive guide" to Lisp. What I present here is what I would have liked to have seen in the first place. Other people probably prefer a different approach."
A quick glance at the broader open source ecosystem will show anyone that most projects don't follow this particular style guide, or this guide is silent on certain things that are probably considered good form enough to put in a company guide, like using uninterned symbols for packages, or using qlot for version pinning your dependencies and having reproducible builds in your CI system, or using UIOP for anything to do with file paths, or... One needs to get comfortable loading a system and then using the usual cross-referencing features of an editor (emacs, vim, atom (https://atom.io/packages/slima), really anything that can talk to a swank server...) since reading code will be the surest…
I shared the urge to avoid loop until I read Pascal Costanza's Highly Opinionated Guide to Lisp[1]
>> Seemingly, the intended way to use the LOOP facility is to just "guess" a way to express an iteration and see if it works. If it doesn't you can either look up the specifics ...
Since then, I do just guess at the syntax and it strangely does what I want most of the time.
It seems that a library like this has a lot to prove because a) it doesn't provide a new capability, b) it adds a project dependency, and c) creates yet another way to do a standard task. If you really don't like the loop macro, you probably don't need much persuading, but I would have liked to have seen more discussion on the these trade-offs.
[1] http://www.p-cos.net/lisp/guide-v1.html
It seems to me that worlds permit sharing immutable data structures, and that Warth & Kay's operations on worlds do not permit sharing mutations done in parallel worlds.
The Worlds paper you cited [http://www.vpri.org/pdf/rn2008001_worlds.pdf] cites the COP overview paper [http://p-cos.net/documents/contextl-overview.pdf] mentioned near the top of the link jrockway gave. Warth & Kay say "Similarly, in order to support context-oriented programming (COP) [8], we may want to add a third key to our lookup table that identifies a context." So that gives me some confidence in my interpretation.
The debate over hygienic-macros is not as straight-forward: https://groups.google.com/d/topic/comp.lang.lisp/dcX15VC5BdM/discussion
Some* argue that hygienic-macros are an unnecessary burden because sometimes you need to capture variable names and this is easy to do with Common Lisp. The situation with Scheme is different because it stores variable and function definitions in the same way (Lisp-1 vs. Lisp-2).
* http://p-cos.net/lisp/guide.html
The receivers mechanism is kind of nice; reminds me of this[0], except that in Kotlin, everything is still statically typed. It's a really clean way to implement Trygve Reenskaug's DCI architecture.
[0] http://www.p-cos.net/documents/contextl-soa.pdf (there was once an article called "ContextL : The Holy Grail of Business App Development", but this seems to be no longer available
Yeah I've blown the stack more times than I can recall when using non-tail recursion. I do enjoy recursion, it seems like a clean and elegant solution, though I'm ridiculously preoccupied with writing non idiomatic code.
Pascal Costanza has an interesting opinion[1] on why TCO wasn't included in the ANSI standard.
[1]http://www.p-cos.net/lisp/guide.html