[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LilyPond to Scheme to Lilypond and variadic function
From: |
Aaron Hill |
Subject: |
Re: LilyPond to Scheme to Lilypond and variadic function |
Date: |
Wed, 25 Nov 2020 17:32:23 -0800 |
User-agent: |
Roundcube Webmail/1.4.9 |
On 2020-11-25 3:27 pm, Daniel Tomas wrote:
(First question is : is it better to answer before or after what we
have
written before ?)
This is the classic topic of top-posting vs. bottom-posting. Some folks
like myself prefer bottom-posting (or what I think is better called
inline-posting), as we can keep our replies located closely to the
original quoted context. For instance, your first question here can be
better addressed if I reply directly below it. With top-posting, I
would need to carefully restate any questions to ensure readers can
follow the discussion. When there are multiple questions or issues to
discuss, top-posting can result in a large body of text that may be
harder to consume.
Top-posting can make sense as it lets you put important information
first. However, care must be taken not to allow the bottom of the email
to grow unbounded by the continual requoting of old content. Some mail
clients hide this quoted material from the user so you may think you are
only posting a few sentences, but in reality your email contains the
entire thread. Ultimately, it is a good practice to trim unnecessary
quoted material, regardless of whether you post above it or below.
I try to use optional arguments, but may be it would not be possible
from
within LilyPond code call this function. I give that example :
[...]
Now i give definition of MTKeyExp :
*MTKeyExp *= #(define-music-function
(parser location name mainNote textBelowMain cyclic . rest)
(string? ly:music? string? boolean? ly:music? number?
number?)
(let-optional rest ((note1 d'4) (num1 2) (den1 1))
[...]
That is not the proper way to do optional arguments for LilyPond
functions. Additionally, optional arguments have restrictions based on
how the parser works. Consider:
%%%%
\version "2.20.0"
foo =
#(define-void-function
(first second)
((boolean? #f) ;; Optional arguments are specified by joining
;; the type predicate with an expression to be
;; used as the default value.
number?) ;; The final argument must be a required one.
(format #t "\n (foo ~s ~s)" first second))
\foo 12
\foo ##t 34
baz =
#(define-void-function
(first second third)
((number? #f) ;; The default value need not match the type
;; predicate of the argument; however, just be
;; aware such usage could be confusing to folks
;; who may review the procedure.
(number? 0) ;; Two optional arguments in sequence may have
;; the same type predicate; but, know that the
;; parser will assign values left-to-right.
;; In this case, the user will be unable to
;; specify the second argument without also
;; passing a value for the first.
string?)
(format #t "\n (baz ~s ~s ~s)" first second third))
\baz alpha
\baz 12 bravo
\baz 34 56 charlie
%%%%
====
Parsing...
(foo #f 12)
(foo #t 34)
(baz #f 0 "alpha")
(baz 12 0 "bravo")
(baz 34 56 "charlie")
Success: compilation successfully completed
====
NOTE: I cannot really speak to the rest of your queries, as I do not
understand the problem space you are working in. But I am hopeful the
above may help you refactor your function into a form that could work.
-- Aaron Hill