Changes between Initial Version and Version 1 of Ticket #827

03/06/11 18:18:07 (3 years ago)

Common Lisp in fact doesn't define reader syntax for multidimensional arrays with an element-type other than T, so it shouldn't be surprising that your attempts to do so don't work.

Since there's no way to read a constant-valued multidimensional bit array, it shouldn't be surprising that there's no way to print one in a way that can be read as an equivalent object.

When CL:*PRINT-READABLY* is true, any attempt to print a bit array which has other than one dimension will fail (signaling a CL:PRINT-NOT-READABLE error.) When CL:*PRINT-READABLY* is false and CL:*PRINT-ARRAY* is true, an implementation is allowed to print a multidimensional BIT array using syntax that's suggestive (to a human reader) of its element type; see CLHS CCL does use this syntax; of course, it isn't a READable representation of the bit array, either.

None of this has anything to do with CCL. The behavior that you expect isn't entirely unreasonable, it just doesn't have much to do with how Common Lisp is defined to behave. Fortunately, the standard CL reader and printer can be extended, and if you're just learning CL you might find doing so to be a worthwhile exercise.


  • Ticket #827

    • Property Status changed from new to closed
    • Property Resolution changed from to invalid
  • Ticket #827 – Description

    initial v1  
    55When you read it back in, the reader barfs: 
    78> Error: Reader error on #<CCL::RECORDING-CHARACTER-INPUT-STREAM #xC75FFE6>, near position 32: 
    89>        Initial contents for #A is inconsistent with dimensions: #2A(#<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4>) 
    1012The related bug is that #1A(#*0000 #*0000 #*0000 #*0000) works "just fine" except it creates a 1D array.