In 1993, your choices were fairly primitive Schemes (R4RS, IEEE Scheme), Dylan, and MacLisp derivatives, with Common Lisp coming off a huge 80s market boost. Seems about right that it’d mostly target CL.
It’s not unreasonable, but I thought it would be helpful to provide context to other readers, since for instance I only recently learned that macros were not standardized until R5RS (1998) and until then assumed they had been part of the language for much longer.
The real fun is that R4RS’ appendix describes both low level, and syntax-rules based hygienic macros. syntax-rules has no way to break hygiene, but there are multiple systems that provide hygiene and low level facilities in the same system (explicit renaming and syntactic closures, namely).
syntax rules probably shouldn’t have won, but declarative pattern based macros are kind of elegant … I guess.
I was very amused by “Use Near-Standard Tools” saying that everyone should use Emacs.
What would you use? In my limited knowledge, the closest thing to a competitor to Emacs for Lisp development would be Dr Racket, but that (1) is for Scheme and (2) didn’t exist in 1993.
Oh, I would still use Emacs personally; I just wouldn’t tell everyone else that they need to do the same. But I was in elementary school in 1993 so who knows.
Our software vendor uses VCS, but has a long history of signing and dating code sections with paragraph explanations. They’ve been developing the same codebase since the 70’s and release the uncompiled source along with the precompiled binaries. Their documentation is horrendous, but the source and comments help out quite a bit.
I recently configured my editor to expand “todo”/ into “TODO | – $name, $date” (where | is where the caret ends after expansion).
and
One small point of disagreement I have with this document is on p. 13: “and and or for boolean value only”. Interestingly, they don’t show an example of what to write instead of non-boolean or, and I think that’s perhaps because it’s a bit involved. The naive expansion of (or A B) would be (if A A B). But A might be a large or expensive subexpression, in which case you should write something like (let ((a A)) (if a a B)) — or, if your style guide insists you should avoid nil punning altogether, (let ((a A)) (if (null a) B a)).
This is a common enough idiom to deserve an abstraction. I suppose you could define another macro for it — maybe call it otherwise — and reserve or for booleans, as Norvig and Pitman recommend. But or does the same job, and at least in some subcommunities, there is already a long tradition of using or for this purpose.
The argument in the case of and is weaker. As the document shows, instead of (and A B) you can write (if A B nil). I think the former is easier to read than the latter, but this is more a matter of taste and what one is accustomed to.
p. 39: Of course, ASDF has won the DEFSYSTEM wars, and deservedly so.
p. 41: I don’t know anyone who still sticks to 80 columns. 120 seems to be the modern standard.
Ah, I stumbled upon this guide earlier this year! I was teaching myself Scheme and was wondering about best practices, code formatting, etc. I had also found this:
Riastradh’s is my personal favorite; so much that I based the Fennel style guide on it. (Its unusual license made it so that I got contacted by FSF people asking me to delete my derivative style guide from the repository.)
this is not in the pdf, but i think this might be an appropriate place to ask because it’s about lisp style, why is the closing bracket usually on the same line in lisp? i tried using guix as a second package manager and it was the weirdest thing about it for me, e.g.
(define (english-plural n str)
(if (= n 1)
str
(concat str "s"))) ; i have to count them! and if i want to add something i have to edit this line too
; instead of
(define (english-plural n str)
(if (= n 1)
str
(concat str "s")
) ; visiblle where what ends
; i can add something here without touching other lines to it's easier and git diffs are cleaner
) ; so it seems to me to be more convenient, so why not?
Your editor will make closing parentheses when you make the opening, but consider that we don’t even type the opening parentheses (and barely see them). Use Paredit! https://calva.io/paredit/ or http://danmidwood.com/content/2014/11/21/animated-paredit.html It lets you directly move across levels on the AST. Learning the more useful hotkeys costs perhaps 1-2 hours (but is a huge indicator of success with lisp and helps you get more out of it.)
Aesthetically, a nice final ))))))) saves space, which I like. I always preferred this style in other languages, so was happy and never thought about it in Lisp. (Pascal’s end is cool, though.)
Structures/operations (tend to) happen at the beginning of a line and have a specific shape. Where they end is indicated (to us humans) by indentation) which the IDE largely handles.
I don’t think it’s so relevant for Guix, though (since you won’t use so much of it.)
Note that this is about Common Lisp (and maybe to a lesser degree other MAClisp derivatives like Emacs Lisp) and not really about lisps in general.
I was very amused by “Use Near-Standard Tools” saying that everyone should use Emacs.
In 1993, your choices were fairly primitive Schemes (R4RS, IEEE Scheme), Dylan, and MacLisp derivatives, with Common Lisp coming off a huge 80s market boost. Seems about right that it’d mostly target CL.
It’s not unreasonable, but I thought it would be helpful to provide context to other readers, since for instance I only recently learned that macros were not standardized until R5RS (1998) and until then assumed they had been part of the language for much longer.
The real fun is that R4RS’ appendix describes both low level, and syntax-rules based hygienic macros. syntax-rules has no way to break hygiene, but there are multiple systems that provide hygiene and low level facilities in the same system (explicit renaming and syntactic closures, namely). syntax rules probably shouldn’t have won, but declarative pattern based macros are kind of elegant … I guess.
What would you use? In my limited knowledge, the closest thing to a competitor to Emacs for Lisp development would be Dr Racket, but that (1) is for Scheme and (2) didn’t exist in 1993.
Oh, I would still use Emacs personally; I just wouldn’t tell everyone else that they need to do the same. But I was in elementary school in 1993 so who knows.
My guess is that technomancy would use Fennel. But that also came a few decades after the paper.
Some good comments from other discussions:
and
Ah, I stumbled upon this guide earlier this year! I was teaching myself Scheme and was wondering about best practices, code formatting, etc. I had also found this:
Riastradh’s is my personal favorite; so much that I based the Fennel style guide on it. (Its unusual license made it so that I got contacted by FSF people asking me to delete my derivative style guide from the repository.)
this is not in the pdf, but i think this might be an appropriate place to ask because it’s about lisp style, why is the closing bracket usually on the same line in lisp? i tried using guix as a second package manager and it was the weirdest thing about it for me, e.g.
Your editor will make closing parentheses when you make the opening, but consider that we don’t even type the opening parentheses (and barely see them). Use Paredit! https://calva.io/paredit/ or http://danmidwood.com/content/2014/11/21/animated-paredit.html It lets you directly move across levels on the AST. Learning the more useful hotkeys costs perhaps 1-2 hours (but is a huge indicator of success with lisp and helps you get more out of it.)
Aesthetically, a nice final
)))))))saves space, which I like. I always preferred this style in other languages, so was happy and never thought about it in Lisp. (Pascal’sendis cool, though.)Structures/operations (tend to) happen at the beginning of a line and have a specific shape. Where they end is indicated (to us humans) by indentation) which the IDE largely handles.
I don’t think it’s so relevant for Guix, though (since you won’t use so much of it.)