No Subject

1999-11-16 Thread Alex Ferguson

The Sender field should be ignored (as per RFC 822) by mail software
if there's a From field. The first From field is not legal as it is
not delimited by a ':'

I'd say the Pine setup is wrong.

--Sigbjorn



Re: behaviour of System.system?

1999-11-16 Thread Fergus Henderson

On 16-Nov-1999, Malcolm Wallace [EMAIL PROTECTED] wrote:
 The Haskell Library Report informally defines the function System.system
 as follows:
 
   Computation /system cmd/ returns the exit code produced when the
   operating system processes the command /cmd/.
 
 This is fairly vague. [...]
 if you try the same test in C, using the
 system(3) call:  the man page says:
 
system() then returns the exit status returned
 by wait(2V).  Unless the shell was interrupted by a  signal,  its
 termination status [i.e. the shell command] is contained in the 8
 bits higher up from the low-order 8 bits of the value returned by
 wait()

That is POSIX specific.  The C standard merely says that system()
"returns an implementation-defined value".  I don't know off-hand
what typical non-POSIX systems do.

 Currently, nhc98 matches C's behaviour by giving the result code
 returned by the operating system (i.e. 256/512/etc).  Currently, Hugs
 and ghc give the (more natural) shell result code, not the one returned
 by the operating system.

We ran into this same issue during the development of Mercury,
and we chose to have Mercury's `call_system' procedure return the
shell result code, treating the cases where the invoked command
was interrupted by a signal as errors.

I think that this approach would be best in Haskell too.

The only other portable alternative that I can see is to use the
C approach of saying that the result is implementation-defined.
But it should be possible for a Haskell program to invoke another
Haskell program that was compiled to a separate executable
and to examine the return status without having to write
system-dependent code.  If the result of `system' was
implementation-defined, that would not be possible.

But I do see one problem with this approach given the current specification.
Looking at the Haskell 98 Library Reference, I see that it says

 | Any System operation could raise an isIllegalOperationError, as
 | described in Section 11.1; all other permissible errors are described
 | below.

and then the description of `system'

 | Computation system cmd returns the exit code produced when the operating
 | system processes the command cmd.

does not specify any other permissible errors.
That indicates that the only error that it can raise is
`isIllegalOperationError', which does not seem like an
appropriate error in the case where the command was invoked
but was interrupted by a signal.  Nor does it seem like
an appropriate error if the command could not be executed
due to lack of memory.  (That second complaint also applies
to many other operations in the `System' and `IO' modules.)
The current set of restrictions on errors does not seem very
satisfactory, IMHO.

-- 
Fergus Henderson [EMAIL PROTECTED]  |  "I have always known that the pursuit
WWW: http://www.cs.mu.oz.au/~fjh  |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.



RE: behaviour of System.system?

1999-11-16 Thread Simon Peyton-Jones

| Obviously it would be useful if the expected behaviour were documented
| more tightly, and conformed across compilers.  Which result should we
| choose to be standard?  (And can the decision please be 
| recorded in the Haskell 98 errata?)

I would welcome a tightened definition, and would add it
to the errata; but I am not qualified to produce one.

One difficulty is that the definition tries not to be Unix-centric.

Simon