Re: Should we be touching goops?

[David Kastrup]

Jean Abou Samra <jean@abou-samra.fr> writes:

> Le 05/06/2022 à 14:13, David Kastrup a écrit :
>> git grep 'ly:moment-\(add\|sub\|mul\|div\|mod\)'
>> puts out a good page or so, much of it in articulate.ly and swing.ly.
>> Admittedly, both of those files are of the kind we would want to
>> encourage people to write, and that kind of change makes it more
>> convenient.
>
>
>
> Sorry, my 'something' was meant to refer to introducing
> a distinction between time points and time spans. (Like you)
> I'm not convinced by the benefits of doing that compared
> to all the churn of converting the code base and asking users
> to convert their own Scheme code: I am not seeing operations on
> moments that have no 'physical' meaning being a significant source
> of actual bugs in our tracker (or a source of any bugs at all).
>
> Independently, I have not understood how this topic relates
> to the original topic of this thread, namely spelling operations
> of Moment and possibly other types with standard + - * /
> overloaded via GOOPS rather than via dedicated functions.

Right, let me refocus.

Indeed this discussion has gone a bit all over the place.  I think the
point/span distinction for uses of Moment has been on Dan's mind for a
longer time before.  Introducing arithmetic by operator has the
potential to tilt the table in a direction that isn't favorable to the
way he'd rather see things move, so he revoiced his concerns.

Something like ly:moment-add has fewer implied semantics than + .  Not
just for humans (who expect + to be more-or-less commutative and
associative even though the latter is only approximately the case with
floating point arithmetic) but even for Scheme which extends a two-term
definition of + into + with an arbitrary larger amount of summands.

This would make it harder to argue the kind of semantics that Dan finds
more appropriate to implement over what we have now.

While I agree with Dan that at the current point of time Moment is
definitely overloaded too much (this has historical reasons since it had
been the _only_ Scheme-accessible version of the Rational type, with
Rational being required before Guile gained its own implementation of
rational numbers), we disagree about where to draw the lines and how
many of them.

Our differences were mostly based on different philosophies about what
constitutes clean programming and what constraints that should imply for
users of LilyPond.

A rich field for tangents.

-- 
David Kastrup