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

[Nathan Trapuzzano <nbtrap@nbtrap.com>]

Stefan Monnier <monnier@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.