[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
#O truncation, and #*
- To: RWK at MIT-MC
- Subject: #O truncation, and #*
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Sat, 1 Nov 80 20:01:00 GMT
- Cc: BUG-LISP at MIT-MC, JONL at MIT-MC, RLB at MIT-MC
- Original-date: 1 November 1980 15:01-EST
Date: 1 November 1980 13:41-EST
From: Robert W. Kerns <RWK at MIT-MC>
cc: BUG-LISP, RLB
Re: #O truncation, and #*
The current definition of #* is not the right thing for machine dependent
code. There is such a thing as gratuitous dependency.
I agree completely. I tink that the existing definition of #* just gives people
license to write code which is never going to be transportable. Worse, it does
not keep the stuff from being run on another system. Consider the alternatives:
Either you can do something like:
#+PDP37 (SETQ FOO #o777777000000)
(or some such) or you can do something like
#+PDP37 (SETQ FOO #*777777000000*)
In the former case, you are providing the guy with info that the number is
octal. If he's never heard of PDP37's, he may still be able to read your code.
In the latter case, you provide him with 0 info if he doesn't know what word
size and natural base are for the PDP37. Heck, it could be HEX on a 48bit
machine and just happen to be that no lettered digits were needed for this
The programmer always knows. Further, if he's playing with bits, he's doing
something very intricate. I think we have an obligation to provide constructs
that lend structure to his program rather than allowing him to hide in
Is there anyone currently opposed to the flushing of the #* convention?
RWK: #O being already locked down, there is an advantage to #O* over #*O
which is that it leaves #* free for some other application.
As to the concept of truncation, I guess I agree with RWK that we need to
think up a place where truncation could be used successfully in some real
application before we offer auto-truncation..