Email list hosting service & mailing list manager

Optional option argument Shiro Kawai (07 Jul 2020 02:44 UTC)
Re: Optional option argument Marc Nieper-Wi├čkirchen (07 Jul 2020 09:35 UTC)
Re: Optional option argument Anthony Carrico (08 Jul 2020 16:49 UTC)
(missing)
Re: Optional option argument Anthony Carrico (08 Jul 2020 23:41 UTC)
Re: Optional option argument John Cowan (08 Jul 2020 23:43 UTC)
Re: Optional option argument Anthony Carrico (09 Jul 2020 00:05 UTC)
Re: Optional option argument John Cowan (09 Jul 2020 00:07 UTC)
Re: Optional option argument Anthony Carrico (09 Jul 2020 00:18 UTC)
Re: Optional option argument John Cowan (09 Jul 2020 00:22 UTC)
Re: Optional option argument Arthur A. Gleckler (30 Nov 2020 19:24 UTC)
Re: Optional option argument Anthony Carrico (30 Nov 2020 21:12 UTC)
Re: Optional option argument Arthur A. Gleckler (01 Dec 2020 00:56 UTC)
Re: Optional option argument Eugenio Montano (01 Dec 2020 01:50 UTC)
Re: Optional option argument Arthur A. Gleckler (01 Dec 2020 01:57 UTC)
Re: Optional option argument Anthony Carrico (01 Dec 2020 14:18 UTC)
Re: Optional option argument Shiro Kawai (08 Jul 2020 19:27 UTC)
Re: Optional option argument Anthony Carrico (08 Jul 2020 23:57 UTC)
Fwd: Optional option argument Arthur A. Gleckler (07 Jul 2020 17:34 UTC)
Re: Fwd: Optional option argument Anthony Carrico (08 Jul 2020 16:10 UTC)
Re: Fwd: Optional option argument Arthur A. Gleckler (08 Jul 2020 19:29 UTC)

Re: Fwd: Optional option argument Anthony Carrico 08 Jul 2020 16:09 UTC

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