From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Thoughts on the buffer positions in the byte compiler's warning messages. Date: Sun, 18 Sep 2016 20:21:46 +0200 Message-ID: References: <20160918152303.GA3576@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1474222950 1893 195.159.176.226 (18 Sep 2016 18:22:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Sep 2016 18:22:30 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 18 20:22:26 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1blgjP-0008Ap-4C for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 20:22:23 +0200 Original-Received: from localhost ([::1]:51126 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blgjN-0005NU-Dx for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 14:22:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blgjH-0005N9-5B for emacs-devel@gnu.org; Sun, 18 Sep 2016 14:22:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blgjD-0004Yh-3z for emacs-devel@gnu.org; Sun, 18 Sep 2016 14:22:15 -0400 Original-Received: from [195.159.176.226] (port=53216 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blgjC-0004Um-T1 for emacs-devel@gnu.org; Sun, 18 Sep 2016 14:22:11 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1blgix-00057m-5a for emacs-devel@gnu.org; Sun, 18 Sep 2016 20:21:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 43 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:oMHyVsQgrNSput1c6A76AGVkUg4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:207577 Archived-At: On Sun, Sep 18 2016, Alan Mackenzie wrote: > After the reader has produced the form to be compiled and > read-symbol-positions-list, we combine these to produce a @dfn{shadow > form} with the same shape as the form, but where there's a symbol in the > form, there is a corresponding list in the shadow form, noting the > corresponding "position" in the form, and onto which warning/error > messages can be pushed. These can then be output at the end of the > compilation. It would be problematic to pass such shadow-forms to macros because macros would be confused if they see artificial lists where they expect symbols. After macro expansion that's no longer a problem and the compiler can use any representation that is convenient. So, instead of replacing symbols with lists, I would attach the position to cons cells (stored in an auxiliary hashtable with the cons as key). (Remember that in Lisp code almost every symbol is stored in the car of of a cons.) > Comments? First, I would look at CMUCL or Clozure CL for inspiration. Those compilers produce fairly accurate source location information and also have the problem that they need to pass "vanilla" forms to macros. (Scheme compilers use "syntax-objects" instead of vanilla forms, so there's probably not much to learn there.) Second, instead of (or in addition to) recording the position of symbols in read-symbol-positions-list I would record the start and end position of lists ie. the READ function should record the position of "(" and the corresponding ")" for each list. Third, MACROEXPAND should record source forms so that the compiler can list all forms (and positions) that eventually generated the fully expanded form. Fourth, for very sophisticated macros there should probably be some API beyond MACROEXPAND so that macros can help the compiler to track source positions. Helmut