-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The relevant passage of the standard (draft 6) reads:

.  (exit)
.  (exit obj )

.  process-context library procedure
.  process-context library procedure

.  Exits the running program and communicates an exit value
.  to the operating system. If no argument is supplied, the
.  exit procedure should communicate to the operating sys-
.  tem that the program exited normally. If an argument is
.  supplied, the exit procedure should translate the argument
.  into an appropriate exit value for the operating system. If
.  obj is #f, the exit is assumed to be abnormal.

Short answer:  I wouldn't mind the proposed extension of
specifying #t as an argument giving a "successful" exit.
Extending it to "any true value," on the other hand, would
be counterproductive because that would not allow you to
directly give the wide variety of more specific (success or)
failure values that the local OS is prepared to interpret.

On the gripping hand, I have one proposed extension that I
think is more needful and useful.  I think that the standard
should state that calling exit with any error-object as a
value causes your program to signal an exit with failure
to the local OS.

The current draft does NOT  now specify the "meaning" of any
argument other than #f.  It could specify #t, without
causing any problems, but I don't think that really adds
much value apart from being more tastefully symmetric.

As I read this, you're expected to either be writing portable
code, in which case you use the two guaranteed behaviors to
signal "success" and "failure," or you're writing code to a
known OS in which case you have a known set of error codes
(and possibly success codes) available, and you can
therefore pass one of those, as something more specific
and meaningful to that OS.

I would expect to use it (on Linux or Windows) by passing
it a small integer value and I would expect the program to
return that same integer to the OS. In that case 0 signaling
success and some other integer signaling an error would be
the expected and desired effect.  If I were on Plan9, I
would expect to pass it a string and have that same string
returned to the OS, in which case a message would signal
failure and an empty string would signal success.

On the other hand, if I were writing portable code, it
wouldn't be reasonable to even presume I know what values
the local OS would interpret as "success" and "failure",
let alone exactly what kind of failure, so I'd be falling
back on the very most generic behavior, guaranteed in the
standard, of signaling just "success" or signaling just
"failure."  The standard indicates one sure way of doing
each of those two things.  We could add another way to
signal success with (exit #t).  It appeals to symmetry,
but may be redundant.

Because the spec as it now stands allows for programs that
act like native programs aware of all the possible error
conditions, and also allows for portable code which, by
its nature, cannot know what value to return for "success"
nor the OS's mapping of return values to of all the
possible errors, I think it does everything it really
needs to do -- though a few words clarifying the rationale
could help prevent misunderstandings; otherwise someone
might map *every* argument other than #f to "success"
and lose the power to pass meaningful specific values
to the OS.

However, I think it could make an additional useful
requirement.  It could promise to signal an error exit
when passed an error-object.

First of all, the current draft *allows* error-objects
as an argument to exit, and I believe that there is really
only one reasonable interpretation of them in the context
of exit arguments.  Thus this is an extension both
compatible with the standard and obvious given the current
standard.

Error-objects, surely, are a category of things that can
be expected to come in flavors at least roughly matching
an operating system's categories of recognized program error
types.  And surely, no one would pass an error object to
exit expecting or intending that as a means to signal
success.  And, finally, it's a minimal burden on implementors:
An implementation could choose simply to signal "generic
failure" given an error-object, the way it does with #f now.
It might also be expected, if trying to decide what kind
of OS-specific error code to yield or what kind of error
message to print, to find useful information in an
error-object.

Therefore, I think error-objects are at least as portable
as #f for signalling error exits, and potentially much more
specific and informative.  Having the standard specify that
error-objects as arguments to exit always cause an "error
return" adds significant value.

				Bear
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPdKCDAAoJEAOzWkqOibfN1esIAJMDmAxfjapT2MS19FEmpZna
++2Zj2dhkgTBzG9lbn+UjRRR2iRBsOSPxtfTT6lozHV5vujQMeiRTJAK4+NJXECA
sFpsGaw5z9xfL1uk+z/E0O6OLXNjP7lkw19PjlaWT24L2QZuTpYrUvMlag3tSItJ
vHfUr5dIE63E9RFzL50x49y/Gvl++Xo935TaHAGZiumFUKxy1kGFf7ED2S7kxvnc
I6SydHNof039le3rzXsItrIq62rXtxtLiQap6QRnihg2H49mq4wIcsqtq7Q4ujBI
/byOiEF2lyofKZxlhJY38aKkUoWZYMGA8ufjBWX4Z77ubKYFU/msd1Ka/cCWnCs=
=8OQq
-----END PGP SIGNATURE-----

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports