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

[dak]

On 2012/12/24 07:28:17, mike7 wrote:

> On 24 déc. 2012, at 01:10, mailto: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

You don't get the point.  A user interface is not supposed to "expose
innards", it is supposed to provide functionality.  Pulling data
structures and some of the code accessing them into the open is not a
user interface.

> > 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.

But those "creative and interesting things" will break frequently on
update.  We already have quite a bit of "why doesn't this stuff I
based on [some version of] scheme-text-spanner.ly not work in my
version of LilyPond?" questions.

> This is something that several users have asked for.

But this does not give it to them.  It is just a teaser which we'll
take away again.  It is bad enough if we have teasers in
input/regression.  Teasers don't belong in LilyPond proper.

> > 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.

People who use LilyPond want some parts of LilyPond to be extensible.
This is _not_, I repeat _not_ what your patch does.  It just pulls
some internals from LilyPond's non-extensible parts into the open.

It is like pulling some wires into the passenger room of a car that
you can short-circuit for stiffening the dampeners and say that
drivers want this.  It will cause explosions when the gas runs low
when using this, but it is better to have this now than later.

There is some correlation to the desires of drivers, yes.

> I don't believe in withholding a capacity from people just because
> its design has problems.

Mike, there is no design.  It is not that the "design has problems",
it is that you did not even bother with designing a user interface.
It is just wires sticking out, and it is wires to something that was
never intended to be shorted.

> 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.

Mike, that is crap.  If a programmer can't be bothered designing a
user interface, how can "people poking at it" replace that?  How can
they better understand what is at issue than the programmer who could
not be bothered creating an actual interface?  For one thing,
incrementally patching things up wherever they break is no substitute
for design.  For another thing, that can only incrementally _mask_
"broken by design" but can never fix it.

> We can refine the regtest over time to be
> whatever we think it should be.

We have that approach with scheme-text-spanner already, and it is a
continuing embarrassment to tell people "Uh, this will most certainly
not continue working in future versions.  It broke already for you?
Tough."

> > 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.

Mike, you don't even try to understand what I am saying.  The point of
an interface is not to make it "better over time".  An interface is
not supposed to change all the time.  When we provide an interface, it
needs to be better than sawing off the hood of a car so that people
can reach into it from the driver's seat.  People _can_ already open
the hood and poke around, but there is no guarantee that all the
details will be in the same place with the next iteration.

> > 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.

You can't "fix" a thin wrapper, nay merely a coating of internals when
the internals change into something more generally useful.  If this
coating is supposed to be an "interface", you can't change the engine
any more.

> I think it's important to have the feature first and make it perfect
> later.

But you are not providing a feature.  You are just providing access to
the engine.  And if poking around in the engine without any provision
of consistence and continued operation is the goal, that can already
be done.

At the current point of time, LilyPond is not designed for supporting
this kind of extensibility.  Every "interface" designed as a thin
wrapper will break in future versions.


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?

_Everything_ is garbage collected continually, and particularly at the
end of a session.  However, every symbol that is compiled somewhere
into the LilyPond code base is not garbage.  Putting this kind of data
as _object_ properties on symbols is fine when one is certain that the
data should stay around indefinitely.

It is unsuitable for per-session data.  By design.  So we need to
change this mechanism to something else before we offer to change this
to per-session.  Since there was no actual interface before, every
code poking around in these object properties of symbols on its own
initiative previously will break.  That's not nice, but then there was
no guarantee or reasonable expectation that our internals would stick
around in the same manner.

And we should not start giving them coatings suggesting otherwise when
we know that they can't work reliably for the purpose we are selling
them for.

> What would help is a sort of
> mark-for-garbage-collection-at-end-of-session function.

Object properties stick around as long as their objects do, and
whether a symbol is used/mentioned somewhere in existing code for
whatever purpose that might not be related to use as a user grob or
event name is an open bet.

This needs to move from symbol object properties to some more reliably
resettable data structure _before_ one can sensibly offer a user-level
interface for it.


https://codereview.appspot.com/7009047/