From: Peter Seibel
Subject: compile-time-too/not-compile-time
Date: 
Message-ID: <m3znrzrfi3.fsf@localhost.localdomain>
Are the concepts of the 'compile-time-too' and 'not-compile-time'
processing modes used anywhere in the CLHS other than "3.2.3.1
Processing of Top Level Forms" and the definition of "Special Operator
EVAL-WHEN"?

-Peter

-- 
Peter Seibel
·····@javamonkey.com

From: Kent M Pitman
Subject: Re: compile-time-too/not-compile-time
Date: 
Message-ID: <sfw7kf3w0bz.fsf@shell01.TheWorld.com>
Peter Seibel <·····@javamonkey.com> writes:

> Are the concepts of the 'compile-time-too' and 'not-compile-time'
> processing modes used anywhere in the CLHS other than "3.2.3.1
> Processing of Top Level Forms" and the definition of "Special Operator
> EVAL-WHEN"?

I doubt it.  In part because I don't personally like this way of
explaining EVAL-WHEN.  It's formally correct and it's the definition,
but it's unbalanced in some weird way that bugs me.  (It's sometimes
like saying "Hey, you're not going to the movies and I'm going too"
instead of "Hey, I'm going to the movies without you".)

Where would you expect them to be used, or why do you ask?
From: Peter Seibel
Subject: Re: compile-time-too/not-compile-time
Date: 
Message-ID: <m3r8dari26.fsf@localhost.localdomain>
Kent M Pitman <······@world.std.com> writes:

> Peter Seibel <·····@javamonkey.com> writes:
> 
> > Are the concepts of the 'compile-time-too' and 'not-compile-time'
> > processing modes used anywhere in the CLHS other than "3.2.3.1
> > Processing of Top Level Forms" and the definition of "Special Operator
> > EVAL-WHEN"?
> 
> I doubt it.  In part because I don't personally like this way of
> explaining EVAL-WHEN.  It's formally correct and it's the definition,
> but it's unbalanced in some weird way that bugs me.  (It's sometimes
> like saying "Hey, you're not going to the movies and I'm going too"
> instead of "Hey, I'm going to the movies without you".)
> 
> Where would you expect them to be used, or why do you ask?

Actually I was hoping they *weren't* used anywhere else. I think I
pretty much wrapped my head around 3.2.3.1 as long as it's just a
matter of applying the rules in the table of EVAL-WHEN
situations/processing modes until you've stripped off all the
EVAL-WHEN's. But if there were other places where these concepts were
used, then I was going to have to go find them and incorporate them
into my understanding. That's all. Thanks.

-Peter

-- 
Peter Seibel
·····@javamonkey.com
From: Tim Bradshaw
Subject: Re: compile-time-too/not-compile-time
Date: 
Message-ID: <ey3of8f84fn.fsf@cley.com>
* Peter Seibel wrote:
> Are the concepts of the 'compile-time-too' and 'not-compile-time'
> processing modes used anywhere in the CLHS other than "3.2.3.1
> Processing of Top Level Forms" and the definition of "Special Operator
> EVAL-WHEN"?

I suspect not, but where else would they be useful, since they're
really ways being precise about how top-level forms get processed, and
what a top-level form is?

--tim
From: Howard Stearns
Subject: Re: compile-time-too/not-compile-time
Date: 
Message-ID: <3DE0E78B.9010905@attbi.com>
The _concepts_, if not the quoted names, are used in DEFMACRO and friends:

"If a defmacro form appears as a top level form, the compiler must store 
the macro definition at compile time, so that occurrences of the macro 
later on in the file can be expanded correctly. Users must ensure that 
the body of the macro can be evaluated at compile time if it is 
referenced within the file being compiled."

Tim Bradshaw wrote:
> * Peter Seibel wrote:
> 
>>Are the concepts of the 'compile-time-too' and 'not-compile-time'
>>processing modes used anywhere in the CLHS other than "3.2.3.1
>>Processing of Top Level Forms" and the definition of "Special Operator
>>EVAL-WHEN"?
> 
> 
> I suspect not, but where else would they be useful, since they're
> really ways being precise about how top-level forms get processed, and
> what a top-level form is?
> 
> --tim