Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: net.lang.c
Subject: Re: Re: Command line arguments
Message-ID: <1636@brl-smoke.ARPA>
Date: Sat, 8-Mar-86 17:20:57 EST
Article-I.D.: brl-smok.1636
Posted: Sat Mar  8 17:20:57 1986
Date-Received: Tue, 11-Mar-86 01:08:27 EST
References: <1463@brl-smok.UUCP> <8200001@ztivax.UUCP>
Reply-To: gwyn@brl.ARPA
Organization: Ballistic Research Lab (BRL)
Lines: 35

There have been articles recently pointing out that there is no
"command line" in an icon-driven environment.  I believe some of
the articles have missed the point about argv (which was the
original topic of discussion).  According to X3J11, there are
two possible conforming C environments:  "hosted", which must be
able to provide program arguments (NOT repeat NOT "command line"
arguments) and receive exit status, and "free-standing", which
need not even have a main() function, let alone program
arguments.

It is of course possible to implement C in an icon-oriented
environment as a "free-standing" implementation.  Generally,
one will need special library routines to access data objects
anyway in such an environment, so transportability is not a big
issue in this case.  Process interface characteristics will
depend on the specific operating environment in a non-portable
way.

Another possibility is to provide a "hosted" implementation in
the icon-oriented environment.  In this case, there must be an
automatic mapping of icon-selected entities into character
strings for the argv array supplied to main().  This may or may
not fit into existing icon interface schemes.  All this means
is that it may not be possible to advertise a conforming
"hosted" implementation of C in such an environment.  I see no
problem with that; if the UNIX-like software tool model doesn't
fit, don't use it.

If you're going to write programs for an object-oriented
environment, how about using an object-oriented programming
language rather than C.  Better yet, how about generalizing
a la Alan Kay to an agent-oriented environment with an
appropriate user interface.  Other than for implementing the
environment itself, one might then be able to do without
"programming languages" altogether.