Re: Scheme pattern for retrieving data in objects

[Jonas Hahnfeld]

To add my 2 cents here, bearing in mind that I mostly care about
LilyPond's Scheme code instead of user code in scores:

On Sat, 2022-04-02 at 13:38 +0200, Han-Wen Nienhuys wrote:
> On Fri, Apr 1, 2022 at 6:43 PM Jean Abou Samra <jean@abou-samra.fr> wrote:
> > [...]
> > 
> > Does anyone find a value in defining a macro for this?
> > 
> > \version "2.23.8"
> > 
> > #(define-syntax-rule (fetch obj getter (sym ...) body body* ...)
> >     (let ((evald-obj obj)
> >           (evald-getter getter))
> >       (let ((sym (getter obj 'sym))
> >             ...)
> >         body body* ...)))
> > {
> >    c'1
> >    \tweak after-line-breaking
> >      #(lambda (grob)
> >         (fetch grob ly:grob-property (left-bound-info)
> >           (fetch left-bound-info assoc-ref (common-Y X padding attach-dir)
> >             (ly:message "common-Y=~a X=~a padding=~a attach-dir=~a"
> > common-Y X padding attach-dir))))
> >    \startTextSpan
> >    c'1\stopTextSpan
> > }
> 
> It's shorter, but is it easier to understand and discover? Is the
> former code (which is somewhat verbose) a real barrier to getting
> coding/typesetting done?

It's actually not a lot shorter, the characters it saves are that the
variable name is identical with the fetched attribute. Which is my
biggest pain point about the proposed macro, because as soon as you
want to or need to name the variable differently (think about naming
elements as children), you cannot use the macro anymore and have to
revert back to the "known" function call. IMHO the bad thing here is
that there are two ways to achieve the same operation, with the new
proposed macro being less powerful.

For my second point, I agree with Dan that defining multiple variables
in one go looks bad, especially in this non-obvious way.


Jonas

signature.asc
Description: This is a digitally signed message part