Re: "loco" after ottava

[Thomas Morley]

Am Sa., 3. Dez. 2022 um 16:56 Uhr schrieb Jean Abou Samra <jean@abou-samra.fr>:
>
> Le 03/12/2022 à 15:41, Thomas Morley a écrit :
> > Granted, if I use -dcheck-internal-types I mostly wear my developer
> > hat. But sometimes I use it even for huge custom codings as part of
> > debugging processes.
>
>
>
> Why? What does it catch?

It catches what you describe below.
Call me a perfectionist, applying it to my custom codings.

>
> In my view, warnings about a property being set on a grob
> that has no interface for it are nothing you need to care
> about as a user. This check merely helps ensuring that the
> IR remains complete when developers add features. I see no
> reason why it would be bad to set a property on a grob even
> if it doesn't have an interface declaring this property,
> if you set another property in this grob to something that
> will read it. For example, it's a common pattern to set
> stencil to #ly:text-interface::print and text to some markup,
> even on grobs that don't have text-interface. That's fine.
> On the other hand, if you change the stencil default for
> a given grob to #ly:text-interface::print in the source,
> you shouldn't forget to add text-interface to that grob.
>
> The other thing check-internal-types catches is callbacks
> returning a value of the wrong type, but I have never
> encountered this case AFAIR.

>
> > Also, hiding internal things from mere users would arguable lead to a
> > very small IR.
> > We could just delete all internal grob and context properties.
> > Which would be a very bad thing, if I think back how often I used them...
>
>
>
> I view internal properties and internal options differently.
> LilyPond has a blurry line between users and developers.

Yep.

> "Internal" for properties draws a line between advanced users
> and other users. Internal properties are thing that you can
> use if you know how to use them from Scheme and (like many
> Scheme things) accept the lesser degree of stability that
> you can expect from them.

Agreed.

> In contrast, for me, the options
> currently listed as "internal" really only make sense if
> you are a contributor working on the source, e.g.,
> debug-gc-assert-parsed-dead catches low-level garbage
> collection problems, debug-parser is only useful if you
> know your way around the Bison / C++ parser, etc.

I will not object to the examples you mentioned.
Alas, if -dcheck-internal-types detects something in my custom code, I
feel the need to fix.
Feels not clean otherwise.
But that's probably only me...

Best,
  Harm