Attempted build, got "Fatal error: The variable +WHITESPACE-CHARACTERS+ is unbound."

[qwertystop]

I'm on OSX. I installed Roswell from Brew, and from there installed SBCL (1.5.4), Quicklisp, and cffi-grovel. Then I ran make LISP='ros -s cffi-grovel run --' and got, after a few things had loaded (apparently successfully; there were naming-convention warnings but no errors), the following:

; Loading "shcl"

Fatal error: The variable +WHITESPACE-CHARACTERS+ is unbound.

~I don't see +WHITESPACE-CHARACTERS+ anywhere in the repo, from a grep.~ right, case-insensitive.

[SquircleSpace]

That particular failure started with SBCL 1.5.3. I don't know what is going on, honestly. As best I can tell, its taking issue with the +whitespace-characters+ constant in shcl/core/utility.lisp. I can't understand why it would find an issue with it, though. Below I've included every line of code that directly references that constant.

(defconstant +whitespace-characters+
  (if (boundp '+whitespace-characters+)
      +whitespace-characters+
      #(#\Space #\Linefeed #\Formfeed #\Vt #\Tab #\Return))
  "The set of characters which should be considered whitespace")

(defun whitespace-p (char)
  "Returns non-nil iff the given character is a whitespace character"
  (find char +whitespace-characters+))

Unless I've seriously misunderstood how this language works, I don't see how this could be an issue with SHCL. I even grepped through all the libraries I depend on (and the source of SBCL itself) looking for other symbols with the same name. I came up empty handed. At this point, my leading theory is that its a compiler bug.

FWIW, SHCL builds fine against SBCL 1.5.2. You can see the latest CI builds at https://travis-ci.org/bradleyjensen/shcl/branches.

I don't like freezing the supported version. It feels like a cop-out. I mean, how do I know that its really a compiler bug? Until there's a root cause, this could very well be caused by some heinous corruption that SHCL is inflicting on SBCL! The last time I froze the supported SBCL version, I had a root-cause in hand. I didn't file a bug against anyone else for it (due to laziness), but I was positive that SHCL wasn't at fault. This time, I've only got a suspicion.

If you just want to play around with SHCL, I'd recommend either using CCL or SBCL 1.5.2. If you're interested in investigating a potential bug in SBCL's FASL loading logic... I might have just the bug for you!

[qwertystop]

Thanks. Unfortunately I am not yet sufficiently competent with Lisp to think I'd be able to make headway on a bug like that, but switching versions did get through the build -- though sudo make install didn't work because it was trying to run sbcl, I had to do sudo make install LISP='ros -s cffi-grovel run --' like with the build.

[jakelaboss]

So I might be a little late to this, but constants work differently then a lot of other values in lisp. A constant won't evaluate it's form in the same way as say (setq +whitespace-characters+ ~form~). I think you're better off with something like:

(defmacro define-constantx (name value &optional doc) `(if (boundp ',name) (symbol-name ',name) (defconstant ,name ,value ,@(when doc (list doc)))))

(define-constantx +whitespace-characters+

(#\Space #\Linefeed #\Formfeed #\Vt #\Tab #\Return)

"The set of characters which should be considered whitespace")

I don't fully understand the intricacies, but I do believe this is totally intended behavior for sbcl, In that the sbcl is strict about it's implimentation of defconstant. To quote from the manual:

It’s especially annoying because, in SBCL, defconstant takes effect not only at load time but also at compile time, so that just compiling and loading reasonable code like (defconstant +foobyte+ '(1 4)) runs into this undefined behavior.