Constants and DEFCONSTANT
Tim Bradshaw
current newsserver which seems to have special code in to deliver
articles in pessimal order, pessimal being defined as `wait until you
are about to expire an article in a thread, and then deliver the
thread in reverse order').
If I understand things, what one would like DEFCONSTANT to do is to
define a constant variable which is bound to object (of any class, not
just something that MAKE-LOAD-FORM works for) such that you always get
`the same' object, where `the same' really means EQL (and perhaps that
is the same as `similar' in the hyperspec?)
(And I, anyway, would like those objects to be mutable, if possible).
But this is hard, because of file compilation. If file A has a
DEFCONSTANT for some variable, and source files B & C refers to it,
then the compiled version of files B & C can't refer to the same
object because they don't share an address space (with each other or
file A). So you end up either having different objects perhaps, or
having references to constant variables go through the variable name
and thus do the whole looking-up-dynamic-bindings thing that you're
trying to avoid.
So I was thinking, how would Fortran do this? I think the answer is
`by fixing it up in the linker'. The unlinked object files would have
unsatisfied references in them to the constant, which would be fixed
up at link time to make a reference to its memory location. If the
constant is an immediate object you wouldn't do this, but then you
wouldn't have the problem in Lisp either.
Couldn't CL do the same thing? File compiling code that referenced a
constant would (for non-immediate constants), result in a fasl file
which had dangling references in it, which would be stitched up at
load time. This would require there to be a little table of
registered constants somewhere, but it shouldn't be hard to arrange
that, and the stitching things up at load time is just what linkers do
in any case. (Note that by `stitching up' I mean `wiring the address
into the code' and not going through the symbol value.) A naive
implementation would also cause there to be a load-order dependence
between the files that define the constant and any users of it, but a
more sophisticated implementation could cause code that would create
and register the constant if it did not exist to be dumped with each
client file (probably optionally, otherwise files that referred to
many constants would get big).
But perhaps this is no good because it won't allow you to optimise things like:
(defconstant foo '(a b))
(defun blib ()
(cdr foo))
(Can other languages deal with this kind of case, presumably by
running code at link time?). You can optimise away the common numeric
cases though.
Or maybe I'm just confused again.
--tim
Mike McDonald
Tim Bradshaw <t...@tfeb.org> writes:
> I think I understand the defconstant stuff a bit now (not helped by my
> current newsserver which seems to have special code in to deliver
> articles in pessimal order, pessimal being defined as `wait until you
> are about to expire an article in a thread, and then deliver the
> thread in reverse order').
>
> If I understand things, what one would like DEFCONSTANT to do is to
> define a constant variable which is bound to object (of any class, not
> just something that MAKE-LOAD-FORM works for) such that you always get
> `the same' object, where `the same' really means EQL (and perhaps that
> is the same as `similar' in the hyperspec?)
That's what I would like and I would guess most non language lawyers would
expect. Most of the code that I've seen that uses defconstant expects that
anyway.
> (And I, anyway, would like those objects to be mutable, if possible).
I would too but that's a separate issue. It'd be nice if whether it's
immutable or not was spelled out a little clearer.
> But this is hard, because of file compilation. If file A has a
> DEFCONSTANT for some variable, and source files B & C refers to it,
> then the compiled version of files B & C can't refer to the same
> object because they don't share an address space (with each other or
> file A). So you end up either having different objects perhaps, or
> having references to constant variables go through the variable name
> and thus do the whole looking-up-dynamic-bindings thing that you're
> trying to avoid.
>
> So I was thinking, how would Fortran do this? I think the answer is
> `by fixing it up in the linker'.
> Couldn't CL do the same thing?
I don't see any obvious reason it couldn't. But since the spec doesn't
require it, you can't currently count on it. Maybe it could be fixed in the
next revision of the ANSI spec.
> But perhaps this is no good because it won't allow you to optimise things like:
>
> (defconstant foo '(a b))
>
> (defun blib ()
> (cdr foo))
There's an old cliche about getting it right first, then worry about
optimizations.
Mike McDonald
mik...@mikemac.com
Howard R. Stearns
> ...
Your analysis of what one might want defconstant to do makes sense to
me.
> But perhaps this is no good because it won't allow you to optimise things like:
>
> (defconstant foo '(a b))
>
> (defun blib ()
> (cdr foo))
I like to view this kind of optimization, which I refer to as partial
evaluation, as an issue of declaring how rigid a binding should be, and
that this is orthogonal to the other issues you describe.
For example, if you tell a compiler that the binding for CDR is
inlinable at compile time (which, in the case of cl:cdr, of course, it
already knows), AND if you tell it that the binding of FOO is inlinable
at compile time (which presumably would be the default for things
defined by DEFCONSTANT, then BLIB can be compiled to just return '(b).
Will (eq (blib) (cdr foo)) in all combinations of what was compiled
where? Perhaps not.
If you think that (eq '(a b) '(a b)) should be true in file-compiled
code, then you probably want to use a Lisp which coalesces literals in
the file compiler, in which case if FOO and BLIB are compiled in the
same file, then (eq (blib) (cdr foo)) will be true. But this has to do
with coalescing and nothing to do with the semantics of defconstant.
If your compiler doesn't do this, or if FOO and BLIB are in different
files, then maybe you want to declare that FOO cannot be inlined at
compile time, but at load time. In this case, perhaps (cdr foo) gets
transformed by the compiler into something like (load-time-value (cdr
foo)) -- if your compiler supports this sort of thing.
My point is that the semantics of these kinds of optimizations ought to
be separate issue (and separately controllable) from the issue of what
defconstant should be doing.
In my opinion, an implementation of defconstant should:
1. At compile time, and if the implementation so chooses, evaluate the
form and make the value available during compilation, providing some
suitable defaults for whatever implmentation-specific declaration
machinery is available, regarding the stability of the binding.
2. Arrange things such that at after load time:
- the value is made available through the symbol-value of the symbol
(as for
all global "variables"
- the value is available for any code which has been compiled to
reference it
(thought whatever other slick mechanism that the implementation
provides).
- Rebinding is forbidden.
Maybe there's bugs here, but the really important thing is that
regardless of whether the spec does or does not now say anything about
EQL'ness for 1 and 2, it would be possible for us to CREATE a definition
which does say something about it, one way or the other, and that this
issue does not necesarrilly cut off issues about controlling/allowing
optimizations, which could be decided/documented separately.
Steven M. Haflich
in any case. (Note that by `stitching up' I mean `wiring the address
into the code' and not going through the symbol value.)
As I sketched in my message yesterday (which may be hard to
locate, since you started a new thread) stitching things up
is one of the capabilities of LOAD-TIME-VALUE.
Tim Bradshaw
[I wrote]
> > But perhaps this is no good because it won't allow you to optimise things like:
> >
> > (defconstant foo '(a b))
> >
> > (defun blib ()
> > (cdr foo))
>
> There's an old cliche about getting it right first, then worry about
> optimizations.
>
Yes, and Lisp wins big time here! Using the `fix it up at load time'
approach, you can obviously have the dangling constant reference
essentially be a *function* of the constant which will compute the
actual thing you want once, at load time (`link time'). The compiler
just has to work out the largest expression which depends on the
constant, convert it to a function (since it depends only on the
constant, there can be no variable capture, so it just amounts to
wrapping it in lambda, and arrange for the loader to call that
function, which will return the thing to splice in.
--tim
Kent M Pitman
> > (defconstant foo '(a b))
> > (defun blib () (cdr foo))
>
> Will (eq (blib) (cdr foo)) in all combinations of what was compiled
> where? Perhaps not.
Right. This is an important case that shows that the internals of the
datastructure need to retain their identity as well in order for the
"magic" to be invisible. Making this work is tough.
> ... perhaps (cdr foo) gets
> transformed by the compiler into something like (load-time-value (cdr
> foo)) -- if your compiler supports this sort of thing.
This sounds scary and hard. Maybe someone who does a lot of compiler work
can convince me otherwise, but this is the kind of thing that pushes the
edge of what I see compilers being able to straightforwardly do, and so is
beyond the point where I'm prepared to insist the language should do all
the work itself.
> In my opinion, an implementation of defconstant should:
>
> 1. At compile time, and if the implementation so chooses, evaluate the
> form and make the value available during compilation, providing some
> suitable defaults for whatever implmentation-specific declaration
> machinery is available, regarding the stability of the binding.
I'm not sure I totally understand what you said here about stability,
but nothing that I did understand sounded wrong. :-)
> 2. Arrange things such that at after load time:
> - the value is made available through the symbol-value of the symbol
> (as for
> all global "variables"
> - the value is available for any code which has been compiled to
> reference it
> (thought whatever other slick mechanism that the implementation
> provides).
> - Rebinding is forbidden.
These all sound ok. Mike is asking for more than this, though, right?
> Maybe there's bugs here, but the really important thing is that
> regardless of whether the spec does or does not now say anything about
> EQL'ness for 1 and 2, it would be possible for us to CREATE a definition
> which does say something about it, one way or the other, and that this
> issue does not necesarrilly cut off issues about controlling/allowing
> optimizations, which could be decided/documented separately.
I certainly agree the spec could be more clear. To the extent that the
behavior isn't nailed down firmly, I blame J13 collectively. To the extent
that it's poorly explained what the present defaults are, I'll take the
blame for that. I knew it was a mess and probably should have said so
more clearly somewhere. To some degree, I raised it in discussions but
probably not pointedly enough. We were busy folks putting this thing together
and there never seemed to be time enough to handle every last loose end...
Mike McDonald
Right! If compile-file was required to use (load-time-value +FOO+) instead
of using a "similar" value, then EQLness of "constant variables" would be
preserved. This is what I want!
Mike McDonald
mik...@mikemac.com
Kent M Pitman
This may be what you want, but it just pushes the bubble under the carpet
to a different place. Howard's example illustrates the full complexity of
the problem and the reason this is not so simply done: component structures.
If you inline a constant (another thing defconstant is for) and you inline
operations on the constant (another thing defconstant is for), then you
get in a place where the identity of the subparts isn't tagged and the
bookkeeping is hard. It is not nearly as easy to keep track of the fact,
as he cited that in
+---- file1.lisp ---
| (defconstant +abc+ '(A . #1=(B C)))
+-------------------
+---- file2.lisp ---
| (defun bc (x) (cdr +abc+))
+-------------------
If CDR is inlined and aggressively optimized, then this is the same as
+---- file2.lisp ---
| (defun bc (x) #1#)
+-------------------
but the question is what will make the compiler notice (since we're compiling
a separate file than file1.lisp) what will make the compiler know that this
constant came from +abc+ in order to assure it's unique. It's not like
it walks around with a tag on it saying "I am the cdr of +abc+'s list." so
the compiler might not reconsolidate it.
To make this work, unless I'm not seeing something, you have to presupose
that either the defconstant registers not only the object but all of its
subforms and you have to assume that at minimum coalescing is done for all
expressions that are subforms of declared constants, or (probably easier)
just for all expressions. But the language doesn't require coalescing,
it only permits it. And certainly requiring it would create a burden on
interpreters, virtually making them impossible to write. It would also make
a predictably strong division between non-file-compiled and file-compiled
things where the compiler was reliably providing a service that the
in-core compiler was not, and that in turn would mean that people would
write more fragile code like we did in Maclisp where people relied
on the file compiler being called and code randomly broke if it wasn't
written that way. In the present scheme you can get what you want with
a bit more work, and get it reliably, but you don't disempower the existing
language features.
Mike McDonald
Kent M Pitman <pit...@world.std.com> writes:
> mik...@mikemac.com (Mike McDonald) writes:
>
>> In article <36F99FFB...@franz.com>,
>> "Steven M. Haflich" <s...@franz.com> writes:
>> > and the stitching things up at load time is just what linkers do
>> > in any case. (Note that by `stitching up' I mean `wiring the address
>> > into the code' and not going through the symbol value.)
>> >
>> > As I sketched in my message yesterday (which may be hard to
>> > locate, since you started a new thread) stitching things up
>> > is one of the capabilities of LOAD-TIME-VALUE.
>>
>> Right! If compile-file was required to use (load-time-value +FOO+) instead
>> of using a "similar" value, then EQLness of "constant variables" would be
>> preserved. This is what I want!
>
> This may be what you want, but it just pushes the bubble under the carpet
> to a different place. Howard's example illustrates the full complexity of
> the problem and the reason this is not so simply done: component structures.
Howard's example is easy to handle. What compile-file has t do is transform
(defun bc ()
(cdr +abc+))
into
(eval-when (:load-toplevel)
(let ((abc-value (load-time-value +abc+)))
; check to see if the optimization conditions still hold
(if (not (consp abc-value))
(error "The +ABC+ changed it's value incompatibly with the compile time
value. A CONS was expected."))
(patch-address XXXX (cdr abc-value))
))
(defun bc ()
(return-contents-of-address XXXX))
Then (eq (cdr +abc+) (bc)) will be T.
> If you inline a constant (another thing defconstant is for) and you inline
> operations on the constant (another thing defconstant is for), then you
> get in a place where the identity of the subparts isn't tagged and the
> bookkeeping is hard. It is not nearly as easy to keep track of the fact,
> as he cited that in
>
> +---- file1.lisp ---
> | (defconstant +abc+ '(A . #1=(B C)))
> +-------------------
>
> +---- file2.lisp ---
> | (defun bc (x) (cdr +abc+))
> +-------------------
>
> If CDR is inlined and aggressively optimized, then this is the same as
>
> +---- file2.lisp ---
> | (defun bc (x) #1#)
> +-------------------
Nope, it could be
(defun bc () (something-similar-to #1#))
instead.
Mike McDonald
mik...@mikemac.com
Christopher R. Barry
> But perhaps this is no good because it won't allow you to optimise things like:
>
> (defconstant foo '(a b))
>
> (defun blib ()
> (cdr foo))
I'd do
(defun blib ()
'#.(cdr foo))
I like to compute stuff at read time when DEFCONSTANT is involved.
Christopher
Vassil Nikolov
Sometimes this works; but not _always_, for the simple reason that
read time is earlier than compile time which is the time when
constants are expanded at the earliest.
Vassil Nikolov <vnik...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Pekka P. Pirinen
> If you inline a constant (another thing defconstant is for) and you
> inline operations on the constant (another thing defconstant is
> for), then you get in a place where the identity of the subparts
> isn't tagged and the bookkeeping is hard.
Then don't do that. Surely if DEFCONSTANT is supposed to preserve
identity (and I must say it was a schock to me to hear that some
implementors thought it needn't), then the compiler is in error if
it constant-folds (I guess that's what you mean by "inlines an
operation") in a way that fails to preserve that identity.
> It is not nearly as easy to keep track of the fact,
> as he cited that in
>
> +---- file1.lisp ---
> | (defconstant +abc+ '(A . #1=(B C)))
>
> +---- file2.lisp ---
> | (defun bc (x) (cdr +abc+))
>
> If CDR is inlined and aggressively optimized, then this is the same as
>
> +---- file2.lisp ---
> | (defun bc (x) #1#)
>
> but the question is what will make the compiler notice (since we're compiling
> a separate file than file1.lisp) what will make the compiler know that this
> constant came from +abc+ in order to assure it's unique.
That's not hard: The compiler _doesn't_ constant-fold over references to
constant variables whose values are data structures. I know LispWorks
works like that. Steven M. Haflich indicated (in the "`fast' global
variables" thread) that ACL "only dereferences constants like numbers
and symbols". Is there any implementation except MCL who don't get it
right?
In any case, implementing constant identity is exactly the kind of
thing that should be left to compiler writers, the language should
just offer a way to declare a constant. I must say that if it was the
intention of the committee to let DEFCONSTANT break a basic language
feature like that, the standard should have included a clear warning.
--
Pekka P. Pirinen Harlequin Group plc, Cambridge, UK
"If you don't want to be replaced by a machine, don't act like one."
from _Ideas and Information_ by Arno Penzias
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
> > If you inline a constant (another thing defconstant is for) and you
> > inline operations on the constant (another thing defconstant is
> > for), then you get in a place where the identity of the subparts
> > isn't tagged and the bookkeeping is hard.
>
> Then don't do that. Surely if DEFCONSTANT is supposed to preserve
> identity (and I must say it was a schock to me to hear that some
> implementors thought it needn't), then the compiler is in error if
> it constant-folds (I guess that's what you mean by "inlines an
> operation") in a way that fails to preserve that identity.
No, the problem is you don't know what the compiler will inline, so you
can't know what to "not do".
Further, a useful property of programs is that if you attach a name
to something, it doesn't change its semantics. You're basically saying
in this case that it does. I think that's wrong.
I'm not concerned with the use of Lisp as an implementation language for
getting something done. Lisp is not about that. If I wanted that,
I'd use C. Lisp is about allowing me to express things in terms of my
high-level intent by saying things that I want clearly, not obliquely.
One of its strengths is that it allows you to freely use anonymous things.
If shifting between named and unnamed things starts to have mysticism
associated with it, that kills that property of the language.
> That's not hard: The compiler _doesn't_ constant-fold over references to
> constant variables whose values are data structures.
This may be a truth about some compiler (or many) but is not a truth
about Lisp.
> I know LispWorks
> works like that. Steven M. Haflich indicated (in the "`fast' global
> variables" thread) that ACL "only dereferences constants like numbers
> and symbols". Is there any implementation except MCL who don't get it
> right?
Defining that 60 compilers do it this way would be meaningless unless
you can convince me that there is a reason to do it this way. I don't
see the conceptual basis for saying it has to be done this way.
> In any case, implementing constant identity is exactly the kind of
> thing that should be left to compiler writers, the language should
> just offer a way to declare a constant. I must say that if it was the
> intention of the committee to let DEFCONSTANT break a basic language
> feature like that, the standard should have included a clear warning.
I'm missing what language feature you're saying DEFCONSTANT breaks.
Marco Antoniotti
Kent M Pitman <pit...@world.std.com> writes:
> I'm not concerned with the use of Lisp as an implementation language for
> getting something done. Lisp is not about that. If I wanted that,
> I'd use C.
Do *you* mean that *you* never got anything done using Lisp? :)
(sorry, couldn't resist :) )
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > I'm not concerned with the use of Lisp as an implementation language for
> > getting something done. Lisp is not about that. If I wanted that,
> > I'd use C.
>
> Do *you* mean that *you* never got anything done using Lisp? :)
> (sorry, couldn't resist :) )
You're not the only person to catch on this, so I'll reply with some
seriousness.
No, I use Lisp for implementation of interesting things all the time.
But for many things (not all), the implementation could be done in any
language... but the "expression" could not.
Lisp is about rising above implementation to saying something of lasting
value.
Chuck Fry
Kent M Pitman <pit...@world.std.com> wrote:
>I'm not concerned with the use of Lisp as an implementation language for
>getting something done. Lisp is not about that. If I wanted that,
>high-level intent by saying things that I want clearly, not obliquely.
Kent, I must disagree with you on this. I *am* concerned with the use
of Lisp as an implementation language, precisely *because* it allows me
to express things in terms of my high-level intent.
Modern Common Lisp compilers allow me to tune the critical parts of my
code to within a few percent of C code, but without the pain of using a
fragile, brittle quasi-portable assembly language.
Back to DEFCONSTANT: Is there a consensus that something about
DEFCONSTANT is counter-intuitive? With the revival of X3J13, now might
be the time to do something about that.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
chu...@chucko.com (text only please) chuc...@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
Mike McDonald
chu...@best.com (Chuck Fry) writes:
> Back to DEFCONSTANT: Is there a consensus that something about
> DEFCONSTANT is counter-intuitive? With the revival of X3J13, now might
> be the time to do something about that.
>
> -- Chuck
I can only speak for myself but I find MCL's legal but perverse
interpretation of "same" to mean "similar" extremely counter-intuitive. And
based upon all of the code where I see other people checking DEFCONSTANT
symbols with EQ, I'd guess I'm not the only one.
Mike McDonald
mik...@mikemac.com
Sunil Mishra
> I can only speak for myself but I find MCL's legal but perverse
> interpretation of "same" to mean "similar" extremely counter-intuitive. And
> based upon all of the code where I see other people checking DEFCONSTANT
> symbols with EQ, I'd guess I'm not the only one.
For myself I would replace counter-intuitive with unexpected. I can see how
and why they might have done it, and I think it makes sense. The existence
of load-time-value (and #.) solve most of the problems that I would have
had with constants. On the other hand, the spec doesn't make this pitfall
appropriately obvious, and something should certainly be done about that.
Sunil
Vassil Nikolov
chu...@best.com (Chuck Fry) wrote:
(...)
> Back to DEFCONSTANT: Is there a consensus that something about
> DEFCONSTANT is counter-intuitive? With the revival of X3J13, now might
> be the time to do something about that.
I think it's pretty clear that IWBN to do something about it. To sum
up, in the very least the programmer should be given control over
the inlining of constants, similar to what is there for functions.
Another thing that might be useful would be control over the
mutability of the object that is the value of a constant (similar
to what is there for LOAD-TIME-VALUE).
Kent M Pitman
> In article <7dr23c$2re$1...@shell5.ba.best.com>,
> chu...@best.com (Chuck Fry) wrote:
> (...)
> > Back to DEFCONSTANT: Is there a consensus that something about
> > DEFCONSTANT is counter-intuitive? With the revival of X3J13, now might
> > be the time to do something about that.
>
> I think it's pretty clear that IWBN to do something about it.
FWIW, it's not clear to me.
There might be a market for something else, but I don't see a problem
with DEFCONSTANT as it stands and is implemented.
I'll say it again: a "constant" is an abstract, not an object with
identity. It can't be an object with identity because it lives in two
different address spaces: the pre-compile-file-compiler address space
and the loaded addresss space. It's like "justice" or "pi", not like
a particular pebble on a particular beach--it's something you
recognize not by its object-pointer but by its description and use.
A "literal" in code is the same. It has identity only to the extent that
you arrange for it, and the reason coalescing is allowed isn't that
object identity isn't important but that any object which can be named
a compile time can't also live at runtime. There is no meaning to that
other than similarity.
Within the same address space (that is, speaking about COMPILE rather
than COMPILE-FILE) object identity is not and should not be violated
because it's not the act of compilation that is the problem--it's the
act of externalization and internalization, and that requires registration.
DEFCONSTANT has no problem with in-core compilation because that has no
way to and no reason to shift object identity. DEFCONSTANT has no problem
with out-of-core compilation because there is no "reasonable expectation
of identity" in a place where there are two address spaces involved other
than those identities which are arranged for. Therefore, IMO, DEFCONSTANT
has no problem period.
If you want to say there is a market for a registration thing, you are
welcome to fill it with an operator and to lobby for its standardization
but I will oppose it if it has the property described earlier, which
is that the object's "outer identity" is registered but the "inner identity"
is not. IMO, if I have identity, then my kidneys have identity, and you
can't change one without the other. To say that if I want the same
kidneys in two different environment, I have to register their name as well
is nonsensical to me. It's fine for engineers to use this kind of
practical accomodation to their cost/benefit trade-off, but it's not fine
for languages or language designers to make such short-sighted trades.
> To sum
> up, in the very least the programmer should be given control over
> the inlining of constants, similar to what is there for functions.
The programmer HAS control. LOAD-TIME-VALUE gives you the choice not
to do inlining. QUOTE gives you the ability to do inlining. There is
no such concept as "in between" (that I have seen articulated in a way
that is not intimately tied up with a particular processing mode and set
of tools).
> Another thing that might be useful would be control over the
> mutability of the object that is the value of a constant (similar
> to what is there for LOAD-TIME-VALUE).
I don't know what this is about. LOAD-TIME-VALUE seems entirely
powerful enough.
(Is this something I missed in your earlier table? It suffices to say
I should go back and look at a particular entry in that table if
that's all that's going on here. I don't have it handy, but I could
go look it up again if you thought it would help. It seemed to me
when I glanced at it earlier that each of the things in that table
were present or writable in user code.)
Fernando D. Mato Mira
Kent M Pitman wrote:
> Lisp is about rising above implementation to saying something of lasting
> value.
After several years of 6 days a week, 14 hours a day development
and 200K of C++ code in 3DJam, it's crumbling under its own weight
and all I want is throw away that code and rewrite it in Lisp.
That would never happen in Lisp. Talk about diamonds.
When you write in Lisp, _that_ is forever.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
Vassil Nikolov
I am aware that this has become rather long but please bear with me.
In article <sfwpv5q...@world.std.com>,
Kent M Pitman <pit...@world.std.com> wrote:
> Vassil Nikolov <vnik...@poboxes.com> writes:
>
> > In article <7dr23c$2re$1...@shell5.ba.best.com>,
> > chu...@best.com (Chuck Fry) wrote:
> > (...)
> > > Back to DEFCONSTANT: Is there a consensus that something about
> > > DEFCONSTANT is counter-intuitive? With the revival of X3J13, now might
> > > be the time to do something about that.
> >
> > I think it's pretty clear that IWBN to do something about it.
>
> FWIW, it's not clear to me.
>
> There might be a market for something else, but I don't see a problem
> with DEFCONSTANT as it stands and is implemented.
My reason to write that was not that there was a problem with DEFCONSTANT
as it is defined in ANSI Common Lisp (I, too, don't see a problem with
that). The reason was that people want (perhaps even need...)
something else sometimes, and moreover it is apparently easy to
incorrectly believe that DEFCONSTANT provides that something else.
(So I am not calling for changes to DEFCONSTANT but for making
its exact functionality a little more explicit perhaps, and
augmenting the language with some new defining forms and/or some new
declarations.)
I called that something else a constant reference (I don't insist that
this is the best terminological choice). I am not quite sure if it
is fully implementable by the user. By `fully implementable' I mean
that a variable that is a constant reference must not be bindable,
and I am not sure that my solution which does DEFCONSTANT of the
same symbol that is defined as a symbol macro is quite legal (I
refer here to my previous posting). And in any case implementing
a constant reference by a closure may mean some performance loss.
(Of course, there might be a better way to implement a constant
reference that I haven't thought of.)
A constant reference is (at least informally) like a notinline
constant variable. The object that is its value may or may not
be mutable, however.
With DEFCONSTANT, the value must be available no later than compile
time. With a constant reference, I see no reason why it shouldn't
be possible to supply the value even as late as run time. But even
if I am wrong, and the value must be made available earlier, then
perhaps programmer control over mutability can be done via the
second argument of LOAD-TIME-VALUE (as someone pointed out some
time ago).
> I'll say it again: a "constant" is an abstract, not an object with
> identity. It can't be an object with identity because it lives in two
> different address spaces: the pre-compile-file-compiler address space
> and the loaded addresss space. It's like "justice" or "pi", not like
> a particular pebble on a particular beach--it's something you
> recognize not by its object-pointer but by its description and use.
Once again, could it be that `constant' and `constant reference' are
sometimes confused, and this is the source of discontent about
DEFCONSTANT?
To me, the notion of a constant reference makes sense and is distinct
from the notion of a constant, but I am not absolutely sure I am not
missing something.
> A "literal" in code is the same. It has identity only to the extent that
> you arrange for it, and the reason coalescing is allowed isn't that
> object identity isn't important but that any object which can be named
> a compile time can't also live at runtime. There is no meaning to that
> other than similarity.
And a constant reference is definitely not the same as a literal object.
(...)
> Therefore, IMO, DEFCONSTANT
> has no problem period.
Indeed. IMO the problem is with expectations, arising from real or
perceived needs, that are directed at DEFCONSTANT and that need to
be `redirected.' (This sounds like social engineering... Big
Brother is watching your constants!)
> If you want to say there is a market for a registration thing, you are
> welcome to fill it with an operator and to lobby for its standardization
> but I will oppose it if it has the property described earlier, which
> is that the object's "outer identity" is registered but the "inner identity"
> is not. IMO, if I have identity, then my kidneys have identity, and you
> can't change one without the other. To say that if I want the same
> kidneys in two different environment, I have to register their name as well
> is nonsensical to me. It's fine for engineers to use this kind of
> practical accomodation to their cost/benefit trade-off, but it's not fine
> for languages or language designers to make such short-sighted trades.
I must honestly admit that I don't quite get the point here.
Does this mean that outer identity is the reference and inner identity
is the value?
(If so, I don't quite get the kidney example as I see a part-of, not
a reference-value, relationship between a human and the human's kidneys,
but I guess this is not very important.)
What is registration? Is e.g. interning a specific case of registration?
Can registration refer also to references, e.g. to what a linker does
in order to resolve references, i.e. when references become values
themselves?
`The act of externalization and internalization, and that requires
registration'---this means that to preserve eqlness of the value across
externalisation and subsequent internalisation, one needs some
registration mechanism?
I can see 4 different scenarios of interplay between inner and outer
identity (in the sense I understand) in which EQL identity can be
preserved or lost for different reasons.
For the examples,
(defun make-thing ()
"Return an uninterned object---a fresh vector of bignums."
(make-array 17 :initial-value (1+ most-positive-fixnum)))
(1) DEFCONSTANT where the value is not interned in any way, e.g.
(defconstant =foo= (make-thing) "some object")
The value returned by another evaluation of the same form that
initialises =FOO= would not be EQL to =FOO= and (EQL =FOO= =FOO=)
may or may not be true depending on whether =FOO= is inlined.
No registration of any kind here.
This is similar to
(define-symbol-macro =foo-as-symbol-macro= (make-thing))
*but* (MAKE-THING) is evaluated only once for _all_ files that
refer to =FOO=, and evaluation may take place as early as compile
time: with =FOO-AS-SYMBOL-MACRO=, evaluation will take place at
run time, and with
(define-symbol-macro =foo-ltv= (load-time-value (make-thing)))
evaluation will take place at load time (and not once for _all_
files but once for _each_ file).
(2) DEFCONSTANT where the value is interned in some way, e.g.
(defconstant =bar= 'baz "an interned symbol")
EQL identity is guaranteed not by virtue of what DEFCONSTANT does
but by virtue of the properties of the value given to the constant
variable: (EQL =BAR= =BAR=) and (EQL =BAR= 'BAZ) will both be true
because this is how interned symbols work, and it doesn't matter
if =BAR= is inlined or not. The reference is not registered,
the value is.
(By the way, this reminds me of the concept of otherwise accessible
parts.)
(3) A constant reference where the value is not interned in any way:
EQL identity is guaranteed only via the same reference but not between
the constant reference and the value produced by another evaluation
of the initialisation form. The reference is registered (terminology?),
the value isn't.
File 0:
(define-constant-reference +quux+ (make-thing) "something else")
(defconstant =foo= (make-thing) "something") ;just for comparison
File 1:
(defun quux1 () +quux+)
(defun foo1 () =foo=)
File 2:
(defun quux2 () +quux+)
(defun foo2 () =foo=)
After compiling and loading everything:
(eql (quux1) (quux2)) => t
(eql (foo1) (foo2)) => unspecified
(eql +quux+ (make-thing)) => nil
(eql =foo= (make-thing)) => nil
(4) A constant reference where the value is interned: EQL identity
is guaranteed in all cases, i.e. one can obtain the same (EQL) object
not only by another occurrence of the same constant reference but
also by another evaluation of the initialisation form (or its
equivalent, in the same sense that 'BAZ and (INTERN "BAZ") are
equivalent (ceteris paribus: same package, same read case)).
> > To sum
> > up, in the very least the programmer should be given control over
> > the inlining of constants, similar to what is there for functions.
>
> The programmer HAS control. LOAD-TIME-VALUE gives you the choice not
> to do inlining. QUOTE gives you the ability to do inlining. There is
> no such concept as "in between" (that I have seen articulated in a way
> that is not intimately tied up with a particular processing mode and set
> of tools).
Sorry, that was a mistake I made.
I wrote just `constants' where I should have written `constant
variables.' Correct me if I am wrong, but inlining may happen no matter
if the initialisation form in DEFCONSTANT is QUOTE or LOAD-TIME-VALUE.
Or should the compiler care how the value of a constant variable was
produced when it decides to inline it?
(By the way, the description of LOAD-TIME-VALUE says, `the result
of this evaluation then being treated as a literal object at run time'
(referring to the evaluation as arranged by the file compiler). Maybe
the words `literal object' are not fully appropriate here as this
form may produce, depending on circumstances, a modifiable object.
Would it have been better to say `immediate object'?)
> > Another thing that might be useful would be control over the
> > mutability of the object that is the value of a constant (similar
> > to what is there for LOAD-TIME-VALUE).
>
> I don't know what this is about. LOAD-TIME-VALUE seems entirely
> powerful enough.
Once again, please read `constant variable' for `constant' in my
sentence. A constant variable is always immutable. (There is
no `read-only-p' parameter to DEFCONSTANT.)
> (Is this something I missed in your earlier table? It suffices to say
> I should go back and look at a particular entry in that table if
> that's all that's going on here. I don't have it handy, but I could
> go look it up again if you thought it would help. It seemed to me
> when I glanced at it earlier that each of the things in that table
> were present or writable in user code.)
I can see now the problem is not with that table not being comprehensive
but with the need to clarify the concepts before or alongside with
providing the table.
And as I wrote above, I am not quite satisfied that DEFINE-xxx-REFERENCE
are adequately writable in user code because I am concerned about the
legality of
(progn
(define-symbol-macro foo ...) ;use FOO as if it is a variable
(defconstant foo ...)) ;but make it unbindable
I see no reason why it shouldn't be illegal but I don't have that
`warm, fuzzy feeling' (CLtL2, 11.9, p. 284, near bottom). My worry
comes from the fact that the name of a global special variable
cannot be used as a symbol macro. Constant variables are not global
special variables but still...
(And `adequately' here also means access in O(1); implementing
somehow a constant reference on top of a `private' global variable
does not ensure that because of the possibility of deep binding.)
Thanks for reading up to here, and for any further remarks,
Vassil.
Erik Naggum
| Modern Common Lisp compilers allow me to tune the critical parts of my
| code to within a few percent of C code, but without the pain of using a
| fragile, brittle quasi-portable assembly language.
just for the heck of it: I have tuned a _very_ CPU-heavy function I wrote
in Common Lisp over a year ago so it went from the unsatisfactory 623 µs
per call to the very pleasant 4.7 µs per call.
the strictly equivalent C function that people are entirely _satisfied_
with, performance-wise, takes 92 µs per call. very frequently, I find
that Common Lisp allows me to experiment with algorithms so much faster
than I can in C and the like, so I can change methodology and approach as
fast as they can do another optimization attempt. this means that a good
Common Lisp programmer can find the optimal algorithm _and_ the optimal
implementation in less time than the C programmer can find the optimal
implementation.
the C mind-set is that C is fast. this is even less true than their idea
that CL is slow. writing really fast C code is _incredibly_ hard, and
you might as well write it in assembly after you have seen what the
compiler is doing to the overall code. I have squeezed the last drop of
blood out of many a CPU in my time, but never has it been easier to do it
than with Allegro CL with its instruction-level profiler, hackable LAP
code (thanks, Duane!), and code transformation with compiler macros (a
standard CL facility). this stuff just isn't available to C programmers.
if you can't outperform C in CL, you're too good at C.
#:Erik
Barry Margolin
Vassil Nikolov <vnik...@poboxes.com> wrote:
>A constant reference is (at least informally) like a notinline
>constant variable. The object that is its value may or may not
>be mutable, however.
I think what you're looking for is a read-only variable, i.e. the only
thing special about it is that it may not be used as the target of an
assignment.
Unfortunately, CL doesn't provide this as a feature. DEFCONSTANT makes the
variable read-only, but it also allows inline substition.
However, if the value assigned with DEFCONSTANT is not something that can
be determined at compile time, you should get what you want. E.g.
(defun my-list (&rest args)
(apply #'list args))
(defconstant +foo+ (my-list 1 2 3))
should be guaranteed to bind +FOO+ to a mutable list (1 2 3). Since
MY-LIST isn't proclaimed INLINE, the compiler may not open-code the call.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Vassil Nikolov
Barry Margolin <bar...@bbnplanet.com> wrote:
(...)
> However, if the value assigned with DEFCONSTANT is not something that can
> be determined at compile time, you should get what you want. E.g.
>
> (defun my-list (&rest args)
> (apply #'list args))
>
> (defconstant +foo+ (my-list 1 2 3))
>
> should be guaranteed to bind +FOO+ to a mutable list (1 2 3). Since
> MY-LIST isn't proclaimed INLINE, the compiler may not open-code the call.
I don't know if this might be useful behaviour, but this is not how
DEFCONSTANT is defined to work. Portable programs must make the value
available at compile time as it is left to the discretion of the
implementation whether the initialisation value supplied to DEFCONSTANT
will be evaluated at compile time or at load time.
Besides, it doesn't matter if the initialisation value is provided by
an inline call or not. The point of this thread, as far as I see it,
is whether the value of the constant variable is inlined or not wherever
there is a reference to the constant variable.
(As an aside, for the sake of nit-picking, the compiler may not open-code
a call when a function is proclaimed NOTINLINE, not when it isn't
proclaimed INLINE. Of course, the compiler is not likely to open-code
a call when a function isn't proclaimed (or declared) INLINE.)
Duane Rettig
> (defun my-list (&rest args)
> (apply #'list args))
>
> (defconstant +foo+ (my-list 1 2 3))
>
> should be guaranteed to bind +FOO+ to a mutable list (1 2 3). Since
> MY-LIST isn't proclaimed INLINE, the compiler may not open-code the call.
A minor nit: Although the above is probably very safe (i.e. portable)
code, I disagree that the compiler is required not to open-code my-list.
On one hand, it would very space inefficient for an implementation
to provide inlining for user-defined functions that are not declaimed
as inline (unless it was doing some sort of block-compilation). But,
OTOH, I don't know of anything in the spec that prohibits some
overzealous implementation from doing so.
However, if my-list had been declaimed notinline, then the compiler
is definitely constrained by the spec from open-coding it, because the
notinline declaration/declamation is one of only 4 delaration specifiers
(besides declaration, (greater) safety, and special) that the compiler
cannot ignore.
Thus, to make this code completely portable, you could place a
(declaim (notinline mylist))
before the defun.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Kent M Pitman
> > [...kidneys...]
> I must honestly admit that I don't quite get the point here.
As with my equality paper, it is an intentional issue just how far down
identity goes. In a cons, identity is one cons deep. In a list, it's
one backbone deep. In an alist, it's two-ply deep.
When you write a user-defined datatype, the compiler can't just be free to
lose the identity of the sub-parts becuase it doesn't understand the
interrelation. If a compiler dumped me out into a fasl file and then read
me back in, it would not suffice to just conjure two new kidneys and say
"well, you should have declared them separate constants if you wanted the
human beingness of kent to work again after you loaded him". It's better
for the language to make it clear that you can't save a complex object
at all and expect to get it back unless you write the code to do it because
it would be lying to you if it declared otherwise.
I think the reason a lot of you think the language should do this is
that you're not used to thinking like a language designer. I don't
mean the technical part--there are a lot of sharp technical people. I
mean the guilt thing. Language design is a lot about seeing people
flail because you gave them enough rope to hang themselves and they
did. And I claim that what separates good design from bad design is
that good designers not only look for things that are hard in hopes of
making them easier, but also they look to where people get in trouble
a lot and are willing to take the personal guilt involved in making
life more difficult by saying "you won't be allowed to get X for free"
because they know that "for free" is a lie and they don't want you to
just end in a mire.
Just about anyone could design a more functional set of tools than a
language designer can design a language because tools only have to
work most of the time and you can kinda shrug and document the places
where they don't work. But the importance of being linguistic is that
you are the very concrete of the foundation on which all future things
will sit, and if you are not designed to be strong, even the tiniest
little cracks will add up after a while and their implications will
start to be felt in places that are far removed from the places that
people are focused on.
I'll give you an example that is off-topic but maybe illustrates what I
mean by things felt other places. Just the other day, I was talking
to someone about having systems tell you when you make certain dumb
little errors. An example might be calling a function with stupid arguments.
Not wrong, just stupid. For example:
(read-from-string stream :start 2)
is a classic. This is completely valid code and it doesn't start
reading from position 2. I would allege that it's appropriate to warn
about it because the probability is so high that even a mechanical program
wouldn't do it that it's worth the warning. But take the following case
that Maclisp used to warn about a lot:
(member x '(a))
I used to get warnings saying one argument to OR was probably a mistake
because it would open code this to
(or (eq x 'a))
and it would think it was dumb for me to use OR without at least two things.
This warning happened a lot and was well-appreciated for years until
macros came into common use, and then it was disastrous. I had code
that said:
(member x '(a $make-compiler-happy$))
because it was constructed by other code that did
`(member x '(,@things $make-compiler-happy$))
and I did not know how many things I would be given. The argument made
by the people who wanted the warning about the OR was that the warning was
"useful" but the argument made by the others was that "useful or not,
it doesn't scale". The language foundation has to be built on things
that scale. Similar problems came up about dead code. It's handy to
get warnings about code like
(cond (foo x) (t y) (bar z))
if no macros are involved, but if a macro is involved, and if the compiler
is deadset on issuing a warning, you're in a real problem and you have
to do weird things like:
(cond (foo x) (*lisp-wont-be-told-until-after-compilation-that-this-is-t* y) (bar z))
And even then, it's probably going to result in slower code.
> (defun make-thing ()
> "Return an uninterned object---a fresh vector of bignums."
> (make-array 17 :initial-value (1+ most-positive-fixnum)))
>
> (1) DEFCONSTANT where the value is not interned in any way, e.g.
>
> (defconstant =foo= (make-thing) "some object")
(Confess: This whole discussion was just an excuse to slip in some
subliminal references to =...= for constants, wasn't it? :-)
> The value returned by another evaluation of the same form that
> initialises =FOO= would not be EQL to =FOO= and (EQL =FOO= =FOO=)
> may or may not be true depending on whether =FOO= is inlined.
> No registration of any kind here.
>
> This is similar to
>
> (define-symbol-macro =foo-as-symbol-macro= (make-thing))
>
> *but* (MAKE-THING) is evaluated only once for _all_ files that
> refer to =FOO=, and evaluation may take place as early as compile
> time: with =FOO-AS-SYMBOL-MACRO=, evaluation will take place at
> run time, and with
>
> (define-symbol-macro =foo-ltv= (load-time-value (make-thing)))
>
> evaluation will take place at load time (and not once for _all_
> files but once for _each_ file).
I don't get the thing with the files. Files are an artificial concept
that you shouldn't introduce unless you absolutely have to. If you want
to talk about files with respect to externalization, there may be
no alternative. But "evaluation" is not about externalization, and indeed
evaluation may be insensitive to what file is involved (for
nested files, for cases where no file is involved, etc.).
> (2) DEFCONSTANT where the value is interned in some way, e.g.
>
> (defconstant =bar= 'baz "an interned symbol")
>
> EQL identity is guaranteed not by virtue of what DEFCONSTANT does
> but by virtue of the properties of the value given to the constant
> variable: (EQL =BAR= =BAR=) and (EQL =BAR= 'BAZ) will both be true
> because this is how interned symbols work, and it doesn't matter
> if =BAR= is inlined or not. The reference is not registered,
> the value is.
>
> (By the way, this reminds me of the concept of otherwise accessible
> parts.)
I just knew someone was going to raise that. It seems like it should
be related, but it's not. Indeed, just the opposite. The whole PROBLEM
is that the parts of a constant ARE accessible. Why? Because the whole
point of a constant is to use it in code. If you didn't use it, you
wouldn't need it. And having used it, you can't know what the system
has done with it--unless you forbid the system from doing useful things,
which seems silly.
> (3) A constant reference where the value is not interned in any way:
> EQL identity is guaranteed only via the same reference but not between
> the constant reference and the value produced by another evaluation
> of the initialisation form. The reference is registered (terminology?),
> the value isn't.
I'm not sure what it means to be the same reference.
In (let* ((x +quux+) (y x)) (eql x y)) is there one reference or two?
>
> File 0:
> (define-constant-reference +quux+ (make-thing) "something else")
> (defconstant =foo= (make-thing) "something") ;just for comparison
>
> File 1:
> (defun quux1 () +quux+)
> (defun foo1 () =foo=)
>
> File 2:
> (defun quux2 () +quux+)
> (defun foo2 () =foo=)
>
> After compiling and loading everything:
>
> (eql (quux1) (quux2)) => t
> (eql (foo1) (foo2)) => unspecified
> (eql +quux+ (make-thing)) => nil
> (eql =foo= (make-thing)) => nil
>
> (4) A constant reference where the value is interned: EQL identity
> is guaranteed in all cases, i.e. one can obtain the same (EQL) object
> not only by another occurrence of the same constant reference but
> also by another evaluation of the initialisation form (or its
> equivalent, in the same sense that 'BAZ and (INTERN "BAZ") are
> equivalent (ceteris paribus: same package, same read case)).
I guess what I'm saying is that similarity is about interning "as
needed", and this is closest to correct. For numbers, interning isn't
needed (though is often practiced for storage reasons) because there are
no comparison operators that can tell the difference between numbers
other than EQ which you are encouraged never to use, and there are no
mutators on numbers much though Drew McDermott used to lament the passing
of "bignums you could rplaca and rplacd" like you used to have in Maclisp.
For packages, interning is needed because there are mutators on packages.
For some structures, mutating is an issue and for some it's not, and
so appropriate MAKE-LOAD-FORM definitions have to be written.
> I wrote just `constants' where I should have written `constant
> variables.' Correct me if I am wrong, but inlining may happen no matter
> if the initialisation form in DEFCONSTANT is QUOTE or LOAD-TIME-VALUE.
I'm not positive I know the answer or that there is an answer.
I can see differing interpretations. It seems to me the whole point of
DEFCONSTANT is to say "the compiler may aggressively view the result of
this computation" and the whole point of saying LOAD-TIME-VALUE it to
say "the compiler may not aggressively view the result of this
computation". Do they cancel? Is the entire form evaluated as if by
EVAL and is "load-time" for the "EVAL" the same as compile-time? I don't
know if I know the answer. I know I've spent so long replying to this that
I'm not going to spend more time researching it today.
> > > Another thing that might be useful would be control over the
> > > mutability of the object that is the value of a constant (similar
> > > to what is there for LOAD-TIME-VALUE).
> >
> > I don't know what this is about. LOAD-TIME-VALUE seems entirely
> > powerful enough.
>
> Once again, please read `constant variable' for `constant' in my
> sentence. A constant variable is always immutable. (There is
> no `read-only-p' parameter to DEFCONSTANT.)
It's not obvious to me what it would mean. Suppose I have a non-read-only
constant and I write it to a file, then I modify it, then I write it to
another file. What is the world like when I load both files in the target
environment? The whole point of a thing you can "aggressively reason about"
is that "you know its contents". It doesn't make sense to say you can know
its identity in advance because it has no pointer identity until runtime.
Only its parts matter, so to say that you're going to sacrifice the parts
for the iddentity so that you can modify it but you can't trust the contents
of that modification seems very odd.
> > (Is this something I missed in your earlier table? It suffices to say
> > I should go back and look at a particular entry in that table if
> > that's all that's going on here. I don't have it handy, but I could
> > go look it up again if you thought it would help. It seemed to me
> > when I glanced at it earlier that each of the things in that table
> > were present or writable in user code.)
>
> I can see now the problem is not with that table not being comprehensive
> but with the need to clarify the concepts before or alongside with
> providing the table.
>
> And as I wrote above, I am not quite satisfied that DEFINE-xxx-REFERENCE
> are adequately writable in user code because I am concerned about the
> legality of
>
> (progn
> (define-symbol-macro foo ...) ;use FOO as if it is a variable
> (defconstant foo ...)) ;but make it unbindable
Heh, I wondered about this, too. I don't know the answer and I bet
implementations could differ on which they prefer to come first.
> I see no reason why it shouldn't be illegal but I don't have that
> `warm, fuzzy feeling' (CLtL2, 11.9, p. 284, near bottom). My worry
> comes from the fact that the name of a global special variable
> cannot be used as a symbol macro. Constant variables are not global
> special variables but still...
Yeah...
> (And `adequately' here also means access in O(1); implementing
> somehow a constant reference on top of a `private' global variable
> does not ensure that because of the possibility of deep binding.)
Oh, this is easy to do:
(defparameter +lexical-unbound+ (make-symbol "UNBOUND"))
(defun lexical-cell (x)
(or (get x 'lexical-cell)
(setf (get x 'lexical-cell) (cons x +lexical-unbound+))))
(defmacro lexical-ref (x)
`(cdr (load-time-value (lexical-cell 'x))))
(defmacro deflexical (var value)
`(progn (define-symbol-macro ,var (lexical-ref ,var))
(setq ,var ,value)
',var))
This is the reason that that define-symbol-macro is so useful.
It allows one to implement a variety of other constructs.
NOTE: I tried the above example in both Harlequin and Allegro.
It fails in LispWorks 4.1 Personal Edition in the interactive
read-eval-print loop (though it works in both interpreted and
compiled load scenarios). Allegro seems to do better. The
simplest test case is:
(progn (define-symbol-macro foo 'bar) foo)
which should work but doesn't in LWW4.1. I assume Hqn is reading
this so I'll leave it to them to fix it if they care. I'm not
on support.
But I think the code is right. You should be able to do:
(deflexical x 3)
(defun foo () x)
(defun bar (f x) (funcall f x))
(defun baz (x) (declare (special x)) (foo))
(bar #'baz 7) => 3
As opposed to what you'd get if you did:
(setq z 3) ;most implementations assume Z special here
(defun foo () z) ;and here
(defun bar (f z) (funcall f z))
(defun baz (z) (declare (special z)) (foo))
(bar #'baz 7) => 7
> Thanks for reading up to here, and for any further remarks,
> Vassil.
No problem.
Raymond Toy
Erik> * chu...@best.com (Chuck Fry)
Erik> | Modern Common Lisp compilers allow me to tune the critical parts of my
Erik> | code to within a few percent of C code, but without the pain of using a
Erik> | fragile, brittle quasi-portable assembly language.
Erik> just for the heck of it: I have tuned a _very_ CPU-heavy function I wrote
Erik> in Common Lisp over a year ago so it went from the unsatisfactory 623 µs
Erik> per call to the very pleasant 4.7 µs per call.
Would it be possible to provide the before and after versions of the
code?
I think it would be very instructive.
Ray
Hartmann Schaffer
Actually, several steps in the evolution might be even more interesting
Hartmann Schaffer
schaffer at netcom dot ca
Erik Naggum
| Actually, several steps in the evolution might be even more interesting
OK, I'll do the steps thing. at issue was hacking up and printing a time
representation. the naïve solution is to use a bignum of seconds since
some human-inspired epoch, use FORMAT with ~D to print it. however, I
also needed proper timezone support (CL's support is suitable only if you
deal with times in a single timezone), and milliseconds (since a second
is a really long time to modern computers, and even milliseconds are).
the zone was represented as the number of hours west of Greenwich.
the time representation is now split up into day, time, and milliseconds.
the zone is changed to seconds eas of Greenwich. day 0 is 2000-03-01,
because that's when a new 400-year leap year period starts, which means
that the leap day is at the end of the four years, the centennium, and
the quatercentennium, and thus no expensive computations are needed to
check for leap years. however, the main culprit was division. it is an
expensive operation, table lookup not, so I precomputed tables for the
146097 days of a quatercentennium and the 86400 seconds of a day, and did
a nifty data representation hack so the values fit in a single fixnum.
the full time representation was changed from a class to a structure, and
proper declarations meant that the access functions were inlined and the
type (fixnum) propagated properly.
time comparison functions now compared three fixnums instead of bignums
and a fixnum (milliseconds) and that meant the timezone tables (extracted
from the Unix timezone database that the C library uses (but also gives
you exactly one handle on)), were searched much faster. in addition, the
interval of the timezone was made available to the caller upon demand (it
affects the length of a local day, which can be 23, 24, or 25 hours!) and
also cached, since most times decoded were in the same timezone. the
time zone adjustment function also did simple addition and subtraction
instead of new divisions into day and time.
what really made a difference once I had figured out how to store the
values in a fixnum (I'll leave that as an exercise for the reader --
since it's so far from obvious how to do it, some people will get a real
kick out of how simple it is, and I don't want to take that kind of joy
away form anyone), was to pass a preallocated vector for the decoding
functions to store its values into instead of returning them as multiple
values.
finally, printing turned out to be very division-intensive, too, so I
precomputed a pair of tables of high and low digits for 100 numbers.
streams were also very expensive, so I deposited characters directly into
a preallocated string and returned a copy or wrote it out (depending on
whether the stream argument was NIL or a stream, like FORMAT). centuries
were easy to change into numbers in the 16 to 99 range instead of 1600 to
9900.
(granted, I have built myself a system with a serious Y10K problem, but
I'll print a warning in the year 9900 if it makes anyone less worried.
rumor has it that Y1K brought us the Dark Ages because it took 400 years
to update all the software to four instead of three digits in the year.)
the only real problem I had with tuning this stuff was that a 400 MHz CPU
is damn hard to get useful statistics from every 10 ms. it manages to do
a tremendous lot of work in 10 ms, so I had to let profiling run for many
minutes to collect useful data as I got closer to the optimum.
#:Erik
Peter Van Eynde
On 02 Apr 1999 11:52:50 +0000, Erik Naggum wrote:
> check for leap years. however, the main culprit was division. it is an
> expensive operation, table lookup not, so I precomputed tables for the
> 146097 days of a quatercentennium and the 86400 seconds of a day, and did
> a nifty data representation hack so the values fit in a single fixnum.
With "the values" you mean the human readable form of the (day,
millisec, timezone) triplet?
..
> what really made a difference once I had figured out how to store the
> values in a fixnum (I'll leave that as an exercise for the reader --
> since it's so far from obvious how to do it, some people will get a real
> kick out of how simple it is, and I don't want to take that kind of joy
So (year,month,day,hour,minute,second) in a fixnum, right?
..
> finally, printing turned out to be very division-intensive, too, so I
*nod*nod*
> the only real problem I had with tuning this stuff was that a 400 MHz CPU
> is damn hard to get useful statistics from every 10 ms. it manages to do
> a tremendous lot of work in 10 ms, so I had to let profiling run for many
> minutes to collect useful data as I got closer to the optimum.
Aha. Is it not possible to use the cycle-counter on modern x86's to
check this. You would have to insert get-the-count instructions here and
there, but it gives you a resolution of 1 clock tick. IIRC
Groetjes, Peter
--
It's logic Jim, but not as we know it. | pvan...@debian.org for pleasure,
"God, root, what is difference?",Pitr | pvan...@inthan.be for more pleasure!