[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DIGITP
- To: RWK at MIT-MC
- Subject: DIGITP
- From: JONL at MIT-MC (Jon L White)
- Date: Mon, 22 Sep 80 17:44:00 GMT
- Cc: (BUG LISP) at MIT-MC, GLS at MIT-MC, JAR at MIT-MC
- Original-date: 22 SEP 1980 1344-EDT
Date: 21 September 1980 05:58-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject: DIGITP in NILCOM;STRING
Bletch, (DIGITP #/q) claims 'q' is a digit. I have commented out the two
offending lines of code. I note in CHPROP that JAR has objected to this
behaviour as well. I did not make it take a radix argument, as JAR suggests,
but I would assert that it should NOT assume the radix is 26, and that it did
so was a bug.
Note that CHPROP had two differing definitions of DIGITP (hence you can't
refer to that as a standard), but no requirement that DIGITP be defined
only to accept decimal digits. More importantly, the former notion of DIGITP
(which I've restored) permits one to ignore the question of whether or not
supra-decimal digits follow "9" in the ascii collating sequence. Thus,
the correct definition of DIGITP permits one then to write DECIMAL-DIGITP as
a simple variant, but your more-limiting definition is of no help in writing
the general DIGITP.
The question of radix is quite misplaced here -- DIGITP only identifies
the portion of the alphabet which **can be** used as digits, not those which
are within the bounds of the current (dynamically changing) input base. By
the bye, the NIL syntax provides for input radices up to 36., not just up
to 26.