From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: David Kastrup Newsgroups: gmane.comp.gnu.lilypond.devel,gmane.lisp.guile.devel Subject: Re: unhandled constant? Date: Sat, 01 Feb 2020 12:36:45 +0100 Message-ID: <8736buwnci.fsf@fencepost.gnu.org> References: <8d77f905-31e9-4d0b-973a-82be38360e07@www.fastmail.com> <07e36ec2-0c0c-4786-9040-ffcb3418e0bb@www.fastmail.com> <87blqiwrbo.fsf@fencepost.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="56550"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: guile-devel@gnu.org, lilypond-devel To: Han-Wen Nienhuys Original-X-From: lilypond-devel-bounces+gnu-lilypond-devel=m.gmane-mx.org@gnu.org Sat Feb 01 12:36:55 2020 Return-path: Envelope-to: gnu-lilypond-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ixr55-000Ea5-Ku for gnu-lilypond-devel@m.gmane-mx.org; Sat, 01 Feb 2020 12:36:55 +0100 Original-Received: from localhost ([::1]:45268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixr54-0000ki-Mu for gnu-lilypond-devel@m.gmane-mx.org; Sat, 01 Feb 2020 06:36:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35904) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixr50-0000kY-T4; Sat, 01 Feb 2020 06:36:52 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ixr4z-0007tJ-N8; Sat, 01 Feb 2020 06:36:49 -0500 Original-Received: from x2f45ef2.dyn.telefonica.de ([2.244.94.242]:35900 helo=lola) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ixr4x-0002Zs-Ub; Sat, 01 Feb 2020 06:36:49 -0500 In-Reply-To: (Han-Wen Nienhuys's message of "Sat, 1 Feb 2020 12:23:51 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: lilypond-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions on LilyPond development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lilypond-devel-bounces+gnu-lilypond-devel=m.gmane-mx.org@gnu.org Original-Sender: "lilypond-devel" Xref: news.gmane.io gmane.comp.gnu.lilypond.devel:72491 gmane.lisp.guile.devel:20370 Archived-At: Han-Wen Nienhuys writes: > On Sat, Feb 1, 2020 at 11:11 AM David Kastrup wrote: >> >> Here is an example that shows better how things work, and what might >> >> be the cause of my problems. Is it right that programmatically set >> >> contents of "current-module" are not serialized into the compiled >> >> file? >> >> >> >> (define (run-at-compile-time cmd) >> >> (module-define! (current-module) (string->symbol cmd) #t) >> >> (format (current-error-port) "I-am-called-at-compile-time ~a\n" cmd)) >> >> >> >> (define (runtime-call cmd) >> >> (format (current-error-port) "I-am-called-at-runtime ~a\n" cmd) >> >> (format (current-error-port) "val ~a\n" >> >> (module-ref (current-module) (string->symbol cmd)))) >> >> >> >> (defmacro foo (cmd . rest) >> >> (run-at-compile-time cmd) >> >> `(runtime-call ,cmd)) >> >> >> >> (foo "xy") > .. >> >> ERROR: In procedure scm-error: >> >> No variable named xy in # >> >> >> >> But that is not using a local define at all. Can you point out the >> actual code that failed for you? > > There are two independent problems. One is a problem with inner > defines, which is addressed by > > https://codereview.appspot.com/553480044/ > > the symptom is compilation failing with "unhandled constant > # " Ah, ok. This appears not to signify that anything is wrong with the code in principle but rather that the byte compiler is not sufficiently capable for processing it. > The other is a problem you can reproduce if you check out > > https://github.com/hanwen/lilypond/tree/guile22-experiment > > with the symptom being: > > ;;; compiling > /home/hanwen/vc/lilypond/out/share/lilypond/current/scm/define-markup-commands.scm > fatal error: Not a markup command: line > > This is because the LilyPond macro "markup" doesn't recognize markup > command and aborts in code that is executed at compile-time. The code > that triggers this are definitions in scm/define-markup-commands.scm > that use (mark #:blah .. ) in the function body. The LilyPond macro "markup" is something I would not mind getting rid of sooner rather than later. It's sick. It is not completely clear to me why it needs the actual definitions to work with, but it may have something to do with its partly workable support of markup list commands. The make-...-markup convenience functions are quite more sane. Stacking a lot of them together may incur a bit of runtime overhead since they do argument checking that the results from markup macro expansion don't. But markup command processing times are likely quite negligible in the total scheme of things even if we end up rechecking large markup lists as they are passed from one function to another. > You can verify this by rewriting > https://github.com/lilypond/lilypond/blob/c5ffa540fdbe52486b9575567ede70be575adb47/scm/define-markup-commands.scm#L305 > and seeing how the error message changes. > > I still don't understand why some code is executed compile time (the > expansion of the markup macro) while other is not (defining the > make-x-markup function in (current-module)) > > Since we recognize markup commands by looking them up in > (current-module), I believe the example I showed here shows that we > can never make this work, and we will have to revisit the markup > macros completely. My vote is on throwing them out. But that would affect a whole bunch of user-level programs. We could add a macro _function_ that does the hard work at execution time rather than at expansion time as a backwards compatibility measure, and discourage using it for new code. -- David Kastrup