Cross-compiling and #. (read time eval)

[kchanqvq]

Continuing my adventure of loading alexandria, I think I just have one obstacle left...

alexandria occasionally use #.(...), this is otherwise fine, but result in picking up implementation-dependent constants from the host environment, like most-positive-fixnum (not a real problem for now, we're not handling bignum anyway), and lambda-list-keywords (resulting in non-existent symbol sb-int:&more and is fatal).

I don't know whether this is a solvable problem. I can't wrap the read time eval expressions in let, because the standard disallow let binding these variables. SICL folk's "First-class Global Environment" looks like the solution, but I don't think a usable implementation of the concept exist yet (certainly not in SBCL).

Thoughts?

p.s. The easy answer is "the problem goes away if we do as any other CL impls, only use cross compilation for bootstrapping and compile user code in target environment". But I'm just curious to see how far can cross compiling user code goes, and if it does turn out to work, such approach might have some benefits (host CL has better development environment like SLIME, and we can use fast host CL like SBCL to compile faster than target JSCL).

[kchanqvq]

CLHS 3.2.2.3:

Constant variables defined in the compilation environment must have a similar value at run time.

So conforming program is indeed allowed to make such assumption...

[cireu]

I feel more strongly that your problem of lambda-list-keywords (at https://github.com/kmx-io/alexandria/blob/master/alexandria-1/macros.lisp#L228) is a bug of Alexandria.

LAMBDA-LIST-KEYWORDS is implementation-defined, and Alexandria unnecessarily use #. here.

[kchanqvq]

@cireu No, I think this is somewhat bad taste but not a bug. As per the quoted CLHS section, Alexandria can assume the value of LAMBDA-LIST-KEYWORDS doesn't change (similar) between compile and run time envrionment. In our cross compilation process it changed, causing the build to fail, so the blame is on ours.