[m-dev.] Getopt extension for discussion

[Philip Dart]

> I was talking with Philip the other day, and he asked for a "maybe string"
> option type so that you can have:
> 	--opt "a string"
> or	--no-opt
> 
> He argued that this was better than using the empty string as a sentinel
> for the "no" case. The example application was filenames (in which case
> "" would always be a valid sentinel). Following is a diff that adds the
> requested functionality.

> Can anyone give a realistic example where "" is not a valid sentinel, where
> the maybe string option would be a real advantage?

Since it was my example, I thought I'd provide some more detail ...

The example a program that uses a startup file, where a default
startup file is provided eg. part of the installation.
The option

	-s filename

could be used to specify a different startup file, and the option

	-s-

could be used to say indicate that no startup file should be read.
This is quite common requirement, eg. for shells and typecheckers :-)
It's also a simple extension which doesn't affect the current use of getopt.

> +getopt__process_option(maybe_string(_), _Option, Flag, MaybeArg, _OptionOps,
> +		OptionTable0, Result) :-
> +	( MaybeArg = yes(Arg) ->
> +		map__set(OptionTable0, Flag, maybe_string(yes(Arg)),
> +				OptionTable),
> +		Result = ok(OptionTable)
> +	;
> +		error("string argument expected in getopt__process_option")
> +	).

Tom, this error string should be different from the one used
for the clause for string(_).

Also, since you've made this change (and posted it before I could post
mine :-), please fix the bug where "-" appearing as an option is ignored
altogether.  This should be passed through as an argument.
Fixing this will allow "-" to be treated as stdin/stdout as for diff or tar.
(Though bash treats "-" the same as "--" but we can't have everything).

Philip