From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling Date: Mon, 21 Apr 2014 21:46:58 -0700 Message-ID: <5355F442.6080606@dancol.org> References: <535558EA.7070506@dancol.org> <53559BD2.3000006@dancol.org> <5355D244.2050104@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MWu1O1U4xuPektOgLbfpCniex0DUUxd9h" X-Trace: ger.gmane.org 1398142035 8075 80.91.229.3 (22 Apr 2014 04:47:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2014 04:47:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 22 06:47:09 2014 Return-path: Envelope-to: ged-emacs-devel@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 1WcSbr-0002jz-6Z for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 06:47:07 +0200 Original-Received: from localhost ([::1]:52728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcSbq-00019H-QQ for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 00:47:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcSbm-00018c-Dc for emacs-devel@gnu.org; Tue, 22 Apr 2014 00:47:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WcSbl-00051k-3B for emacs-devel@gnu.org; Tue, 22 Apr 2014 00:47:02 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:42844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcSbk-00050u-LZ for emacs-devel@gnu.org; Tue, 22 Apr 2014 00:47:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=uVO1arqEytwFMfOomVm8xU8zxBCD/HWAWIFeeKWVCYM=; b=cqDR03pN9gH7V45r27pcduM/bv1fJwmvaKuIW8MXThTGxd/Fbm7xpzNkAx0ln8a03toqXUARQPt3XV5HFLtpjTQxsAz4oQIcs64dcDEGaOf14rrtcyu+YzBTqPC1TsfrmvmBcFX33mtjG6tokHNUQeCAWZmNS+qwJPky5o/TKICl6bExnRRUgt0y71y576EJNm6tHgjmtbX/BIMVgdl7CHgvNdCbLXhrEbm7DxHFvlqqageZQn06NakMBd/Ra1n5j4AzZsqyL45H8l0MInv+6olfVH7pRZOtElrHhJFe6sXteMD4SbJKDngOB2Ik1pRsuO1A/7zpdlhDqBbgkIHUsg==; Original-Received: from [2601:8:b200:2b6::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WcSbj-0005jT-Mb; Mon, 21 Apr 2014 21:46:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: X-Enigmail-Version: 1.6 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171569 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MWu1O1U4xuPektOgLbfpCniex0DUUxd9h Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/21/2014 09:25 PM, Stefan Monnier wrote: >>> That's not the kind of example I was thinking if. Do you have a real= >>> example, maybe? >> Try writing a macro that emits a defstruct, then a function that uses >> cl-typep for that struct, all wrapped in the same toplevel progn. >=20 > That's getting closer to an actual example. I still can't think of > a case where you'd want to use cl-typep in this way, tho. cl-struct-slot-value uses typep It makes sense to do so given that cl-struct-slot-value knows the name of the struct, but not necessarily the name of its predicate function --- which might not even exist. The chunk below is from the iface code I'm working on. This code isn't even close to done --- it's just here to give you a sense of the problem. You see that we declare a structure, then emit some functions that use the structure. Some of these functions go on to do things with values that are allegedly of the structure type, and they use typep to check that these values are actually of the struct type. This approach is a perfectly logical way to go about writing code, and we should support it. Forcing users to do something else is especially pernicious because the problem we're discussing only shows up when compiling (or loading) files --- in normal interactive development, everything seems fi= ne! (eval-and-compile (defun iface--make-member-wrapper (iface-name member) "Create a lisp form defining an interface accessor. IFACE-NAME is a symbol giving the name of the interface being defined. MEMBER is an element of the MEMBERS parameter to `iface-declare'." (cl-destructuring-bind ((member-name inst-arg &rest xarglist) &optional doc) member (unless (and inst-arg (symbolp inst-arg) (not (eql (aref (symbol-name inst-arg) 0) ?\&))) (error (concat "Interface members must accept an instance as" " their first argument"))) `(defun ,member-name (,inst-arg &rest xargs) ,doc (declare (advertised-calling-convention (,inst-arg ,@xarglist) ,emacs-version)) (apply (cl-struct-slot-value ',iface-name ',member-name ,inst-ar= g) ,inst-arg xargs))))) (cl-defmacro iface-declare ((name base) &rest members) "Create a new interface called NAME, inheriting from BASE. MEMBERS is a list of member specifiers. Each is a list of the form ((NAME . ARGUMENTS) DOCUMENTATION), where NAME is a symbol naming the interface member, ARGUMENTS is a cl-lib-style argument list, and DOCUMENTATION is documentation to attach to that function." (let ((doc (and (stringp (car members)) (pop members))) (prefix (concat (symbol-name name) "--iface-"))) `(progn (cl-defstruct (,name (:include ,base) (:conc-name ,(intern prefix)) (:copier nil)) ,@(if doc (list doc)) ,@(mapcar #'caar members)) ,@(mapcar (lambda (member) (iface--make-member-wrapper name member)) members) ',name))) >> The reason we have automated tests is to make sure we can maintain thi= s >> "level of detail". That it's not immediately useful to you isn't a >> reason not to include it. I can't believe this issue is even >> contentious: the current behavior is a clear bug. >=20 > It's a clear bug if we assume Common-Lisp semantics. But in many cases= , > Elisp chooses to provide simpler semantics, to allow a simpler and/or > more naive implementation. I don't care whether we diverge from CL in sets of supported features and names of functions, but we should try hard to match CL's fundamental execution semantics. Practically every possible bad lisp idea was tried before Common Lisp came around. The CL people knew about the precise problem we're discussing on this thread and codified the best solution in the language. There are solutions in CL for problems that we haven't even encountered yet. The less closely we follow CL, the less we benefit from the experience baked into the specification and the harder it is to fix problems that eventually do come up. --MWu1O1U4xuPektOgLbfpCniex0DUUxd9h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTVfRCAAoJEMAaIROpHW7IHaAP/1mvJ5pHJl8pv6s0/uAMk7+v KG9DvUnaAJlTd7vdN7G8kcUylUJq1INpTGd49qsqkkwxERvz2gqJqZfJibNr1/HE 6bEDuX2opc1eagcAQw/rmI781KPdGzhlMhakiPU+4hisGfphRQHi82UtoCPfjFT2 99w5IlPRvrfQRsjFSijmnS6ydlwyZdY403tiNYOSOC5DvUcCx9GDDkH3x+l2cfCV O/wgPxkrD9DwldMsHfIgvpXqVh+fKiexytoEMbJRzr6aZfQ8PQsvpxgAsBt4Uz7f vEwYaTbUGfxdQ6tW9+LtepcfwCI93kzOD7RI61Biz319AmBBCnz20MJrwmtPZ7hm 7A3JJaB5SRWGLEwFKkM03qYggWv7umcY9x7LRn/Dq6Yp6mwCYOSZIzPZfB5FsEQg 2fNNlTDIoxe4U4F1/fNt6iTwVZ2I1SkGflBuf15ErXeYtILkXIywlRC6+4RaRcad 98M680TV8vOHcGk1lB11JzOopFei1BZqr4hJapnLJick7nbBkdsQlX2SlYl1etqD 5qxq7mDev2R+9ZW8NKk4TW7vEYZri0BQAQ98hkSGEpG7o9QElq7dET9rQSwrU4KZ dqpPAXIHHj2hfKe4Hcw2tDr6alubHwGdAjLvyOAWB3zb1wODheE56GqEz+lFZ9aD gcK8I4VglD5lMhebEm7b =dD6U -----END PGP SIGNATURE----- --MWu1O1U4xuPektOgLbfpCniex0DUUxd9h--