Consider using closer-mop

[dieggsy]

sql/base/package.lisp does a bunch of implementation conditionals to import MOP symbols. It may be cleaner to use closer-mop instead. A potential issue is closer-mop no longer lists cmucl as actively supported, though it still ships a closer-cmu.lisp file (which may or may not work).

[dieggsy]

To get around CMU maybe not being supported, we could just keep importing-from for both closer-mop and cmucl, in which case symbols should stay the same, and we can cover other supported implementations with closer-mop.

It would be nice not to have to import and just use package qualified c2mop: symbols, though.

[dieggsy]

As it turns out, I don't think CMUCL has 64-bit support:

• 64-bit cmucl (#286)
• Mac OS 10.14 can't build cmucl (#75)

It seems likely this is the reason closer-mop no longer officially supports it.

Given this (and the increasing scarcity of operating systems supporting 32-bit architectures), we could stop officially supporting CMUCL until further updates on their end?

[snunez1]

As it turns out, I don't think CMUCL has 64-bit support:

• 64-bit cmucl (#286)
• Mac OS 10.14 can't build cmucl (#75)

It seems likely this is the reason closer-mop no longer officially supports it.

Given this (and the increasing scarcity of operating systems supporting 32-bit architectures), we could stop officially supporting CMUCL until further updates on their end?

FWIW, rtoy claims there are efforts underway to port CMUCL to 64-bit. I have no visibility into that effort but would love to see it succeed. There's a lot to like about CMUCL and its environment.