Chris Dornan writes:
>
> Surely, the argv global-constant proposal is cool. What is being proposed is
> is a modest extension, namely introducing a constant that is initialised with a
> copy of the command-line arguments. Cannot this sit along side the existing
> proposal, with each mechanism being used appropriately. I can think of many
> programs where I would quite usefully use the global constant -- I suspect all
> of them.
>
This is spot on I think, if you want to go the extra mile and provide
an options file, say, then you will have to get out all your plumbing
gear, rather than record options via CAFs, if you so wish. But, the
issue here is *not* how you configure your programs, there's more than
one way to do that (to paraphrase the Perl slogan), but the fact that
argv is *constant* and should be provided as such. I've yet to see a
post contending that argv isn't.
>
> But hold on a moment.
>
> What happens if you have a Stoye-style process model in which you are kicking
> off processes by running `main' programs from a shared repository of program
> modules. Now each of the processes would be a separate program with its own
> command-line arguments, but the global-constant proposal cannot deal with this
> as many processes with different arguments would be executed from the same
> collection of modules. Many hackful solutions exist to get around this problem
> to be sure, but the proposal would seem to be decidedly out of place with this
> multi-process execution model.
>
If you're going to provide a functional process abstraction like this,
then you will have to find another way, perhaps
fork :: ([String]{-argv-} -> IO ()) -> IO ()
(You'd probably also want to do something about I/O and have the
standard handles for each process be separate). Slightly restrictive
you might say, but I personally wouldn't lose any sleep over it
(do you really want a functional OS with one big, shared heap?)
--sigbjorn
