[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A memorial day issue
- To: Fahlman@CMU-CS-C
- Subject: A memorial day issue
- From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
- Date: Tue, 31 May 1983 15:58:00 -0000
- Cc: common-lisp%su-ai@USC-ECL
- In-reply-to: The message of 31 May 83 09:37-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 31 May 1983 09:37 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Send a specific proposal for PARSE-INTEGER and then we can consider it.
My specific proposal is that we flush it. I still don't see any
function in here that would be broadly and generally useful and not
trivial for the user to write, but you've written more user interfaces
than I, and if there's a good idea in here trying to get out, I'd like
to see it.
@Defun[Fun {parse-integer}, Args {@i[string]}, Keys {[start][end][radix][junk-allowed]}]
This function examines the substring of @i[string] delimited by @kwd[start]
and @kwd[end] (which default to the beginning and end of the string).
It skips over whitespace characters and then attempts to
parse an integer. The @kwd[radix] parameter defaults to @f[10],
and must be an integer between 2 and 36.
If @i[junk-allowed] is not @false, then the first value
returned is the integer parsed, or @false if no syntactically correct number
was seen. The second value is the index into the string of the delimiter
that terminated the parse, or the index beyond the substring if the
parse terminated at the end of the substring.
If @kwd[junk-allowed] is @false (the default), then the entire substring is scanned.
An error is signalled if the substring does not consist entirely of
the representation of an integer, possibly surrounded on either side by
whitespace characters.
The returned value is the number parsed, or @false if no syntactically valid
integer was found.
It is an error if the substring is blank (@false will be returned in this case).
@Enddefun
I note in passing that a lot of interfaces from MIT have been strongly
influenced by the syntactic style of TECO and DDT: 123x, etc. This
style has its place (in programs like TECO and DDT), but there are much
better user interface styles around for most things, or at least a lot
of variety in people's taste.
I dislike that style of interface intensely, too. PARSE-INTEGER, although
it supports such activity, is not designed primarily with that in mind.
so if the proposed PARSE-INTEGER were
primarily intended to make it easier to parse the "abutted numeric
prefix" style of argument, I think it would be a great candidate for the
yellow pages but I would oppose its inclusion in the white pages.
There is no strict need for a lot of functions. Yet, this particular
little piece of functionality seems like a white pages candidate because,
as I have said, almost any conceivable user interface will require it. The
abutted-number feature is a very small aspect.
I am not sure if whitespace around the number being allowed is right.