lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Data structure for (package) options


From: Urs Liska
Subject: Re: Data structure for (package) options
Date: Tue, 28 Jan 2020 15:06:31 +0100
User-agent: K-9 Mail for Android


Am 28. Januar 2020 14:48:54 MEZ schrieb David Kastrup <address@hidden>:
>Han-Wen Nienhuys <address@hidden> writes:
>
>> On Mon, Jan 27, 2020 at 11:39 PM Urs Liska <address@hidden>
>wrote:
>>>
>>> I didn't have time to really think about much (about LilyPond) the
>past
>>> week, just enjoyed seeing so much constructive discussion.
>>> [..]
>>
>> I haven't read your messages in detail, but I'd like to throw out one
>> thought to consider: we use GUILE modules as a mechanism for
>> identifier namespacing (\paper, \header all create modules). I think
>> it might be useful if we could provide a LilyPond native mechanism
>for
>> packaging that declares a namespace implicitly, eg.
>>
>>   \module "edition" {
>>       internal = ...
>>       addTweak  = ...
>>   }
>>
>>   \import edition.addTweak
>>
>> that would let you define constructs in a package that doesn't
>pollute
>> the global namespace, and let .ly packages control explicitly what
>> symbols they want to use.
>>
>> I think we should aim to avoid textual inclusion as a mechanism that
>> powers packaging.
>
>At the implementation side, "textual inclusion" will be what has to
>power systems where one can "plug in" packages and have them work by
>being present.  Even Guile's use-modules mechanism works at that level.
>But of course that doesn't mean that we want \include as a user-level
>access method in the long haul.
>
>It's likely that a typical more complex package may consist of both .ly
>and/or .scm components and that is an implementation detail that a
>package user should not need to bother about, and that hopefully should
>not significantly complicate things for people wanting to provide
>packages with either or both .ly and/or .scm components.

From my experience with OLL it would sesm reasonable to have all packages use 
.ly files as entry point. From there they can use Scheme modules if they need 
to. OLL does some work to add its root to the guile path, so there's the way to 
use modules relstive to the package.

Urs


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]