[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: get rid of ly:export
From: |
Ian Hulin |
Subject: |
Re: Proposal: get rid of ly:export |
Date: |
Sun, 06 Nov 2011 16:30:51 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 |
Hi David,
(see below)
On 06/11/11 09:43, David Kastrup wrote:
>
> Hi,
>
> I've been annoyed in the past by the presence of ly:export since
> it creates timing problems in the parser and lexer. I propose
> completely removing it. As a replacement in the rare situations
> where it might be applicable, I propose moving the $ syntax, now
> only used inside of #{ ... #}, to Lilypond in general, in order to
> indicate auto-export at the direct lexical level where it makes
> sense.
>
> So that #{ ... #} would still be able to access music function
> variables inside, it would inherit the lexical environment of its
> encompassing definition.
>
> This would imply that #{ ... #$argument ... #} would _cease_
> working. Instead you would have to write #{ ... #argument ... #}
> in order to get a Scheme argument. But at least #{ ...
> #$defaultpaper ... #} would work the same in #{ ... #} as outside.
>
> If ly:export is removed, we can split the work of #( ... ) into two
> phases: at the lexical stage, the expression is read. While
> parsing, it is evaluated. In that manner, we get rid of
> synchronization problems.
>
> In contrast, $ would read and evaluate in one piece. As one
> benefit, we would get rid of errormessages involving
> \lilytmpvarxxxx pseudovariables.
>
> This change would definitely cause problems to existing code.
> Automatic conversion seems only semi-feasible.
>
> But it would give $ straightforward semantics everywhere (it would
> carry a meaning always in Lilypond, never in Scheme). And removing
> ly:export, which requires messing up the logical order and timing
> of lexing/parsing, would be a definite improvement, while still
> providing its functionality in a non-obscure way.
>
The main thing you'll need to look at for possible side-effects is the
coding of the tagline in scm/titling-init.ly, as this is potentially
used by default in any LilyPond compilation. Here's the stuff from
scm/titling-init.ly.
tagline = \markup {
\with-url
#"http://lilypond.org/"
\line {
%% 2014 = em dash.
#(ly:export
(format #f "Music engraving by LilyPond ~a~awww.lilypond.org"
(lilypond-version)
(ly:wide-char->utf-8 #x2014)
))
}
}
If as part of this patch you can re-code so we don't have to use this
nonsense, so much the better, it's a major PITA for Guile V2 migration
as it crashes Guile in phase 2 of LilyPond initialization and I can't
yet see why.
Cheers,
Ian