On 7/7/20 1:34 PM, Arthur A. Gleckler wrote:
> Hello, Anthony.  I know it has been a long time since you contributed
> SRFI 37 /args-fold: a program argument processor/, but would you mind
> taking a look at Shiro Kawai's feedback below?  (Here is the full email
> thread <https://srfi-email.schemers.org/srfi-37/dates/2020/07/>.)  It's
> a request for clarification of the intended interpretation of, e.g.,
> --bar abc, a long option without an equal sign between the name and the
> value.

I think the real motivation for REQUIRED-ARG? was to force short options
to consume the following token as an option argument. Extending this
behavior to long options was probably a bad implementation.

Concerning long options:

* In a single argument string, a long-option followed by one = delimiter
character followed by a long-option-argument is accepted. Example:
--speed=fast

* All other argument strings are treated as operands. This includes
argument strings consisting of a single - character.

I would read this as /only/ the equal sign "=" delimits a long option
argument. So the two argument strings "--bar" and "abc" would be the
long-option "--bar" with a /missing/ long option argument, followed by
the program operand "abc".

I would say the spec is buggy because it doesn't say what to do with
missing required option arguments. I mentioned the ambiguity in Robby
Findler's thread about multiple argument options:

   https://srfi-email.schemers.org/srfi-37/msg/2779969/

Robby's resolution breaks Posix/Gnu compatibility:

   https://srfi-email.schemers.org/srfi-37/msg/2779971/

The original code resolves the ambiguity by using the next program
argument. This partially matches Robby's/PLT's way of pulling args for
long options, but I would say this was a bad choice, and the
option-processor should probably be provided a #f for ARG in this case,
as an error flag. Unfortunately the discussion was focused on comparison
with cmdline.ss, and there was no vetting of the issue of missing option
args.

All in all, this discussion argues for strongly typed interfaces. We can
see here that Posix, Gnu, and Scheme all suffer in this respect!

(reverse
  (args-fold
   (list "--help=hello" "--help" "--help" "--help" "-h" "-h" "-h")
   (list
    (option
     (list #\h "help")
     #t
     #f
     (lambda (option name arg seed)
       (cons (list 'recognized name arg) seed))))
   (lambda (option name arg seed)
     (cons (list 'unrecognized name arg) seed))
   (lambda (operand seed)
     (cons operand seed))
   '()))

'((recognized "help" "hello")
   (recognized "help" "--help")
   (recognized "help" "-h")
   (recognized #\h "-h"))

But, today I would prefer:

'((recognized "help" "hello")
   (recognized "help" #f)
   (recognized "help" #f)
   (recognized "help" #f)
   (recognized #\h "-h")
   (recognized #\h #f))

> Thank you very much for your contribution.

Welcome. I hope this note is helpful.

--
Anthony Carrico