On Wed, 2002-10-23 at 07:29, William Harold Newman wrote:
>
> On Tue, Oct 22, 2002 at 02:34:19PM +0200, Gerd Moellmann wrote:
> >
> > Adam Warner <[EMAIL PROTECTED]> writes:
> >
> > > In: defun-grab plus1
> > > (defun-grab plus1 (number) (1+ number))
> > > --> progn eval-when defparameter progn
> > > ==>
> > > (setq plus1 '(defun plus1 (number) (1+ number)))
> > > Warning: Undefined variable: plus1
> >
> > I think this from CLHS might be relevant:
> >
> > defparameter and defvar normally appear as a top level form, but it is
> > meaningful for them to appear as non-top-level forms. However, the
> > compile-time side effects described below only take place when they
> > appear as top level forms.
> >
> > [...]
> >
> > Side Effects:
> >
> > If a defvar or defparameter form appears as a top level form, the
> > compiler must recognize that the name has been proclaimed
> > special. However, it must neither evaluate the initial-value form nor
> > assign the dynamic variable named name at compile time.
> >
> > There may be additional (implementation-defined) compile-time or
> > run-time side effects, as long as such effects do not interfere with
> > the correct operation of conforming programs.
>
> I was motivated to rip so much stuff apart in pursuit of correct
> EVAL-WHEN behavior ca. sbcl-0.7.0 not because I do a lot of exotic
> things with EVAL-WHEN in application code, but because so many of the
> magic-at-toplevel operators like DEFUN, DEFSTRUCT, and DEFVAR are
> naturally defined in terms of EVAL-WHEN. Then when EVAL-WHEN behaves
> correctly, all sorts of special cases, e.g. Adam's and also
> (defun foo (x)
> (if x
> (defstruct foo a)
> (defstruct foo b c)))
> (compile *)
> start to work as ANSI specifies.
I hope you can achieve this aim William and the results cross-pollinate
into CMUCL.
I'm a bit despondent because in attempting to allow the breaking out
into the top level within my document format I have destroyed its
functional design.
If you saw my more recent post I said that I had worked around the
problem by turning the "test" function into a form that concatenates a
global variable:
(test
...)
(defun-grab ...)
(test
...)
I overlooked that this idea also ends any internal nesting at the point
the test function is closed.
Think of the "test" function as part of a document written in Lisp. This
function may e.g. be called document and may e.g. define the start and
end of the document:
(document "This is the full text of the document")
Could translate to:
\begin{document}
This is the full text of the document
\end{document}
It's obvious why I can't break the enclosing function until the
completion of the document: the document would end prematurely. Instead
the design has to become something like:
(begin "document")
...we are still in the top level...
(end "document")
In other words s-expressions cannot be leveraged because it must be
necessary to break out into the top level.
Now I can still decide that all top-level code has to be defined at the
beginning or end of the document. It's the same kind of reluctant
decision you would face if, for example, comments could only be entered
in the top level. You would try and avoid using too much
nested/functional code because the comments would become further and
further away from their logical location.
So people can understand what the defun-grab was for: Raw function input
lists are captured because I have developed a program to automatically
convert a small class of Lisp function syntax to presentation markup.
It is not helpful to have to move all the defun-grab definitions out of
the (document ...) and into the top level. I spent a while putting them
all in their logical locations. If I continue with a functional document
format it appears they must be moved outside the document (since the
functions and defparameters are supposed to be globally accessible).
I'm not sure whether it should work because "defparameter and defvar
normally appear as a top level form, but it is meaningful for them to
appear as non-top-level forms" or whether one of the compile-time
exceptions apply. Given that it doesn't seem to work I still have to
decide whether I should cut back on the document format's function
design to allow entry of code within the top level at strategic
locations. Even though it works with interpreted code I require compiled
code speed.
I may have thought of a third way that goes something like this:
(document (chapter1) (chapter2) (bibliography))
...can put other top level code here...
(defun chapter1 ...)
...can put other top level code here...
(defun chapter2 ...)
...can put other top level code here...
(defun bibliography ...)
Which gets around top level code not being able to be included within
this kind of document structure:
(document
(chapter1 ...)
(chapter2 ...)
(bibliography ...))
I think this fully addresses Raymond's question "perhaps you could
explain why you think you need to do this and what you really want to
do."
Regards,
Adam
