[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM, email@example.com
- Subject: adjustable arrays
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 20 May 87 02:41 EDT
- Cc: firstname.lastname@example.org, kmp@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think you are both expressing reasonable and relatively coherent
views of the world.
The real problem is that CLtL is not explicit enough to distinguish between
the two cases. It has insufficient concept exposition about adjustable
arrays to clearly indicate the intent of the authors about what properties
were intentional and which were accidental. Consequently, people made up
their own concepts.
The problem with incomplete specs like this is that there are multiple
extrapolations which are compatible with the base spec, and those
extrapolations are not necessarily compatible with each other. This result
acts as a real barrier to portability at times.
I can relate to Moon's claims because I use the lispm a lot and believe it to
be an internally consistent correct reading of CLtL in this area. On the
other hand, it's not what I had expected from reading the CL manual. As such,
I know first hand that other people can have internally consistent but
differing readings. I also know first hand that it's a pain to port code
between dialects with conflicting views because it's hard to test the code
in one implementation and have any confidence that it will run in the other.
Whether we decide on the conservative reading that Sandra and others have
pushed or the less conservative reading that Moon asserts was intended, the
important thing is that the manual say clearly what will happen so that users
can simply read the book and know what to expect with no need to do lengthy
deductions about the consequences of what they have or have not read.
I think the issues are clearly understood and little more is to be gained by
prolonged debate at this time. A process (X3J13) exists for introducing
changes/corrections to CLtL and I think that process should now be asked to
do its job by addressing that issue.