want to know
Badger BA 64810
bbadger at x102c.harris-atd.com
Fri Aug 18 02:41:02 AEST 1989
In article <1989Aug16.203219.11825 at cs.rochester.edu> quiroz at cs.rochester.edu (Cesar Quiroz) writes:
>Just a few difficulties I have with Badger's argument.
>In <2538 at trantor.harris-atd.com>, bbadger at 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 at trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
More information about the Comp.lang.c
mailing list