[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Having trouble understanding optional and variable amount of argumen

From: Urs Liska
Subject: Re: Having trouble understanding optional and variable amount of arguments
Date: Thu, 8 Mar 2018 08:44:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Hi Stéfano,

Am 08.03.2018 um 07:26 schrieb Stefano Troncaro:
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
    `((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 ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]