[Openmcl-devel] use of #.

Hamilton Link helink at sandia.gov
Mon Jan 28 12:35:21 PST 2002

Gary Byers wrote:
> On Mon, 28 Jan 2002, Eric Marsden wrote:
> > Hi,
> >
> > OpenMCL behaves rather differently from other implementations in the
> > way that COMPILE-FILE adds information to the evaluation environment.
> > Consider code like
> >
> >    (defconstant +foo+ #\a)
> >    (defun foo () #.(char-code +foo+))
> >
> > This doesn't compile on OpenMCL. CLHS "Processing of
> > Defining Macros" says that DEFCONSTANT must "make definitions
> > available both in the compilation and run-time environments". So I
> > take it the evaluation and runtime environements are separate.
> >
> > What idioms do people use to get around this? Wrapping everything with
> Yes (though personally I don't think think of it as "getting around"
> anything; that may be a minority opinion.)

If I might inject another potentially minority opinion, this issue
should almost never come up, so wrapping "everything" in an eval-when
seems like an overstatement. IMHO the #. reader macro is almost never a
Good Thing (tm); I think I probably use eval-when more often for funky
macro stuff than for anything else, and even then not very often.

I think my idiom is just never using #. for anything, and treating
eval-when like a signal that I should stop and consider whether what I'm
doing should really depend on that aspect of the environment.

IIRC, an example of when I've had to break down and use eval-when is
when I wanted to defun something in file A and then use it in the body
of a defmacro in file B. In order to have things use the macro and get
macroexpanded, the function had to be defined, and the function wasn't
available by the time the other file was loaded unless I used eval-when
to put it in an environment where it would hang around.


Openmcl-devel mailing list
Openmcl-devel at clozure.com

More information about the Openmcl-devel mailing list