From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jan Nieuwenhuizen Newsgroups: gmane.lisp.guile.user Subject: Re: nyacc 0.73.0 released Date: Sun, 01 Jan 2017 13:32:36 +0100 Organization: AvatarAcademy.nl Message-ID: <87ful3arkr.fsf@gnu.org> References: <87d1gfcfnm.fsf@gnu.org> <87r34ob2wc.fsf@gnu.org> <57B2C5AB-DDE6-4B0E-9D9F-A45C6B34ED51@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1483274016 11708 195.159.176.226 (1 Jan 2017 12:33:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jan 2017 12:33:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guile-user@gnu.org To: Matt Wette Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jan 01 13:33:31 2017 Return-path: Envelope-to: guile-user@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 1cNfKM-00021N-UE for guile-user@m.gmane.org; Sun, 01 Jan 2017 13:33:31 +0100 Original-Received: from localhost ([::1]:53079 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNfKP-00064b-Bc for guile-user@m.gmane.org; Sun, 01 Jan 2017 07:33:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNfJq-00062N-KV for guile-user@gnu.org; Sun, 01 Jan 2017 07:33:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNfJm-0000Zk-M6 for guile-user@gnu.org; Sun, 01 Jan 2017 07:32:58 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNfJY-0000Tb-RU; Sun, 01 Jan 2017 07:32:40 -0500 Original-Received: from peder.onsbrabantnet.nl ([88.159.206.46]:60496 helo=dundal.peder.onsbrabantnet.nl) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNfJY-0007fS-7v; Sun, 01 Jan 2017 07:32:40 -0500 X-Url: http://AvatarAcademy.nl In-Reply-To: <57B2C5AB-DDE6-4B0E-9D9F-A45C6B34ED51@gmail.com> (Matt Wette's message of "Sat, 31 Dec 2016 16:04:24 -0800") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13072 Archived-At: Matt Wette writes: Hi Matt! >> Also, it seems like it doesn't like it if an #includ'ed file is meant to >> go inside a function, like (simplified example) > So this is a bug. And I am not sure how to proceed yet. The parser > was designed to return a AST with code from includes under a subtree. > This allows a file to be processed with respect to code only in that > file. The way it works is to parse the included file as a new parse. > That only works at the top level. This breaks for files included > inside functions etc. That makes sense. > How are you processing the file? Do you want to be able to > discriminate between a file and the included files, and only if > included files are at the decl level (e.g., #include ) but > code inside functions gets included as is (i.e., the AST looks as if > the code was in the parent file)? For a user, best is to have error messages that point to the file+line where the actual code is; so in each case the included file. Gcc's cpp always adds # "" markers; it makes no difference where the file is included. What I am currently doing, is generate lists of symbol declarations and definitions by snarfing the original mes.c file. The declarations are included at toplevel, which is fine. The definitions go inside functions. So for my specific use case it does not really much either way, although having correct file:line:message error messages is nice. ;-) > This will take some sort of parser-lexer hook I think. I want to > think about a clean architecture for all the use cases. Sure. Greetings, Jan --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.nl= =20=20