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


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814 <at> debbugs.gnu.org
Subject: bug#15814: 24.3.50; Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Wed, 06 Nov 2013 21:08:39 -0500
> What's the alternative?  Transform malformed let in some undefined way?

Yup.  Just like we've done so far.

> very least, the behavior when compiled/evaluated should be the same as
> when interpreted, i.e. an error.

For incorrect syntax, it's perfectly OK to misbehave differently in the
two cases.  Especially, the interpreted case without going through eager
macroexpansion (i.e. through macroexpand-all) is largely irrelevant.

> But more generally, what's wrong with signalling the error at compile
> time?

I explained that already: the first error stops everything, so you only
get one error report even when there are several errors.

>> 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.

No, because M-: is not "loading an interpreted file".
But sooner or later M-: will also go through macroexpand-all.


        Stefan




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.