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

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
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 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

Previous Next

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