Xref: utzoo comp.unix.wizards:7558 comp.lang.c:8873
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!rutgers!bellcore!spectral!sjs
From: sjs@spectral.ctt.bellcore.com (Stan Switzer)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: command line options
Message-ID: <6546@bellcore.bellcore.com>
Date: 4 Apr 88 14:23:27 GMT
References: <2414@zyx.UUCP> <738@srs.UUCP> <26423@cca.CCA.COM> <761@srs.UUCP> <26550@cca.CCA.COM>
Sender: news@bellcore.bellcore.com
Reply-To: sjs@spectral.UUCP (Stan Switzer)
Organization: Computer Technology Transfer, Bellcore
Lines: 29

> In article <761@srs.UUCP> srs!dan@cs.rochester.edu (Dan Kegel) writes:
> ]We've recently been mulling over what would be better than getopt().
	. . .
> o Non-switch positional arguments should be allowed.
> o The caller should be able to step through the list of arguments which
>   were ignored by the argument processor.
	. . .
> o The argument processor shouldn't use any static or global variables
> o It should allow the caller to do as much of the error handling as desired.

In article <26550@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
> o	The argument processor should be a one call routine, a contrasted
> 	to getopt, which is called once for each argument.
 
All of these considerations suggest that getopt()' should be a coroutine
style function.  Harking back to a week-old discussion, I propose that a
coroutine mechanism (actually some sort of policy-free state freeze/thaw)
would greatly help in solving this sort of problem.  The getopt()' coroutine
would be instantiated with an argument vector, then be (co)invoked once
per argument.  Semantic error notifications could be conveyed back to
getopt()' via the (co)returns.

(In fact the Sys V getopt() routine does approximate this approach by
using external variables and a bizarre calling convention.  It just doesn't
generalize.)

Just another simple example of where coroutines can simplify things...

Stan Switzer   sjs@ctt.bellcore.com -or- bellcore!ctt!sjs