Re: unhandled constant?

[David Kastrup <dak@gnu.org>]

Han-Wen Nienhuys <hanwenn@gmail.com> writes:

> On Sat, Feb 1, 2020 at 11:11 AM David Kastrup <dak@gnu.org> 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 #<directory (guile-user) 56514b591140>
>> >>
>>
>> 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
> #<procedure ... > "

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