From: Peter Seibel
Subject: constantp values always available at macro expansion time?
Date:
Message-ID: <m3mzyeshqm.fsf@javamonkey.com>
I have vague recollection of someone (Tim Bradshaw maybe) posting
something about certain impls (CMUCL maybe?) not making constants
available at compile time leading code like the following to behave
badly when THING is a DEFCONSTANT'd constant:
(defmacro foo (thing)
`(print
,(if (constantp thing) (frob thing) `(frob ,thing))))
Before I go try to track the whole thing down in Google, I was
wondering if someone who was involved could give me the executive
summary of the "resolution"--e.g. "everyone" agreed that such impls
are either conformant or non-conformant or everyone just agreed to
disagree.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
[Sorry for the late response... Work's been busy...]
Peter Seibel <·····@javamonkey.com> wrote:
+---------------
| I have vague recollection of someone (Tim Bradshaw maybe) posting
| something about certain impls (CMUCL maybe?) not making constants
| available at compile time...
+---------------
Yeah, Tim & me both. I first ran into it [I use CMUCL, he doesn't] as
an issue with a certain version of Tim's HTOUT macros [circa Aug'03]
that attempted to do more aggressive compile-time constant aggregation
[e.g., collapsing (PROGN (WRITE "foo") (WRITE "bar")) into (WRITE "foobar"),
that sort of thing], and had a lengthy private sidebar with Tim that
led to his backing out part of the new optimization [or putting it under
feature test, I forget]. Then there was some discussion of it here in
May'04. See my article <···························@speakeasy.net>
and nearby articles.
+---------------
| ...leading code like the following to behave badly when THING is
| a DEFCONSTANT'd constant:
| (defmacro foo (thing)
| `(print
| ,(if (constantp thing) (frob thing) `(frob ,thing))))
+---------------
Yup! That's exactly the scenario which can break in CMUCL, if THING
is a symbol defined with DEFCONSTANT (though it works if THING is
a keyword symbol).
+---------------
| Before I go try to track the whole thing down in Google, I was
| wondering if someone who was involved could give me the executive
| summary of the "resolution"--e.g. "everyone" agreed that such impls
| are either conformant or non-conformant or everyone just agreed to
| disagree.
+---------------
Well, despite any concensus of what the standard *should* have said,
IMHO most agreed that what it *actually* says is that CMUCL *is*
conformant. The problem is that the CLHS requires that:
...symbols declared as constant by the user in the indicated
environment using DEFCONSTANT are always considered constant forms
and must be recognized as such by CONSTANTP.
yet does *NOT* require that the *value* of such a symbol be available
at compile time [emphasis added]:
If a defconstant form appears as a top level form, the compiler must
recognize that name names a constant variable. AN IMPLEMENTATION MAY
CHOOSE TO EVALUATE THE VALUE-FORM AT compile time, LOAD TIME, or both.
This means that CONSTANTP cannot portable & reliably be used to tell
whether a value is available at compile time, even if it is known to
be "constant".
Does that answer your question? [...or at least give you a place to
start Googling?]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Tim Bradshaw" <··········@tfeb.org> writes:
> Peter Seibel wrote:
> > I have vague recollection of someone (Tim Bradshaw maybe) posting
> > something about certain impls (CMUCL maybe?) not making constants
> > available at compile time leading code like the following to behave
> > badly when THING is a DEFCONSTANT'd constant:
> >
> > (defmacro foo (thing)
> > `(print
> > ,(if (constantp thing) (frob thing) `(frob ,thing))))
> >
> I suspect that CMUCL is conformant in fact, although I think it's
> clearly a quality-of-implementation issue, since having constants
> available at macro-expansion time lets optimisations happen which are
> otherwise hard (for instance: inlining of constants as HTOUT does!)
You can always encapsulate DEFCONSTANT in a:
(EVAL-WHEN (:COMPILE-TOPLEVEL ...) ...)
to be able to portably use it in a macro as above.
--
__Pascal Bourguignon__
From: Duane Rettig
Subject: Re: constantp values always available at macro expansion time?
Date:
Message-ID: <4fz3gnwwu.fsf@franz.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> "Tim Bradshaw" <··········@tfeb.org> writes:
>
> > Peter Seibel wrote:
> > > I have vague recollection of someone (Tim Bradshaw maybe) posting
> > > something about certain impls (CMUCL maybe?) not making constants
> > > available at compile time leading code like the following to behave
> > > badly when THING is a DEFCONSTANT'd constant:
> > >
> > > (defmacro foo (thing)
> > > `(print
> > > ,(if (constantp thing) (frob thing) `(frob ,thing))))
> > >
>
> > I suspect that CMUCL is conformant in fact, although I think it's
> > clearly a quality-of-implementation issue, since having constants
> > available at macro-expansion time lets optimisations happen which are
> > otherwise hard (for instance: inlining of constants as HTOUT does!)
>
> You can always encapsulate DEFCONSTANT in a:
> (EVAL-WHEN (:COMPILE-TOPLEVEL ...) ...)
> to be able to portably use it in a macro as above.
Yes, of course, that is possible, but then, if the constant has a
different value that conflicts with one already defined in the current
compiling environment, then uses of that new constant might cause
breakage in the compiling lisp. As a simple example, consider the
cross-compilation by a 32-bit lisp onto a 64-bit target: what happens
when the compiler runs into a (defconstant most-positive-fixnum ...)?
The problem from _our_ point of view (i.e. Allegro CL, which does
evaluate the constant's value at compile time) is that the CL spec
defined CONSTANTP (and note that constantp accepts an optional environment
argument) but never defined CONSTANT-VALUE function (also to receive an
optional environment argument). The major reason for this, of course,
is precisely because of the non-guarantee of the constant-value being
available at compile-time. A lesser reason would be what to do in an
inconsistent situation: should constant-value return any value if
the argument isn't really a constant (with a possible warning) or
should it call error?
At several times during my ruminations on environments, I have
considered re-exporting our excl::constant-value function from the
system package (where the other environments-access functionality
resides) and to call that the definitive way to access the constant's
value, but have stopped short because of this issue of accessibility.
The _real_ rub is that that cmucl does indeed have the capability to
access the value of the constant within the environment (using an
"info" accessor when the constant is a name in the variable space) so
it wouldn't be hurt by a definition of sys:constant-value. But it
might hurt some other implementation which does not store the value
away during compile time.
If it _had_ been so defined, then the above example would have become
trivial to define:
(defmacro foo (thing &environment env)
`(print
,(if (constantp thing env)
(frob (sys:constant-value thing env))
`(frob ,thing))))
Note that in Allegro CL it is already trivial to define (non-portably,
and with no guarantee that it will continue to work in future versions,
since excl::constant-value is not exported or documented, and thus not
supported):
(defmacro foo (thing &environment env)
`(print
,(if (constantp thing env)
(frob (excl::constant-value thing env))
`(frob ,thing))))
Of course, with our environments access module, constant-value is easy
enough to define if one can count on the value being stored - when the
argument is a symbol a simple call to sys:variable-information will
return the fact that the symbol represents a constant _and_ the actual
value. It's just that the use of this technique is itself non-portable.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Christophe Rhodes
Subject: Re: constantp values always available at macro expansion time?
Date:
Message-ID: <squ0rwovg5.fsf@cam.ac.uk>
Duane Rettig <·····@franz.com> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> You can always encapsulate DEFCONSTANT in a:
>> (EVAL-WHEN (:COMPILE-TOPLEVEL ...) ...)
>> to be able to portably use it in a macro as above.
>
> Yes, of course, that is possible, but then, if the constant has a
> different value that conflicts with one already defined in the current
> compiling environment, then uses of that new constant might cause
> breakage in the compiling lisp. As a simple example, consider the
> cross-compilation by a 32-bit lisp onto a 64-bit target: what happens
> when the compiler runs into a (defconstant most-positive-fixnum ...)?
You restructure your build arrangement such that you don't depend on
the host implementation vagaries of interpretation of the ANSI CL
requirements of DEFCONSTANT, of course.
We keep on hearing that Lisp is the perfect language in which to
construct domain-specific solutions; it so happens that a very good
language for expressing Common Lisp implementations is precisely ANSI
Common Lisp. It's a bit of a shame that more vendors don't buy into
the value of the language on which they base their advanced
offerings...
Christophe
(In case anyone is left in any doubt: behind the tongue-in-cheek of
this post is a serious point. Source code of the existence proof is
available through the usual channels. :-)
From: Duane Rettig
Subject: Re: constantp values always available at macro expansion time?
Date:
Message-ID: <4ekiz6h6x.fsf@franz.com>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Pascal Bourguignon <····@mouse-potato.com> writes:
> >
> >> You can always encapsulate DEFCONSTANT in a:
> >> (EVAL-WHEN (:COMPILE-TOPLEVEL ...) ...)
> >> to be able to portably use it in a macro as above.
> >
> > Yes, of course, that is possible, but then, if the constant has a
> > different value that conflicts with one already defined in the current
> > compiling environment, then uses of that new constant might cause
> > breakage in the compiling lisp. As a simple example, consider the
> > cross-compilation by a 32-bit lisp onto a 64-bit target: what happens
> > when the compiler runs into a (defconstant most-positive-fixnum ...)?
>
> You restructure your build arrangement such that you don't depend on
> the host implementation vagaries of interpretation of the ANSI CL
> requirements of DEFCONSTANT, of course.
In other words, you go "under the hood" to get the functionality
not otherwise available.
> We keep on hearing that Lisp is the perfect language in which to
> construct domain-specific solutions; it so happens that a very good
> language for expressing Common Lisp implementations is precisely ANSI
> Common Lisp. It's a bit of a shame that more vendors don't buy into
> the value of the language on which they base their advanced
> offerings...
>
> Christophe
>
> (In case anyone is left in any doubt: behind the tongue-in-cheek of
> this post is a serious point. Source code of the existence proof is
> available through the usual channels. :-)
Yes, well, I think the existence proof is the presence of any of the CL
implementations that exist on more than one platform each. Wouldn't
it be nice, though, if the methods for going "under the hood" were
consistent? Perhaps a MOP for environmental issues? Perhaps, like,
an environments access system?
I take your tongue-in-cheek remarks, but my ultimate (and completely
serious) goal is to make the environments access module so palatable
for any other lisp vendor that it becomes irresistable for them (you)
to use when it becomes opensource...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Christophe Rhodes
Subject: Re: constantp values always available at macro expansion time?
Date:
Message-ID: <sqactnj30n.fsf@cam.ac.uk>
Duane Rettig <·····@franz.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> You restructure your build arrangement such that you don't depend on
>> the host implementation vagaries of interpretation of the ANSI CL
>> requirements of DEFCONSTANT, of course.
>
> In other words, you go "under the hood" to get the functionality
> not otherwise available.
Only in one sense. In another, you take the guarantees offered to
you, and write your program only in terms of these guarantees. To be
crystal clear: we don't rely on any knowledge of defconstant's
interaction with environments, or any such similarly unspecified areas
of the standard.[*]
Just to put it in slightly more concrete terms, if you see
(def!constant sb!xc:most-positive-fixnum (1- (ash 1 n-fixnum-bits)))
floating around, you know that not only (after loading this file) will
the host compiler know that the target's most-positive-fixnum is
whatever it will be, but also the cross-compiler (when it starts
running) will know that most-positive-fixnum is what it will be.
DEF!CONSTANT is implemented as (more-or-less)
(defmacro def!constant (name value)
`(progn
#+running-on-the-host
(defconstant ,name ,value)
(sb!xc:defconstant ,(uncross name) ,value)))
and at no point do we rely on any under-the-hood knowledge of the
system on which we're running: only on the guarantees that are offered
to us. (I should say that this is an idealised description of what's
going on, but the basic idea is there.)
[*] modulo bugs, but there's no problem in principle.
>> (In case anyone is left in any doubt: behind the tongue-in-cheek of
>> this post is a serious point. Source code of the existence proof is
>> available through the usual channels. :-)
>
> Yes, well, I think the existence proof is the presence of any of the CL
> implementations that exist on more than one platform each.
I don't think we're talking about the same existence here, then. You
seem to be referring to the ability of one CL system to compile itself
for another platform using knowledge of how it is implemented, whereas
I'm talking about using only existing standard-guaranteed behaviour.
Am I right in our mutual incomprehension, or is it only I who have
misunderstood you? :-)
> Wouldn't it be nice, though, if the methods for going "under the
> hood" were consistent? Perhaps a MOP for environmental issues?
> Perhaps, like, an environments access system?
>
> I take your tongue-in-cheek remarks, but my ultimate (and completely
> serious) goal is to make the environments access module so palatable
> for any other lisp vendor that it becomes irresistable for them (you)
> to use when it becomes opensource...
A tightly-specified environment interaction system would be a great
boon, whether the Allegro CL implementation of it is Open Source or
not (going on the assumption here that Franz isn't about to start
patenting its APIs or something equally insane :). If the system is
open for discussion with other vendors' representatives about what is
and is not practical to support with reasonable amounts of work, then
so much the better (but an undiscussed proposal is a lot better than
no proposal at all).
Christophe
From: Duane Rettig
Subject: Re: constantp values always available at macro expansion time?
Date:
Message-ID: <4pt2j2zgz.fsf@franz.com>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Christophe Rhodes <·····@cam.ac.uk> writes:
> >
> >> You restructure your build arrangement such that you don't depend on
> >> the host implementation vagaries of interpretation of the ANSI CL
> >> requirements of DEFCONSTANT, of course.
> >
> > In other words, you go "under the hood" to get the functionality
> > not otherwise available.
>
> Only in one sense. In another, you take the guarantees offered to
> you, and write your program only in terms of these guarantees. To be
> crystal clear: we don't rely on any knowledge of defconstant's
> interaction with environments, or any such similarly unspecified areas
> of the standard.[*]
Hmm...
> Just to put it in slightly more concrete terms, if you see
> (def!constant sb!xc:most-positive-fixnum (1- (ash 1 n-fixnum-bits)))
> floating around, you know that not only (after loading this file) will
> the host compiler know that the target's most-positive-fixnum is
> whatever it will be, but also the cross-compiler (when it starts
> running) will know that most-positive-fixnum is what it will be.
> DEF!CONSTANT is implemented as (more-or-less)
> (defmacro def!constant (name value)
> `(progn
> #+running-on-the-host
> (defconstant ,name ,value)
> (sb!xc:defconstant ,(uncross name) ,value)))
==========^^^^^^
> and at no point do we rely on any under-the-hood knowledge of the
> system on which we're running: only on the guarantees that are offered
> to us. (I should say that this is an idealised description of what's
> going on, but the basic idea is there.)
The flagged line looks pretty under-the-hood to me...
And wouldn't you rather remove those pesky #+ and #- conditionalizations?
Are these conditionalizatons usable by a user? I.e. If I asked sbcl to
"cross-compile" something other than sbcl source, would it be a clean
interface, or is the cross-compilation mostly geared toward the compilation
of itself to another architecture?
> [*] modulo bugs, but there's no problem in principle.
>
> >> (In case anyone is left in any doubt: behind the tongue-in-cheek of
> >> this post is a serious point. Source code of the existence proof is
> >> available through the usual channels. :-)
> >
> > Yes, well, I think the existence proof is the presence of any of the CL
> > implementations that exist on more than one platform each.
>
> I don't think we're talking about the same existence here, then. You
> seem to be referring to the ability of one CL system to compile itself
> for another platform using knowledge of how it is implemented, whereas
> I'm talking about using only existing standard-guaranteed behaviour.
I guess it depends on what you mean by "standard". More on that later.
But I was only responding to your previous comment:
! We keep on hearing that Lisp is the perfect language in which to
! construct domain-specific solutions; it so happens that a very good
! language for expressing Common Lisp implementations is precisely ANSI
! Common Lisp. It's a bit of a shame that more vendors don't buy into
! the value of the language on which they base their advanced
! offerings...
I agree with this statement 100%; we should be using "standard"
constructs to construct our lisps, and not rely on internals.
Your very own definition of defconstant relies on internal magic,
and that's what I'm trying to empower implementations to get away
from.
> Am I right in our mutual incomprehension, or is it only I who have
> misunderstood you? :-)
I think we must be misunderstanding each other, because I think I'm
the one pushing for the possibility of CLs using a standard mechanism
to define itself.
Let me now explain what I mean by CL and standard mechanism:
<blue-sky>
Suppose CLRFI gets off the ground (I think it will) and that
the environments access system becomes one of the early CLRFIs,
complete with a reference implementation. And then suppose all
CL vendors were to negotiate the CLRFI and the reference
implementation (I have no misunderstanding that changes would
indeed be required), and then finally it became an accepted CLRFI
substandard. At that point, each lisp (even Allegro CL) could change
its expansion of defconstant from something like this:
(PROGN (DECLAIM (SPECIAL FOO))
(EVAL-WHEN (COMPILE)
(EXCL::DEFCONSTANT1 'FOO 10))
[ ... ]
(EXCL::DEFCONSTANT2 'FOO 10))
to something more like this:
(PROGN (DECLAIM (SPECIAL FOO))
(EVAL-WHEN (COMPILE)
(SYS:AUGMENT-ENVIRONMENT SYS:*COMPILE-FILE-ENVIRONMENT*
:REUSE T
:CONSTANT 'FOO
:LOCATIVE 10))
[ ... ]
(SYS:AUGMENT-ENVIRONMENT NIL
:CONSTANT 'FOO
:LOCATIVE 10))
In other words, (if and when environments access is accepted as
"standard") all defininitions could be defined mostly in terms of
these standards for those CL implemetations that accepted the standard.
</blue-sky>
Of course, we are a long way off from that point, since we are not
quite ready to release the sources (although the interface is
completely documented as it currently stands).
This whole discussion about cross-compiling might be esoteric to
those who haven't dealt with cross-compiling before, but a better
(but perhaps harder-to-find) example might be that one lisp invocation
which compiles a source-file into a fasl file intended to be loaded
into another lisp might have a constant ddefined as one value; the
source file might redefine the value of the constant, use its value
later in the file, and be done with it. So at the end of the
compilation, the currently running lisp expects the constant's original
value to still be defined in it, (which precludes the use of an
(eval-when (:compile-toplevel) ...) around the defconstant form in
the source file) but the lisp which is going to load the new
fasl file expects that when it loads the file
1. The constant is defined as the defconstant had specified
2. The compiled code after the defconstant all used this value
3. That compiled code was optimized _as_ _if_ the constant had
been part of the environment of the lisp.
I think #1 and #2 are mandatory, but #3 is optional, though I think
many CL implemetations do this. I also categorize cross-compilation
as an example of this problem - in the general case it is an issue
of the compiling lisp's environment being different than the compiled
file (as targeted to a different lisp invocation).
> > Wouldn't it be nice, though, if the methods for going "under the
> > hood" were consistent? Perhaps a MOP for environmental issues?
> > Perhaps, like, an environments access system?
> >
> > I take your tongue-in-cheek remarks, but my ultimate (and completely
> > serious) goal is to make the environments access module so palatable
> > for any other lisp vendor that it becomes irresistable for them (you)
> > to use when it becomes opensource...
>
> A tightly-specified environment interaction system would be a great
> boon, whether the Allegro CL implementation of it is Open Source or
> not
Agreed.
> (going on the assumption here that Franz isn't about to start
> patenting its APIs or something equally insane :).
If we were planning that, I certainly wouldn't be posting this here :-)
Also, we would probably be more tight-lipped about our documentation,
which is freely available in the 7.0 doc set, available on our website.
> If the system is
> open for discussion with other vendors' representatives about what is
> and is not practical to support with reasonable amounts of work, then
> so much the better (but an undiscussed proposal is a lot better than
> no proposal at all).
It might be premature - there are still mundane issues to decide that
the spec and implementations require (e.g. notably, CLOS/PCL and their
walker), and I'd not want to drag other vendors into yet) but I would
be more than happy to discuss any issues that you might have at the
interface level, or take suggestions if you want to get into those
details. Start with the docs
(http://www.franz.com/support/documentation/7.0/doc/environments.htm
Might be a good place to start) and send me some email.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Nikodemus Siivola
Subject: Re: constantp values always available at macro expansion time?
Date:
Message-ID: <cn22f8$fkqsm$1@midnight.cs.hut.fi>
Duane Rettig <·····@franz.com> wrote:
> > `(progn
> > #+running-on-the-host
> > (defconstant ,name ,value)
> > (sb!xc:defconstant ,(uncross name) ,value)))
> ==========^^^^^^
> The flagged line looks pretty under-the-hood to me...
Depends on what you mean by under-the-hood: the definition of
sb!xc:defconstant is itself portable, and doesn't depend on details
of the implementation the system is being built with. OTOH, it
certainly is under-the-hood in the sense that it's part of the SBCL
build machinery and not usable by end users.
I'm think that there is a lingering misunderstanding here: when you
say "cross-compilation" you mean (I assume) building lisp X for platform
B with lisp X on platform A, whereas Christophe refers to building lisp
X for platform B with lisp Y on platform A.
> Are these conditionalizatons usable by a user? I.e. If I asked sbcl to
> "cross-compile" something other than sbcl source, would it be a clean
> interface, or is the cross-compilation mostly geared toward the compilation
> of itself to another architecture?
Not quite. While not usable by users, the machinery is a bit more
comprehensive then that: it's geared toward compilation of itself
with any[*] ANSI compliant CL implementation to same or another
architecture.
[*] At least CMUCL, OpenMCL, and Clisp are more-or-less routinely used
to build SBCL.
Cheers,
-- Nikodemus
From: Duane Rettig
Subject: Re: constantp values always available at macro expansion time?
Date:
Message-ID: <4is8b80t0.fsf@franz.com>
Nikodemus Siivola <········@sokeri.niksula.hut.fi> writes:
> Duane Rettig <·····@franz.com> wrote:
>
> > > `(progn
> > > #+running-on-the-host
> > > (defconstant ,name ,value)
> > > (sb!xc:defconstant ,(uncross name) ,value)))
> > ==========^^^^^^
>
> > The flagged line looks pretty under-the-hood to me...
>
> Depends on what you mean by under-the-hood: the definition of
> sb!xc:defconstant is itself portable, and doesn't depend on details
> of the implementation the system is being built with. OTOH, it
> certainly is under-the-hood in the sense that it's part of the SBCL
> build machinery and not usable by end users.
Yes, this is precisely what I mean by under-the-hood. I can't,
in a vanilla copy of any lisp (except, perhaps, sbcl) type
(sb~xc:defconstant x 1) and not get a package error. My sense of
"standard" and "portable" is a situation where any "standard-compliant"
lisp would have underlying definitions of the defining macros
(including defconstant) which contained standard forms, for the most
part. Currently, there is only one standard: Ansi CL, and under this
standard, this goal is not quite possible (although the intention is
well known in the "Getalt" of the document), but my goal is to work
toward a possible CL + CLRFI "standard" which would make this goal
possible for any implementations that implemented this "standard".
> I'm think that there is a lingering misunderstanding here: when you
> say "cross-compilation" you mean (I assume) building lisp X for platform
> B with lisp X on platform A, whereas Christophe refers to building lisp
> X for platform B with lisp Y on platform A.
It doesn't matter what "cross-compilation" means here; my original post
on cross-compilation was intended to use it as an example of why one
would want defconstant to preserve one value while compiling using
another value. That's all. Any deeper that we dive into the
cross-compilation issue (that isn't directly relevant to the issue
of portable defining macros) is not something I care to pursue.
> > Are these conditionalizatons usable by a user? I.e. If I asked sbcl to
> > "cross-compile" something other than sbcl source, would it be a clean
> > interface, or is the cross-compilation mostly geared toward the compilation
> > of itself to another architecture?
>
> Not quite.
The question was rhetorical, because obviously this is true (i.e. that
it is not quite general - that it is specifically meant for
self-cross-compilation).
> While not usable by users, the machinery is a bit more
> comprehensive then that: it's geared toward compilation of itself
> with any[*] ANSI compliant CL implementation to same or another
> architecture.
>
> [*] At least CMUCL, OpenMCL, and Clisp are more-or-less routinely used
> to build SBCL.
It is a testament to sbcl's clean design that its machinery can be loaded
up into almost any compliant CL and compile itself. However, my goal
is _not_ portably compiling sbcl; it is enabling portable compilation
of _any_ project within any other, without a lot of the extra machinery
that is currently needed to separate the environments of the compiled code
from the compiling lisp.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Tim Bradshaw
Subject: Re: constantp values always available at macro expansion time?
Date:
Message-ID: <ey3actnz9n2.fsf@cley.com>
* Pascal Bourguignon wrote:
> You can always encapsulate DEFCONSTANT in a:
> (EVAL-WHEN (:COMPILE-TOPLEVEL ...) ...)
> to be able to portably use it in a macro as above.
The problem is that HTOUT doesn't control the things it is processing,
so it can't make any assumptions about them: I don't want to say `if
you want to use HTOUT, then you have to wrap all your DEFCONSTANTs in
EVAL-WHEN'.
--tim