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?)

(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

In article <nkjpv5y244f....@tfeb.org>,
        Tim Bradshaw <t...@tfeb.org> writes:

  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.

  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.

  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.

  There's an old cliche about getting it right first, then worry about
optimizations.

  Mike McDonald
  mike...@mikemac.com

Your analysis of what one might want defconstant to do makes sense to
me.

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.

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.

[I wrote]

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

"Howard R. Stearns" <how...@elwood.com> writes:

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.

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.

I'm not sure I totally understand what you said here about stability,
but nothing that I did understand sounded wrong. :-)

These all sound ok.  Mike is asking for more than this, though, right?

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...

In article <36F99FFB.24139...@franz.com>,
        "Steven M. Haflich" <s...@franz.com> writes:

  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
  mike...@mikemac.com

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.

In article <sfwk8w5eu91....@world.std.com>,
        Kent M Pitman <pit...@world.std.com> writes:

  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.

  Nope, it could be

  (defun bc () (something-similar-to #1#))

  instead.

  Mike McDonald
  mike...@mikemac.com

I'd do

        (defun blib ()
          '#.(cdr foo))

I like to compute stuff at read time when DEFCONSTANT is involved.

Christopher

In article <87aex16zd5....@2xtreme.net>,
  cba...@2xtreme.net (Christopher R. Barry) wrote:

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 <vniko...@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    

Kent M Pitman <pit...@world.std.com> writes:

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.

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

pe...@harlequin.co.uk (Pekka P. Pirinen) writes:

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.

This may be a truth about some compiler (or many) but is not a truth
about Lisp.

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.

I'm missing what language feature you're saying DEFCONSTANT breaks.

Kent M Pitman <pit...@world.std.com> writes:

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

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.

In article <sfw3e2nbwmu....@world.std.com>,
Kent M Pitman  <pit...@world.std.com> wrote:

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)  chuck...@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.

In article <7dr23c$2r...@shell5.ba.best.com>,
        chu...@best.com (Chuck Fry) writes:

  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
  mike...@mikemac.com

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

In article <7dr23c$2r...@shell5.ba.best.com>,
  chu...@best.com (Chuck Fry) wrote:
(...)

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).

Vassil Nikolov <vniko...@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    

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.

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).

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.)

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

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html

I am aware that this has become rather long but please bear with me.

In article <sfwpv5q8imr....@world.std.com>,
  Kent M Pitman <pit...@world.std.com> wrote:

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).

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.

And a constant reference is definitely not the same as a literal object.

(...)

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!)

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)).

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'?)

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.)

...

read more »

* chu...@best.com (Chuck Fry)
| 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

In article <7dv9jq$in...@nnrp1.dejanews.com>,
Vassil Nikolov  <vniko...@poboxes.com> wrote:

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.

In article <pwPM2.160$kM2.33262@burlma1-snr2>,
  Barry Margolin <bar...@bbnplanet.com> wrote:
(...)

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.)

Vassil Nikolov <vniko...@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