Re: Having trouble understanding optional and variable amount of arguments

[Urs Liska]

Am 08.03.2018 um 10:35 schrieb Urs Liska:

Am 08.03.2018 um 08:44 schrieb Urs Liska:

Hi Stéfano,

Am 08.03.2018 um 07:26 schrieb Stefano Troncaro:

@Urs

I looked into your examples and \with blocks are very useful.

You said earlier that you were thinking about how to make it so that the context-mod could have required arguments, default values for missing ones, and even predicates. I was thinking that context-mod->props could be made to accept this information as an optional argument. Then it can return a 'curated' list of props or raise warnings/errors. That I think shouldn't be difficult to do.

Great idea, thank you. Actually it's pretty much along the lines I was already thinking about - but I hadn't thought of the obvious of doing it directly in context-mod->props.

Although I'm undecided on what would be a convenient way of storing the 'requirement data'. The obvious one to me is an alist with a structure like this: `((key1 . (required . #t)) (key2 . ((default . 9) (pred . ,number?))) ...), but I'm not sure. What do you think?

The "required" is not necessary because if a key shows up in this list it implicltly is required. One addition I'd do is add a keyword 'strict. When that's present any keys *not* in the list are rejected.

#(define rules
   `((key1 .                ;; type plus default
       ((type . ,number?)
        (default . 5)))
     (key2 .                ;; only the type
       ((type . ,symbol?)))
     (key3)                 ;; required without type or default
     (key4 .                ;; default value but no type
       ((default . #t)))
     ))

#(define rules2
   (cons
    'strict
    `((key1 .
        ((type . ,number?)
         (default . 5)))
      (key2 .
        ((type . ,symbol?))))))
    

With rules1 the function would simply check for the presence of the specified keys while with rules2 unknown keys would be rejected (issue a warning and be dropped)

Defining the rules structures is somewhat picky - but this won't be done in the *user* documents but basically in packages or similar library structures, so it should be ok.

I'll give that a shot as I can use this in a current project - but of course I'd also review pull requests ;-)

Best
Urs

I have implemented the above structure as predicates for use with context-mod->props in
https://github.com/openlilylib/oll-core/commit/2ef019f643cbb719bdba15bd28107bb7f12124da
(on the typed-props branch), but so far it doesn't do anything yet. But as you said, Stéfano, this isn't very hard to do. I just wanted to push that before you'd start working on it yourself.

Urs

OK, I've completed the code but didn't merge it to master yet.
The interface can now be used like this:

%%%
\version "2.19.80"

\include "oll-core/package.ily"

#(define rules
   `((ind ,number? 5)
     (target ,symbol?)
     (payload)
     (msg ,string? "No message given")))

testRules =
#(define-void-function (opts) (ly:context-mod?)
   (let ((props (context-mod->props rules #t opts)))
     (pretty-print props)))

\testRules \with {
  msg = "Something"
  unk = "Unknown option"
  target = something
}
%%%

This correctly assigns the 'msg' property, sets 'ind' to the default 5, complains about the wrong type for 'target' and the missing 'payload' property. The failing properties are discarded and will presumably cause errors further down the line, but that is the responsibility of a package or a document author.

Best
Urs