Re: Should we be touching goops?

[David Kastrup]

Aaron Hill <lilypond@hillvisions.com> writes:

> On 2022-06-06 5:24 pm, David Kastrup wrote:
>> Putting a bit more meat on what this may mean:
>> <https://gitlab.com/lilypond/lilypond/-/merge_requests/1404>
>
> This certainly lends some brevity being able to use operators rather
> than named procedures.  Providing all this is firstly correct and
> secondly reasonably performant, it seems like a good addition.
>
> That said, I did find one surprise looking at [1].  I would not have
> expected 1+ (increment) to work without some way of Scheme knowing how
> to construct unity for a given type.  Am I just overlooking where such
> a <Moment> is being specified?  Or is there supposed to be a
> type-specific overload of 1+?  I am worried something might not have
> gotten committed.
>
> [1]:
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1404/diffs?commit_id=bafd55131495ad58d8c9eb4439f60c8789bc9dc8#98b870cc087eeb4becf470fa3ec9b05b85962f2f_115_109

1+ works on a plain number here.

(define-method (/ (a <Moment>) (b <Moment>)) (ly:moment-main (ly:moment-div a 
b)))

I saw no point in letting the division of Moments deliver a Moment like
ly:moment-div does, so ly:moment-main fetches the resulting rational.
Returning a Moment would be just meaningless.  While I objected to
distinguishing time spans from time points by type, that does not mean
that I am in favor of completely insane type relations for new
functionality.

What may actually be a surprising simplification is
<https://gitlab.com/lilypond/lilypond/-/merge_requests/1404/diffs?commit_id=bafd55131495ad58d8c9eb4439f60c8789bc9dc8#98b870cc087eeb4becf470fa3ec9b05b85962f2f_224_213>


-- 
David Kastrup