You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These are some examples of the syntax for flags at the moment:
(flag (verbose)
("-v" "--verbose" "Show detailed messages.")
(verbose #t))
(flag (attempts n)
("-a" "--attempts" "Number of attempts to make")
(attempts (string->number n)))
(flag (transaction n timeout)
("-t" "--transaction" "Size of transaction, and timeout value")
(transaction (map string->number (list n timeout))))
(flag (links #:param [links null] link)
("-l" "--link" "Links to validate")
(links (cons link (links))))
It seems that the goal of a flag function is typically to set the value of the corresponding parameter. So, should the syntax instead encode this transparently instead of requiring the user to do it explicitly? That is, we could treat the return value of the function as the value that the parameter should be set to, and do this behind the scenes. Otherwise, the syntax seems to have some redundancy, and in the most common cases (e.g. the first three examples above), the user would probably not even care to mention the parameter. The new versions would look like this:
(flag (verbose)
("-v" "--verbose" "Show detailed messages.")
#t)
(flag (attempts n)
("-a" "--attempts" "Number of attempts to make")
(string->number n))
(flag (transaction n timeout)
("-t" "--transaction" "Size of transaction, and timeout value")
(map string->number (list n timeout)))
(flag (links #:param [links null] link)
("-l" "--link" "Links to validate")
(cons link (links)))
This change would likely be backwards incompatible, and should probably be done in connection with #5 for that reason (as that is also backwards incompatible).
The text was updated successfully, but these errors were encountered:
These are some examples of the syntax for flags at the moment:
It seems that the goal of a flag function is typically to set the value of the corresponding parameter. So, should the syntax instead encode this transparently instead of requiring the user to do it explicitly? That is, we could treat the return value of the function as the value that the parameter should be set to, and do this behind the scenes. Otherwise, the syntax seems to have some redundancy, and in the most common cases (e.g. the first three examples above), the user would probably not even care to mention the parameter. The new versions would look like this:
This change would likely be backwards incompatible, and should probably be done in connection with #5 for that reason (as that is also backwards incompatible).
The text was updated successfully, but these errors were encountered: