Aaron Hill <[email protected]> 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
