[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: Fri, 9 Mar 2018 08:18:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Am 08.03.2018 um 23:46 schrieb Stefano Troncaro:
With your last update, the following syntax popped to mind:
\version "2.19.80"

%Functional copy of your example
#(define rules
      (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
      (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.


reply via email to

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