From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nathan Trapuzzano Newsgroups: gmane.emacs.bugs Subject: bug#15814: 24.3.50; Signal error on malformed bindings in `cl-symbol-macrolet' (patch) Date: Wed, 06 Nov 2013 20:14:37 -0500 Message-ID: <871u2tgghu.fsf@nbtrap.com> References: <87k3gmmvk9.fsf@nbtrap.com> <87a9himfvp.fsf@nbtrap.com> <87ppqd2314.fsf@nbtrap.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1383792659 6915 80.91.229.3 (7 Nov 2013 02:50:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Nov 2013 02:50:59 +0000 (UTC) Cc: 15814@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 07 03:51:03 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VeFgU-0007fe-IO for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Nov 2013 03:51:02 +0100 Original-Received: from localhost ([::1]:37378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeFgT-0006ha-Tx for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Nov 2013 21:51:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeEBj-0004X7-UC for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2013 20:15:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VeEBd-0000hM-Sm for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2013 20:15:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeEBb-0000a6-Mk for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2013 20:15:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VeEBb-0002f9-2M for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2013 20:15:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Nathan Trapuzzano Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Nov 2013 01:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15814 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 15814-submit@debbugs.gnu.org id=B15814.138378688610198 (code B ref 15814); Thu, 07 Nov 2013 01:15:02 +0000 Original-Received: (at 15814) by debbugs.gnu.org; 7 Nov 2013 01:14:46 +0000 Original-Received: from localhost ([127.0.0.1]:38001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VeEBK-0002eP-2C for submit@debbugs.gnu.org; Wed, 06 Nov 2013 20:14:46 -0500 Original-Received: from oproxy19-pub.mail.unifiedlayer.com ([70.40.200.33]:54153) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VeEBH-0002eH-NB for 15814@debbugs.gnu.org; Wed, 06 Nov 2013 20:14:44 -0500 Original-Received: (qmail 19451 invoked by uid 0); 7 Nov 2013 01:14:40 -0000 Original-Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy19.mail.unifiedlayer.com with SMTP; 7 Nov 2013 01:14:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=zonoFRtjYDzh0lLwA5JUlCjzc06phMzbPSthN8ete74=; b=r/zeZwl1zC13ZFZQizP7kmNAZCUhTJd72zJkW+QlqcAdgSf/ewibXxTA3zp8PJb5oboarrfcZUtkAou5E+aGVsULZ0WpqJViPhRHlmNhk/s1SKduHN6MReOgi+q1Nd3t; Original-Received: from [50.90.253.209] (port=51540 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (TLSv1:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1VeEBD-0003BM-Uh; Wed, 06 Nov 2013 18:14:40 -0700 In-Reply-To: (Stefan Monnier's message of "Wed, 06 Nov 2013 08:45:24 -0500") User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3.50 (gnu/linux) X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80101 Archived-At: Stefan Monnier 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.