Re: Markup module patch (Issue 2026)

[Ian Hulin]

On 16/12/11 18:07, David Kastrup wrote:
> Ian Hulin <address@hidden> writes:
> 
>> Because this means serious fiddling with the maoing markup code.
>> I really hope you didn't write it because I agree with David,
>> it's a fetid pile of Dingo's kidneys to maintain, and I fear
>> it'll take me a lo-o-o-ong time and much cursing and swearing to
>> change it.
> 
> I actually extended it somewhat at one time.  I have stated on this
> list that I hate working with C++ and am working hard to make it
> possible to avoid that.  As a result, you'll see that the vast
> majority of my work is on the C++ code base.  In a similar vein,
> you will find my handwriting in the markup code.  But I did not
> start it.
> 
No finger-pointing intended.  I'm just frustrated that this rather
brittle subsystem is holding up progress on what I really want to work
on (i.e. fixing issue 2026 so I can crack on with completing 1686.

> If #{ \markup ... #} were evaluated at compile time, I would
> likely already have set out to obliterate the markup macro
> altogether and we would not be slashing with knives at each other
> for the sake of not needing to touch this code implementing its own
> language and system between LilyPond and Guile ever again.
> 
Seconded, but knives?  I do hope it hasn't got *that* unfriendly.
It's more like a game of "hot-potato voleyball". I'm trying to get
away with changing as little of the markup code internals as I can.

>> It'll mean trying to find a way of getting
>> compile-markup-expression to look in a list both in the current
>> module, and then falling back to the (lily) module (where all the
>> base code markup commands from define-markup-commands.scm will
>> be) before failing the validation.
> 
> Can you explain what modules have to do with it?  You make it sound
> as if every source file needed to end up in its own module except
> when taking special measures.  That sounds quite inconvenient for
> working with projects distributed among multiple Lilypond files.
> 
Lilypond scoping is implemented using the Guile module system. Each
new Lilypond scope is declared as an anonymous Guile module, and we
use special code provided by Guile V2 (module-export-all!) which we
emulate for Guile V1.8 by declaring it in lily.scm (the Guile team
actually supplied us with the code as we were doing it before in a
rather under-the-counter unsupported manner).  This is done in code by
routine ly_make_module in ly-module.cc using a undocumented Guile
routine make-module.