Am 08.03.2018 um 23:46 schrieb Stefano Troncaro:
@Urs
With your last update, the following syntax popped to mind:
\version "2.19.80" %Functional copy of your example #(define rules
`(strict
(req payload
(target ,symbol?))
(opt accepted-without-type
(accepted-arg ,fraction?)
(ind ,number? 5)
(msg ,string? "No message given"))))
%Accepts any argument, but provides a type-check and a default for
msg #(define rules2
`(flexible
(opt (msg ,string? "No message given"))))
I'll think about it later today, just a few short comments for now:
I like it because:
1) It eliminates the need for the boolean argument to
context-mod->props, and puts that information together with all the
other rules, which makes them easier to read and parse (mentally)
because all the information is in the same place. I know it's a minor
thing but it's not much more typing and it feels cleaner to me. The
other way you have a 'rules object' that does not contain the whole
ruleset.
Very good point.
2) It eliminates unnecessary parens.
I'm not sure this is relevant. You don't need to put them around untyped
options but you have to add another layer around everything.
What I liked about my implementation (as opposed to the first ideas) was
that it's flat, a simple list of lists. But probably I'll consider this
as weighing less than 1)
3) It eliminates the need to flag many arguments with opt.
I don't have a strong opinion on that on first sight.
4) Also, arguments that have default values feel optional to me, and
here they are grouped together. With this I can at first glance know
what arguments I need to give and what is optional.
What you're proposing is focused on the POV of the *caller* of the
function (i.e. the document author), while my approach was focused on
what the *code* needs to be present.
As said I'll have to think more closely about it later today, but you
may have a good point here too.
It may have defects I'm not seeing. What do you think? If you like it
I can do the rework.
You may of course open a pull request. Maybe we'll discuss details but I
have no objections so far.
Best
Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
