GNU bug report logs - #15814
24.3.50; Signal error on malformed bindings in `cl-symbol-macrolet' (patch)

Previous Next

Package: emacs;

Reported by: Nathan Trapuzzano <nbtrap <at> nbtrap.com>

Date: Tue, 5 Nov 2013 20:42:01 UTC

Severity: minor

Tags: patch

Found in version 24.3.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


Message #23 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Wed, 06 Nov 2013 20:14:37 -0500
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>> (let ((msg (format "Malformed `cl-symbol-macrolet' binding: %S"
>>>> (car bindings))))
>>>> (macroexp--warn-and-return msg `(error "%s" ,msg)))
>
> Check other uses of macroexp--warn-and-return (there aren't many).
> It doesn't signal any error at all.  But they do emit warnings either
> during compilation or while loading an interpreted file.

In the example I gave, the second argument to macroexp--warn-and-return
is an (error ...) form, which will be evaluated at run time.  That's
what I meant.  If we're going to use macroexp--warn-and-return, it seems
this is the only sensible thing to do (in this case that is).  What's
the alternative?  Transform malformed let in some undefined way?  At the
very least, the behavior when compiled/evaluated should be the same as
when interpreted, i.e. an error.

But more generally, what's wrong with signalling the error at compile
time?  Sure, it would cause the Emacs build to fail, but I would call
that an advantage.  Not to mention, it's especially easy to miss the
warnings during the build process, as opposed to compiling individual
files manually.

> As I said, currently it's performed in bytecomp.el and cconv.el, and
> there's no way to get to either of those two without going through
> macroexp--expand-all first.  So, yes, there is a guarantee.
>
> When loading an interpreted file, we go through macroexp--expand-all as
> well (not not through cconv.el nor through bytecomp.el).

It doesn't look like evaluation via M-: has to go through
macroexp--expand-all.  Try:

M-:
(let ((foo 'bar)) foo)
RET

Though I guess in the specific case of malformed `let', this doesn't
really matter, since the interpreter will catch the error.




This bug report was last modified 11 years and 273 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.