This is a great achievement: bitwise-identical output of the compiler when bootstrapped with different CL implementations.

It is inspiring to see people like Christophe Rhodes work on SBCL and make tremendous progress.

He is sufficiently honest to write how he missed an obvious typo (guess what, this happens with every language, no matter how hard you try to avoid them). Unfortunately, this is now the most discussed part of the article, which is sad.

Quoting:

(shades of times gone by). Eventually I realised that (unless (member (package-name package) '("COMMON- LISP" "KEYWORD" :test #'string=)) ...)

was not the same as (unless (member (package-name package) '("COMMON- LISP" "KEYWORD") :test #'string=) ...)

I know this is a bit nitpicking but this is the kind of mistake which will be always difficult to detect in lisp as long as the syntax is what it is... Which is a pity because I like the language so much.

Indenting/formatting conventions can make such a mistake easier to detect.

Compare

    (unless

        (member

            (package-name package)

            '("COMMON-LISP" "KEYWORD")

            :test #'string=) ...)

and

    (unless

        (member

            (package-name package)

            '("COMMON-LISP" "KEYWORD" :test #'string=)) ...)

If `member` requires 3 arguments, then it's easy to spot the mistake in the latter.

Yes, thank you (by the way I am totally unable to properly quote things here). I understand, yes.

You can create quoted text by leaving a blank line, indenting what you want to quote, then leave another blank line.

https://news.ycombinator.com/formatdoc

I am amazed that you have taken the time to reply and explain! Thanks.

If there's a question I can answer in 30 seconds as I pass by, then I figure it's worth doing. I've recently been looking at systems to try to capture and make available knowledge bases that can be searched, mined, and possibly automated.

How can we help people to stand on the shoulders of giants ...

I hope you are lucky. I am a prof. of maths and find your approach ro helping very near my heart and as I know that it does take some effort, I really appreciate it.

There are valid criticisms of lisp syntax, but I'm not sure this is one of them. This kind of mistake [writing f(g(x,y)) where you want f(g(x),y)] is easy to make and (sometimes) hard to spot in many languages.

Honestly I think lisp would gain a lot just by having more choices of paired delimiter. The fact that [ has to match ], < has to match >, { has to match } and ( has to match ) is a huge aid to visually understanding the AST of some code. The fact that in lisp e.g. array accesses are not different from function calls, or that blocks are not different from expressions, is a great advantage, but we would do better to preserve the option of using several different delimiters.

The great thing about Common Lisp is that if you really want to use another paired delimiter, you can using reader macros e.g. it is quite trivial to translate

  [1 2 3]

into

  (vector 1 2 3)

and now you have more conventional looking array literals.

The terrible thing is that this is not standardized, so every codebase ends up with a slightly different version of what [ means.

> Honestly I think lisp would gain a lot just by having more choices of paired delimiter.

Many lisps either allow alternate paired delimiters in general or demand them for specific constructs (or both -- Racket and many Schemes do both, and all Schemes do at least the latter.)

Racket (a Scheme dialect, not CL) allows us of brackets [] and curly braces {} in place of parentheses.

Yay, now we can determine if our SBCL build contains a backdoor.

https://www.schneier.com/blog/archives/2006/01/countering_tr...