[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
- To: Masinter.pa@Xerox.COM
- Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 13 Sep 88 18:00 EDT
- Cc: firstname.lastname@example.org
- In-reply-to: <880904-152018-8868@Xerox>
I'm happy with most of this but I have one bone to pick.
I believe the END argument to PARSE-INTEGER should be permitted to be
NIL, meaning use the rest of the string. This is most convenient from
an implementation point of view because one can write
&KEY (START 0) (END NIL)
If you say the argument must be an integer, you must write:
&KEY (START 0) (END NIL END-P)
and complain if END is NIL while END-P is T (which seems gratuitous
error checking since the functionality would be useful) or else you must
&KEY (START 0) (END (LENGTH STRING))
which is also gratuitous since the function will not be certain that the
value of END is correct and will have to do (LENGTH STRING) yet again in
order to validate the value of END.
I believe an analogous criterion should be applied to END arguments
across the board. If someone thinks it appropriate, I will write this up
as a separate cleanup.