want to know

[Badger BA 64810]

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.