From: Marco Antoniotti
Subject: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <c2455095-557b-42f4-985c-da15bca013b3@k30g2000hse.googlegroups.com>
Hi

I know this may be a RTFM question, but, as usual, I am lazy... :)

For reasons that I do not want to discuss here, I may end up doing
things like

(handler-bind ((warning #'muffle-warning))
   (defstruct foo a s d)
   (defclass zot () ())
   ;; etc etc
)

Are there some CLHS limitations on the compiler's behavior as far as
the types FOO and ZOT are concerned?  I am asking this, because I am
not so sure if HANDLER-BIND has to be treated as PROGN at the top-
level.

Thanks
--
Marco

From: Richard M Kreuter
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <87y73b2mf2.fsf@progn.net>
Marco Antoniotti <·······@gmail.com> writes:

> For reasons that I do not want to discuss here, I may end up doing
> things like
>
> (handler-bind ((warning #'muffle-warning))
>    (defstruct foo a s d)
>    (defclass zot () ())
>    ;; etc etc
> )
>
> Are there some CLHS limitations on the compiler's behavior as far as
> the types FOO and ZOT are concerned?

Yes.  From 3.2.3.1.1 "Processing of Defining Macros":  

| The next figure lists macros that make definitions available both in
| the compilation and run-time environments... As with ‘eval-when’,
| these compile-time side effects happen only when the defining macros
| appear at top level.
|
| declaim                 define-modify-macro    defsetf
| defclass                define-setf-expander   defstruct
| defconstant             defmacro               deftype
| define-compiler-macro   defpackage             defvar
| define-condition        defparameter           
|
| Figure 3.8: Defining Macros That Affect the Compile-Time Environment

--
RmK
From: Marco Antoniotti
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <a49c6257-ff1c-4ba4-8cb5-d8f8b7c0837c@s50g2000hsb.googlegroups.com>
On Aug 5, 5:15 pm, Richard M Kreuter <·······@progn.net> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > For reasons that I do not want to discuss here, I may end up doing
> > things like
>
> > (handler-bind ((warning #'muffle-warning))
> >    (defstruct foo a s d)
> >    (defclass zot () ())
> >    ;; etc etc
> > )
>
> > Are there some CLHS limitations on the compiler's behavior as far as
> > the types FOO and ZOT are concerned?
>
> Yes.  From 3.2.3.1.1 "Processing of Defining Macros":  

Well.  I find "3.2.3.1.2 Constraints on Macros and Compiler Macros"
even more stringent, given what is written in "3.2.3.1 Processing of
Top Level Forms" point (2).

Now, my head is spinning... what about yours? :)

Cheers
--
Marco
From: Thomas F. Burdick
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <a808ba89-e69c-493e-9b04-a40988f4112f@j1g2000prb.googlegroups.com>
On 5 août, 23:32, Marco Antoniotti <·······@gmail.com> wrote:
> On Aug 5, 5:15 pm, Richard M Kreuter <·······@progn.net> wrote:
>
> > Marco Antoniotti <·······@gmail.com> writes:
> > > For reasons that I do not want to discuss here, I may end up doing
> > > things like
>
> > > (handler-bind ((warning #'muffle-warning))
> > >    (defstruct foo a s d)
> > >    (defclass zot () ())
> > >    ;; etc etc
> > > )
>
> > > Are there some CLHS limitations on the compiler's behavior as far as
> > > the types FOO and ZOT are concerned?
>
> > Yes.  From 3.2.3.1.1 "Processing of Defining Macros":  
>
> Well.  I find "3.2.3.1.2 Constraints on Macros and Compiler Macros"
> even more stringent, given what is written in "3.2.3.1 Processing of
> Top Level Forms" point (2).
>
> Now, my head is spinning... what about yours? :)

Fortunately you can avoid vertigo by splitting things into several
files, and putting the handler-bind around the compile-file/load.
Unless that's too easy :-)
From: Marco Antoniotti
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <ff526ffd-c4e0-466b-a214-516a22eada7e@m3g2000hsc.googlegroups.com>
On Aug 6, 3:35 am, "Thomas F. Burdick" <········@gmail.com> wrote:
> On 5 août, 23:32, Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
> > On Aug 5, 5:15 pm, Richard M Kreuter <·······@progn.net> wrote:
>
> > > Marco Antoniotti <·······@gmail.com> writes:
> > > > For reasons that I do not want to discuss here, I may end up doing
> > > > things like
>
> > > > (handler-bind ((warning #'muffle-warning))
> > > >    (defstruct foo a s d)
> > > >    (defclass zot () ())
> > > >    ;; etc etc
> > > > )
>
> > > > Are there some CLHS limitations on the compiler's behavior as far as
> > > > the types FOO and ZOT are concerned?
>
> > > Yes.  From 3.2.3.1.1 "Processing of Defining Macros":  
>
> > Well.  I find "3.2.3.1.2 Constraints on Macros and Compiler Macros"
> > even more stringent, given what is written in "3.2.3.1 Processing of
> > Top Level Forms" point (2).
>
> > Now, my head is spinning... what about yours? :)
>
> Fortunately you can avoid vertigo by splitting things into several
> files, and putting the handler-bind around the compile-file/load.
> Unless that's too easy :-)

Nope. For my purposes, I need the HANDLER-BIND to be the result of
macroexpansion of a DEFSOMETHING macro.

Apart from that, note that AFAIU a strict reading of the CLHS also
implies that the usual trick

(let ((my-static-almost-as-in-C-var 42))
   (defun foo (...) ... my-static-almost-as-in-C-var ...)

is not all that well defined w.r.t. the compiler.


Cheers
--
Marco
From: Pascal Costanza
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <6fttbfFddm30U1@mid.individual.net>
Marco Antoniotti wrote:
> On Aug 6, 3:35 am, "Thomas F. Burdick" <········@gmail.com> wrote:
>> On 5 ao�t, 23:32, Marco Antoniotti <·······@gmail.com> wrote:
>>
>>
>>
>>> On Aug 5, 5:15 pm, Richard M Kreuter <·······@progn.net> wrote:
>>>> Marco Antoniotti <·······@gmail.com> writes:
>>>>> For reasons that I do not want to discuss here, I may end up doing
>>>>> things like
>>>>> (handler-bind ((warning #'muffle-warning))
>>>>>    (defstruct foo a s d)
>>>>>    (defclass zot () ())
>>>>>    ;; etc etc
>>>>> )
>>>>> Are there some CLHS limitations on the compiler's behavior as far as
>>>>> the types FOO and ZOT are concerned?
>>>> Yes.  From 3.2.3.1.1 "Processing of Defining Macros":  
>>> Well.  I find "3.2.3.1.2 Constraints on Macros and Compiler Macros"
>>> even more stringent, given what is written in "3.2.3.1 Processing of
>>> Top Level Forms" point (2).
>>> Now, my head is spinning... what about yours? :)
>> Fortunately you can avoid vertigo by splitting things into several
>> files, and putting the handler-bind around the compile-file/load.
>> Unless that's too easy :-)
> 
> Nope. For my purposes, I need the HANDLER-BIND to be the result of
> macroexpansion of a DEFSOMETHING macro.

What about expanding into this?

(eval-when (:compile-toplevel :load-toplevel :execute)
   (handler-bind ((warning #'muffle-warning))
     (defstruct ...)
     (defclass ...)))

Then you get the full definitions at compile time, which means that they 
are also recognized in subsequent code.

> Apart from that, note that AFAIU a strict reading of the CLHS also
> implies that the usual trick
> 
> (let ((my-static-almost-as-in-C-var 42))
>    (defun foo (...) ... my-static-almost-as-in-C-var ...)
> 
> is not all that well defined w.r.t. the compiler.

What do you mean by "not well defined" here?

You can have invocations of foo elsewhere in the code, no problem. (You 
may not get static checks that the numbers of arguments are correct, but 
so what?)


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Thomas F. Burdick
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <e6be9e6c-29dd-4c70-87b5-03f421f7b859@8g2000hse.googlegroups.com>
On Aug 6, 5:12 pm, Pascal Costanza <····@p-cos.net> wrote:
> Marco Antoniotti wrote:
> > On Aug 6, 3:35 am, "Thomas F. Burdick" <········@gmail.com> wrote:
> >> On 5 août, 23:32, Marco Antoniotti <·······@gmail.com> wrote:
>
> >>> On Aug 5, 5:15 pm, Richard M Kreuter <·······@progn.net> wrote:
> >>>> Marco Antoniotti <·······@gmail.com> writes:
> >>>>> For reasons that I do not want to discuss here, I may end up doing
> >>>>> things like
> >>>>> (handler-bind ((warning #'muffle-warning))
> >>>>>    (defstruct foo a s d)
> >>>>>    (defclass zot () ())
> >>>>>    ;; etc etc
> >>>>> )
> >>>>> Are there some CLHS limitations on the compiler's behavior as far as
> >>>>> the types FOO and ZOT are concerned?
> >>>> Yes.  From 3.2.3.1.1 "Processing of Defining Macros":  
> >>> Well.  I find "3.2.3.1.2 Constraints on Macros and Compiler Macros"
> >>> even more stringent, given what is written in "3.2.3.1 Processing of
> >>> Top Level Forms" point (2).
> >>> Now, my head is spinning... what about yours? :)
> >> Fortunately you can avoid vertigo by splitting things into several
> >> files, and putting the handler-bind around the compile-file/load.
> >> Unless that's too easy :-)
>
> > Nope. For my purposes, I need the HANDLER-BIND to be the result of
> > macroexpansion of a DEFSOMETHING macro.

Aw don't be such a wimp! Between *compile-file-pathname* and *load-
pathname* you can figure out in your macro expansion function where to
write the auxiliary files and ... end up with a *real* mess :-)

> What about expanding into this?
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
>    (handler-bind ((warning #'muffle-warning))
>      (defstruct ...)
>      (defclass ...)))
>
> Then you get the full definitions at compile time, which means that they
> are also recognized in subsequent code.

With defstruct, you are in fact redefining the struct, even if the
definition is compatible. Which is technically not okay, but in
practice supported by every implementation AFAIK.

>
> > Apart from that, note that AFAIU a strict reading of the CLHS also
> > implies that the usual trick
>
> > (let ((my-static-almost-as-in-C-var 42))
> >    (defun foo (...) ... my-static-almost-as-in-C-var ...)
>
> > is not all that well defined w.r.t. the compiler.
>
> What do you mean by "not well defined" here?
>
> You can have invocations of foo elsewhere in the code, no problem. (You
> may not get static checks that the numbers of arguments are correct, but
> so what?)

I also believe that you can't count on using FOO in the current
compile-time environment, eg, in a macro expansion function, before
loading the fasl.
From: Pascal Costanza
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <6fug1oFdb8kmU1@mid.individual.net>
Thomas F. Burdick wrote:
> On Aug 6, 5:12 pm, Pascal Costanza <····@p-cos.net> wrote:
>> What about expanding into this?
>>
>> (eval-when (:compile-toplevel :load-toplevel :execute)
>>    (handler-bind ((warning #'muffle-warning))
>>      (defstruct ...)
>>      (defclass ...)))
>>
>> Then you get the full definitions at compile time, which means that they
>> are also recognized in subsequent code.
> 
> With defstruct, you are in fact redefining the struct, even if the
> definition is compatible. Which is technically not okay, but in
> practice supported by every implementation AFAIK.

Well, it _is_ better to use defclass by default, and defstruct only when 
you need the speed. ;)

>>> Apart from that, note that AFAIU a strict reading of the CLHS also
>>> implies that the usual trick
>>> (let ((my-static-almost-as-in-C-var 42))
>>>    (defun foo (...) ... my-static-almost-as-in-C-var ...)
>>> is not all that well defined w.r.t. the compiler.
>> What do you mean by "not well defined" here?
>>
>> You can have invocations of foo elsewhere in the code, no problem. (You
>> may not get static checks that the numbers of arguments are correct, but
>> so what?)
> 
> I also believe that you can't count on using FOO in the current
> compile-time environment, eg, in a macro expansion function, before
> loading the fasl.

You cannot count on that anyway. Even if a defun form is toplevel, it 
won't be available in the compilation environment.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Richard M Kreuter
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <87abfq2g1t.fsf@progn.net>
Marco Antoniotti <·······@gmail.com> writes:

> Apart from that, note that AFAIU a strict reading of the CLHS also
> implies that the usual trick
>
> (let ((my-static-almost-as-in-C-var 42))
>    (defun foo (...) ... my-static-almost-as-in-C-var ...)
>
> is not all that well defined w.r.t. the compiler.

That's right.  From the dictionary entry for DEFUN:

| ‘defun’ is not required to perform any compile-time side effects.

--
RmK
From: Pascal J. Bourguignon
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <87ej52qazj.fsf@hubble.informatimago.com>
Richard M Kreuter <·······@progn.net> writes:

> Marco Antoniotti <·······@gmail.com> writes:
>
>> Apart from that, note that AFAIU a strict reading of the CLHS also
>> implies that the usual trick
>>
>> (let ((my-static-almost-as-in-C-var 42))
>>    (defun foo (...) ... my-static-almost-as-in-C-var ...)
>>
>> is not all that well defined w.r.t. the compiler.
>
> That's right.  From the dictionary entry for DEFUN:
>
> | ‘defun’ is not required to perform any compile-time side effects.


On the other hand, 

(eval-when (:compile-toplevel :load-toplevel :execute)
  (let ((my-static-almost-as-in-C-var 42))
     (defun foo (...) ... my-static-almost-as-in-C-var ...)))

is perfectly well defined w.r.t. the compiler.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
From: Pascal Costanza
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <6fug49Fdb8kmU2@mid.individual.net>
Richard M Kreuter wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> 
>> Apart from that, note that AFAIU a strict reading of the CLHS also
>> implies that the usual trick
>>
>> (let ((my-static-almost-as-in-C-var 42))
>>    (defun foo (...) ... my-static-almost-as-in-C-var ...)
>>
>> is not all that well defined w.r.t. the compiler.
> 
> That's right.  From the dictionary entry for DEFUN:
> 
> | ‘defun’ is not required to perform any compile-time side effects.

The sentence that follows after is more important: "In particular, defun 
does not make the function definition available at compile time."

That's not optional.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <6frtprFcug24U1@mid.individual.net>
Marco Antoniotti wrote:
> Hi
> 
> I know this may be a RTFM question, but, as usual, I am lazy... :)
> 
> For reasons that I do not want to discuss here, I may end up doing
> things like
> 
> (handler-bind ((warning #'muffle-warning))
>    (defstruct foo a s d)
>    (defclass zot () ())
>    ;; etc etc
> )
> 
> Are there some CLHS limitations on the compiler's behavior as far as
> the types FOO and ZOT are concerned?  I am asking this, because I am
> not so sure if HANDLER-BIND has to be treated as PROGN at the top-
> level.

HANDLER-BIND is most certainly removes top-leveledness: It sets up a 
handler for conditions in the dynamic environment, which happens at runtime.

The types introduced by DEFSTRUCT and DEFCLASS are only recognized by 
the compiler at compile time when they are toplevel forms. So there you 
go...

[It's a pity that it's not easily possible to set up global condition 
handlers, without opening up a new dynamic extent.]

Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Marco Antoniotti
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <902ca4c7-f01f-46c7-a441-41b1a8e0d041@d77g2000hsb.googlegroups.com>
On Aug 5, 5:08 pm, Pascal Costanza <····@p-cos.net> wrote:
> Marco Antoniotti wrote:
> > Hi
>
> > I know this may be a RTFM question, but, as usual, I am lazy... :)
>
> > For reasons that I do not want to discuss here, I may end up doing
> > things like
>
> > (handler-bind ((warning #'muffle-warning))
> >    (defstruct foo a s d)
> >    (defclass zot () ())
> >    ;; etc etc
> > )
>
> > Are there some CLHS limitations on the compiler's behavior as far as
> > the types FOO and ZOT are concerned?  I am asking this, because I am
> > not so sure if HANDLER-BIND has to be treated as PROGN at the top-
> > level.
>
> HANDLER-BIND is most certainly removes top-leveledness: It sets up a
> handler for conditions in the dynamic environment, which happens at runtime.
>
> The types introduced by DEFSTRUCT and DEFCLASS are only recognized by
> the compiler at compile time when they are toplevel forms. So there you
> go...

That was my understanding.  However, there is another dark side (read:
implementation-dependent side) to this line of reasoning.  It is
unclear where and how types are handled.  In particular, there is no
user level way to "expand" the cons representing a type specifier that
is the result of issuing a DEFTYPE.

> [It's a pity that it's not easily possible to set up global condition
> handlers, without opening up a new dynamic extent.]

Ditto.

Cheers
--
Marco
From: Kent M Pitman
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <uzlnr87il.fsf@nhplace.com>
Marco Antoniotti <·······@gmail.com> writes:

> > [It's a pity that it's not easily possible to set up global condition
> > handlers, without opening up a new dynamic extent.]
> 
> Ditto.

There are a number of "obvious" features people want in CL that were 
not-so-obvious after all when you had an architecture like the LispM,
and that influenced the design of CL in various places.

Because the LispM had no separated address space, the problem was that
toplevel handlers would have invaded arbitrary other programs, unrelated
to your own, even things like the scheduler.  By requiring you to bind
handlers around the outermost place in your program, you end up naturally
supporting such architectures.

Nothing keeps you from creating something that emulates top-level handlers
and having a form that does (with-toplevel ...) and even your own
process-run-function that automatically wraps a call-with-toplevel
around new processes.

Incidentally, the QUIT function people always ask for has the same
issue, and there's no reason you can't have that same with-toplevel macro
you just wrote also be accompanied by a quit function that throws to a
throw established by such a form, and perhaps also exits the Lisp if
you say that's what should happen... note that on the LispM, if you exited
Lisp every time you exited an application, you'd have been really unhappy,
since exiting Lisp was the same as halting the machine.
From: Pascal Costanza
Subject: Re: CLHS hermeneutics: HANDLER-BIND as a top level form...
Date: 
Message-ID: <6fs2nhFd72b1U1@mid.individual.net>
Kent M Pitman wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> 
>>> [It's a pity that it's not easily possible to set up global condition
>>> handlers, without opening up a new dynamic extent.]
>> Ditto.
> 
> There are a number of "obvious" features people want in CL that were 
> not-so-obvious after all when you had an architecture like the LispM,
> and that influenced the design of CL in various places.

I certainly didn't mean to say that it would be easy to design such a 
feature. It's clear that there are some important issues to be solved 
here...

Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/