Re: define-markup-function problem

[Carl D. Sorensen]

On 1/29/09 7:12 AM, "Kieren MacMillan" <address@hidden>
wrote:

> Hi Carl,
> 
> So we have the following, which all work:
> 
> #(define-markup-command (test layout props stringA stringB) (string?
> string?)
>      (interpret-markup layout props
>          (markup (#:column (stringA stringB)))))
> 
> #(define-markup-command (test layout props stringA stringB) (string?
> string?)
>      (interpret-markup layout props
>      (markup #:column (cons stringA stringB))))
> 
> #(define-markup-command (test layout props stringA stringB) (string?
> string?)
> (interpret-markup layout props
> (markup (make-column-markup (list stringA stringB)))))
> 
> Which is "better code", and why?
> 
I prefer #3.  My reasons?

I don't like option 1, because this is a scheme function.  The use of
#:column as a scheme function is not standard -- it's mixing LilyPond and
scheme.  Also, in scheme, you can't do (stringA stringB).  So somehow the
#:column is triggering a macro that turns what would be illegal scheme into
legal scheme.  I haven't spent the time to follow through exactly how.

I like option 2 better than option 1, but I still don't like it because the
documentation says that column needs a list of strings, and you have a pair
of strings not a list of strings.  Again, the #:column is doing something
that modifies the scheme, and I can't follow it.  It doesn't match with the
documentation, and I don't know how to change it if it stops working (like
you mentioned in your case of adding and removing parentheses until it
started working.

Option 3 is all standard scheme, and follows the documentation exactly.
It's very easy for me to understand why and how it works, and easy for me to
modify and apply in different situations.

Probably if I had my way, I'd eliminate the #:column syntactic sugar,
because I think it introduces more problems than it solves.  If I'm working
in scheme, I should be working in scheme.  But that's just my opinion.

HTH,

Carl