Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)

[address@hidden]

On 24 déc. 2012, at 01:10, address@hidden wrote:

> All of this is absolutely devastatingly horrible code that is not
> reconcilable with sane per-session semantics and tampers with LilyPond
> internals in a way that has bleed-over effects into future files in the
> same command line.
> 
> In addition, the interfaces into the exposed internals are absolutely
> horrific and cryptic and don't make any sense as a user interface.
> 

I agree that the innards I'm exposing are not coded particularly well - there 
is a lot of glue code in Scheme just to get the machine running.  I would 
rather take the time now to clean that code up and get it so that users can use 
it (that has been a frequent request) if that is what people think should be 
done.

> This is taking everything that is broken with
> input/regression/scheme-text-spanner.ly, magnifies it to a number of
> other cases, and gives it a bad interface.

I am of the opinion that it is better to have stuff like this that allows 
people to do creative and interesting things with LilyPond than not have it at 
all.  This is something that several users have asked for.  I do not mind, 
however:

1) putting a caveat that it is subject to change or bad code.
2) working on the code so that it gets better.

What would be most helpful from you are constructive comments on how to make 
the patch better, which you are doing below and I appreciate.  More are welcome.

> 
> No, no, and no again.  Extensibility in this area would be nice, but
> pulling out LilyPond's innards into the public without a proper design
> is no substitute for that and totally a step in the wrong direction.

I disagree.  Proper design is important, but people who use LilyPond want this. 
 I don't believe in withholding a capacity from people just because its design 
has problems.  Yes, let's improve the design, but let's get it out there.  If 
anything, that will allow people to poke at it, see where it fails, and give us 
the opportunity to make it better.  We can refine the regtest over time to be 
whatever we think it should be.

> None of these ad-hoc interfaces can sensibly be guaranteed to survive
> any evolution of LilyPond's operation since they don't interface to
> functionality, but rather to the current internals.

So then let's make the functions and regtest better over time instead of not 
releasing it at all.  If LilyPond's imperfect were a criteria for not making it 
available to the public, no one would have ever used any of it back in the day 
and we would not be having this discussion.

> 
> If people want to poke LilyPond's internals with a stick, of course they
> can do so with all bad side effects including everything breaking
> possibly on the next update.  But there is no point giving them a stick
> with a handle for that if there is no way in which we can guarantee the
> handle working for longer or better than the stick does.

We can guarantee this by fixing it when and if it breaks, like everything else. 
 I think it's important to have the feature first and make it perfect later.

So what I need from you, if you're willing to help me out, are explanations of 
how this causes bleedover effects.

> 
> 
> https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly
> File ly/property-init.ly (right):
> 
> https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly#newcode682
> ly/property-init.ly:682: defineEventClass =
> Absolutely awful interface here.  No.

Helpful suggestions appreciated.  Again, I think it's better to have a bad UI 
than not have one at all.  At least it is a start, but of course I want to make 
it as good as possible in this first round.

> 
> https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
> 
> https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode2695
> scm/define-grobs.scm:2695: (define (register-grob-name x)
> No.  This is an interface with heavy session bleedover characteristics:
> as long as a symbol is not garbage-collected (for example, because it is
> referenced anywhere as a symbol in a totally non-grob context), it will
> remain defined between sessions.
> 

How can we force it to be garbage collected at the end of a session?

> First the internals need to be redefined in a manner allowing for sane
> per-session behavior before any exposed public interface is offered for
> that.
> 
> https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode2703
> scm/define-grobs.scm:2703: (completize-grob-entry x))
> No, this will cause heavy bleedover effects between sessions.

How do I fix this?

> 
> https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm
> File scm/define-music-types.scm (right):
> 
> https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm#newcode758
> scm/define-music-types.scm:758: (define-public (make-music-descriptions
> descriptions)
> Unsuitable for a public interface because of session bleedover.

How do I fix this?

What would help is a sort of mark-for-garbage-collection-at-end-of-session 
function.  Does that exist?

Cheers,
MS