I am writing a patch (related to all the recent talks on font selection) where I want to have `grob-interpret-markup` written in C++. I can of course define it with LY_DEFINE, except that this makes it named ly:grob-interpret-markup instead.
I can do
(define-public grob-interpret-markup ly:grob-interpret-markup)
like we already have for assoc-get aka ly:assoc-get, but it seems
clumsy.
grob-interpret-markup is widely used. Renaming it only because of this
would be a pity.
Having ly: or not mostly distinguishes functions implemented in C++ from
functions implemented in Scheme (though a few Scheme-defined ones have
ly: too), but that distinction is not very relevant from the user point of
view. And I've heard about people confused about ly:markup? not working
in music function signatures.
Any thoughts on the following options?
1. Keep existing functions as they are, but allow new C++ functions to
be defined without this prefix.
2. Remove the ly: prefix from C++ functions. Avoid breaking the world
by doing the equivalent of
#(use-modules (lily)
((lily) #:prefix ly:))
which makes *all* functions (including those defined in Scheme) available
both with and without ly: prefix.
We would need to rename those few for which both a ly: and a non-ly:
variant exist (I'm thinking about
(ly:)side-position-interface:y-aligned-side.)
Also, we would need to decide whether we rewrite our own base
of Scheme code to remove those 'ly:'s. I'm not really looking
forward to doing that, especially while I'm busy with fonts,
so I am unlikely to work on it myself in the immediate future at
least.
signature.asc
Description: This is a digitally signed message part
