[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: dlw at SCRC-TENEX at mit-mc, DLA at SCRC-TENEX at mit-mc
- Subject: parse-number
- From: Bernard S. Greenberg <BSG at SCRC-TENEX at mit-mc>
- Date: Thu, 23 Dec 1982 19:37:00 -0000
- Cc: lisp-designers at SCRC-TENEX at mit-mc, Common-Lisp at SU-AI at mit-mc
- In-reply-to: The message of 23 Dec 82 13:40-EST from Daniel L. Weinreb <dlw at SCRC-TENEX>
Date: Thursday, 23 December 1982, 13:40-EST
From: Daniel L. Weinreb <dlw at SCRC-TENEX>
Ah. That reminds me why parse-number works the way it does.
parse-number is intended to be a tool to help you parse your way through
a string. If you encounter a digit on your way from the left end of the
string to the right end, you call parse-number, and it reads in as much
of the string as is a number and tells you where it stopped so that you
can continue to parse the string. Whether you expected the entire
string to be a number or not is up to you, and parse-number can be
useful in both cases so the "best" default value for the
fail-if-not-whole-string argument is not obvious. I don't think it's
too important as long as the documentation makes it clear.
Now I see. So parse-number is designed to help you implement user interfaces
where fields are delimited from each other by what kind of characters they
contain, not spaces, commas, or other such. I have used parse-number countless
times since I came here, and not once wanted its current behavior. Does anyone
acknowledge this point about the current behavior implying peculiar user interfaces?