Question about IGNORE-ERRORS

Spiros Bousbouras

unread,

Dec 30, 2018, 1:56:54 PM12/30/18

to

If I type at the REPL

(defmacro mac (arg) (unless (integerp arg) (error "mac : Not an integer")))
(list (ignore-errors (mac "")) 44)

, SBCL returns (NIL 44) but ECL throws me into the debugger. Is the
behaviour of ECL conforming ?

Jocelyn Fréchot

unread,

Dec 30, 2018, 2:52:44 PM12/30/18

to

On 30/12/2018 19:56, Spiros Bousbouras wrote:

> If I type at the REPL
>
> (defmacro mac (arg) (unless (integerp arg) (error "mac : Not an integer")))
> (list (ignore-errors (mac "")) 44)
>

> , SBCL returns (NIL 44) but ECL throws me into the debugger. [..]

With which error?

--
Jocelyn Fréchot

Pascal J. Bourguignon

unread,

Dec 30, 2018, 3:02:03 PM12/30/18

to

Your code is not conforming.

The point here is that the error is signaled by the minimal-compiler, at
macro-expansion time, which may occur at compilation-time or at
run-time, depending on the evaluation strategy choosen by the
implementation.

To get conforming behavior, you would have to write, at the REPL:

(defmacro mac (arg) (unless (integerp arg) (error "mac : Not an integer")))

(defparameter *f* (ignore-errors (compile nil (lambda () (list (ignore-errors (mac "")) 44)))))
(when *f* (funcall *f*))

Then, in all cases *f* would be bound to NIL, and no function would be
called. The outer ignore-errors macro would catch the error signaled by
the macro, during COMPILE.

--
__Pascal J. Bourguignon__
http://www.informatimago.com

Spiros Bousbouras

unread,

Dec 30, 2018, 3:06:30 PM12/30/18

to

mac : Not an integer
Broken at EVAL.No restarts available.
Broken at MAC.
>>

If at the >> prompt I type :pop I get
Top level.
>

Barry Margolin

unread,

Dec 31, 2018, 11:51:40 AM12/31/18

to

In article <8wvbGEkWOldthA...@bongo-ra.co>,

The REPL is not fully specified in CL. In particular, it never says
whether the entire form is compiled first, and then executed, or it
interprets it incrementally.

IGNORE-ERRORS establishes a dynamic runtime environment in which errors
are ignored. If the entire form is compiled first, the error will occur
during compilation, not when the expanded code is executed. In this
case, the error should throw you into the debugger.

But if it's evaluated or compiled incrementally, the error doesn't
happen until you're expanding the macro within the execution of the
IGNORE-ERRORS body, and the error is suppressed.

Since the REPL isn't specified fully, both are probably conforming.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Pascal J. Bourguignon

unread,

Dec 31, 2018, 1:44:55 PM12/31/18

to

Barry Margolin <bar...@alum.mit.edu> writes:

> In article <8wvbGEkWOldthA...@bongo-ra.co>,
> Spiros Bousbouras <spi...@gmail.com> wrote:
>
>> If I type at the REPL
>>
>> (defmacro mac (arg) (unless (integerp arg) (error "mac : Not an integer")))
>> (list (ignore-errors (mac "")) 44)
>>
>> , SBCL returns (NIL 44) but ECL throws me into the debugger. Is the
>> behaviour of ECL conforming ?
>
> The REPL is not fully specified in CL. In particular, it never says
> whether the entire form is compiled first, and then executed, or it
> interprets it incrementally.
>
> IGNORE-ERRORS establishes a dynamic runtime environment in which errors
> are ignored. If the entire form is compiled first, the error will occur
> during compilation, not when the expanded code is executed. In this
> case, the error should throw you into the debugger.
>
> But if it's evaluated or compiled incrementally, the error doesn't
> happen until you're expanding the macro within the execution of the
> IGNORE-ERRORS body, and the error is suppressed.
>
> Since the REPL isn't specified fully, both are probably conforming.

Both behaviors are allowed for the implementations: it's implementation
dependent, the opposite of conforming. Both implementations remain
conforming for having an implementation dependent behavior, as long as
it is documented.

For conforming code see my other post.

Kaz Kylheku

unread,

Dec 31, 2018, 2:08:28 PM12/31/18

to

That of ECL is less surprising to me. You're generating the error at
macro-expansion time.

The description of ignore-errors form doesn't say anything about
catching errors during the macro expansion of its argument forms.

The error suppression could happen in an evaluation model in which macro
expansion is interleaved with evaluation, rather than as a full
expansion pass over an entire top-level form prior to any evaluation.

It could happen anyway if ignore-errors is imbued with macro-expansion-time
semantics, extending its error-catching protection over expansion time.

Spiros Bousbouras

unread,

Sep 11, 2019, 1:28:05 AM9/11/19

to

On Mon, 31 Dec 2018 11:51:34 -0500
Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <8wvbGEkWOldthA...@bongo-ra.co>,
> Spiros Bousbouras <spi...@gmail.com> wrote:
>
> > If I type at the REPL
> >
> > (defmacro mac (arg) (unless (integerp arg) (error "mac : Not an integer")))
> > (list (ignore-errors (mac "")) 44)
> >
> > , SBCL returns (NIL 44) but ECL throws me into the debugger. Is the
> > behaviour of ECL conforming ?
>
> The REPL is not fully specified in CL. In particular, it never says
> whether the entire form is compiled first, and then executed, or it
> interprets it incrementally.
>
> IGNORE-ERRORS establishes a dynamic runtime environment in which errors
> are ignored. If the entire form is compiled first, the error will occur
> during compilation, not when the expanded code is executed. In this
> case, the error should throw you into the debugger.
>
> But if it's evaluated or compiled incrementally, the error doesn't
> happen until you're expanding the macro within the execution of the
> IGNORE-ERRORS body, and the error is suppressed.
>
> Since the REPL isn't specified fully, both are probably conforming.

Is it just the REPL ? If the code was in a file and I did LOAD , wouldn't
the behaviour be the same ?