Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!network!ucsd!nosc!logicon.arpa!trantor.harris-atd.com!x102c!bbadger From: bbadger@x102c.harris-atd.com (Badger BA 64810) Newsgroups: comp.lang.c Subject: Re: want to know Message-ID: <2549@trantor.harris-atd.com> Date: 17 Aug 89 16:41:02 GMT References: <8487@bsu-cs.bsu.edu> <2980@solo9.cs.vu.nl> <182@sunquest.UUCP> <14269@haddock.ima.isc.com> <1496@l.cc.purdue.edu> <1701@crdgw1.crd.ge.com> <2538@trantor.harris-atd.com> <1989Aug16.203219.11825@cs.rochester.edu> Sender: news@trantor.harris-atd.com Reply-To: bbadger@x102c.harris-atd.com (Badger BA 64810) Organization: Harris GISD, Melbourne, FL Lines: 98 In article <1989Aug16.203219.11825@cs.rochester.edu> quiroz@cs.rochester.edu (Cesar Quiroz) writes: >Just a few difficulties I have with Badger's argument. >In <2538@trantor.harris-atd.com>, bbadger@x102c.harris-atd.com wrote: >| Firstly, it is less informative to the user. Having a fixed entry like main >| removes the possibility of a descriptive name being applied to a program. >Not quite so. I bet all the C code I keep has different names for >different programs. I just happen to use the filename to name the >programs. The particular entry point used by the runtime system is >of no importance when looking for informative naming, because that >name is not the one people associate with the program! The >objection is trivially true, and quite irrelevant. [I wouldn't >claim the scheme in use is perfect, think about how many times a >novice writes a `test.c' and gets himself into strange states.] > Yes, and occaisonally you'll see a file ``main.c''! The point is that the main program has a _purpose_ which could (should!) be described in its name. Just like every other function. C's lazy run-time startup code is responsible for this blemish. It doesn't ruin the language, but it is a wart. You use significant names for the files of your programs, why shouldn't you use significant names for the main routines? I suppose a standards committee would put the burden of proof on those wishing to change the status quo, but I'm not a standards committee, I'm used to having this feature in other languages, and I feel it's up to the defenders of ``main()'' to show why this restriction is desirable. >| Our local ctags has been modified to substitute ``Mfoo'' for the >| symbol ``main()'' found in file ``foo.c''. This kind of game wouldn't >| be required if C let you choose your main program name. > >This is true, and also irrelevant. It is not unusual to have a >`usage()' function, just because it is the reasonable thing to do. >Do you also special-case this? This point only says that the tools >need a correct model of the naming system, rather than build in >erroneous assumptions (``No two programs have different functions >with the same name''). Of course the tools could be better! My point is that ``main'' is an *unnecessary* restriction. You _could_ program in a language which requires all parameters to have fixed names (r1,r2,r3...). It's more expressive to be able to name things yourself. Even assemblers are symbolic. Why *not* let me choose the name of the main program? ``Well, we've always done it this way.'' isn't much of a reason (except in standardizing existing practice). A work-around for now is to adopt a coding convention to trivialize main(): int printenv(int argc, char *argv[] ,char *renvp[]); int main(int argc, char *argv[] ,char *renvp[]) {return (printenv(argc, argv ,renvp));} int printenv(int argc, char *argv[] ,char *renvp[]) { ...stuff ...} But I'd much rather just write: int printenv(int argc, char *argv[] ,char *renvp[]) { ...stuff ...} >| Secondly, I don't really like the idea of having a _single_ entry >| point to a program. ... >This is more interesting. Is it fair to say that this issue goes >beyond the language itself and into the design of the programming >environment? ... provide more detail about how you would go about >changing exec and the shells it would be a stronger proposal. ... Yes, this is chiefly an environment problem -- how does a shell construct arguments for arbitrary functions? UNIX takes the easy way out by restricting the interface to strings (main(argc,argv,envp)). Many single-language systems offer a more complete interface. Lisp, Cedar, Arcturus (Interpreted Ada, Thomas Standish UC,Irvine) and the Rational Corp. Ada environment come to mind. The UNIX shell has two in-out interfaces (IFs) to programs. The first IF is the main call arguments and return value: int main(int argc, char *argv[] ,char *renvp[]) The command line words and the environment strings are bundled and passed to main, and the return value is used as a status. The second IF is the standard input/output redirection, as used in pipelines. In particular output from a program can be captured in the shell command using `foo` syntax to insert the output from command foo into the command line. (As in `` mv $i `echo $i | sed 's/.ada/.a/'` ''. Note that `` and '' are not part of the command.) Actually, this problem has already been solved by the debuggers: dbx, sdb, adb, gdb. Each of these has ways of calling any function within the object module. >As it is, it amounts to `I don't like it, I like X and you take care >to make sure X works for me', a position for which I have no sympathy. > >If anyone cares to formulate this proposal in terms that can be >discussed, I would suggest taking a look at the debate (in the Lisp >community) between residential and file-based systems, just to make >sure no time is spent in rediscoveries. My impression is that the >new language created that way will have little resemblance to C >anyway. There really wouldn't be any much change to C. Even now, main() isn't treated specially by the C compiler. It's just that the runtime system makes a direct call to main after initial start-up. Bernard A. Badger Jr. 407/984-6385 |``Use the Source, Luke!'' Secure Computer Products |``Get a LIFE!'' -- J.H. Conway Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.