From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: conditional code segments Date: Fri, 01 Jun 2018 21:56:36 -0400 Message-ID: <87d0xadk8b.fsf@netris.org> References: <78397a0b-139c-de1a-2cbf-2458088e1952@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1527904578 24138 195.159.176.226 (2 Jun 2018 01:56:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2018 01:56:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-user@gnu.org To: Matt Wette Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Jun 02 03:56:14 2018 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 1fOvm9-00069z-6x for guile-user@m.gmane.org; Sat, 02 Jun 2018 03:56:13 +0200 Original-Received: from localhost ([::1]:58067 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOvoF-0002PL-TU for guile-user@m.gmane.org; Fri, 01 Jun 2018 21:58:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOvnn-0002PG-8D for guile-user@gnu.org; Fri, 01 Jun 2018 21:57:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOvnk-000584-6n for guile-user@gnu.org; Fri, 01 Jun 2018 21:57:55 -0400 Original-Received: from world.peace.net ([64.112.178.59]:45998) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fOvnk-00057S-2J for guile-user@gnu.org; Fri, 01 Jun 2018 21:57:52 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fOvni-0005nn-PE; Fri, 01 Jun 2018 21:57:50 -0400 In-Reply-To: <78397a0b-139c-de1a-2cbf-2458088e1952@gmail.com> (Matt Wette's message of "Fri, 1 Jun 2018 16:37:10 -0700") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.112.178.59 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:14598 Archived-At: Hi Matt, Matt Wette writes: > In C I can use `#ifdef' .. `#endif' to "comment out" code segments. > > In Scheme, one can use `#|' and '|#' which is OK but requires dealing with both ends of the > segment to switch on / off. And emacs (v 24.5) scheme mode does not always fontify the buffer > correctly with #|...|#. There's another kind of comment in standard Scheme (both R6RS and R7RS) that's supported by Guile, but unfortunately it doesn't seem to be documented in our manual. Simply put the two characters "#;" before any datum, and the entire datum will be skipped by the reader. Whitespace may appear between "#;" and the datum. So, for example: #; (let () ...) will cause the entire 'let' form (which is a datum) to be skipped. Emacs and paredit understand this syntax, and will act accordingly. It works not only at top-level, but also nested arbitrarily deeply within datums. So, for example: scheme@(guile-user)> (let () (display "1\n") (display "2\n") #; (display "3\n")) 1 2 scheme@(guile-user)> and if you put that code in an Emacs buffer in Scheme mode, the (display "3\n") will be colorized as a comment, but the final closing parenthesis will have the default color. > I tried using cond-expand but it does not work as expected: > scheme@(guile-user)> (cond-expand-provide (current-module) '(abc)) > $1 = (abc) > scheme@(guile-user)> (cond-expand (abc #t)) > While compiling expression: > Syntax error: > unknown file:2:0: cond-expand: unfulfilled cond-expand in form (cond-expand (abc #t)) It didn't work because when a 'cond-expand' form is used in module FOO, it looks for the features (e.g. 'abc') in all of the modules that are imported by FOO, but not in FOO itself. Mark