From: Raymond Toy
Subject: Re: printing arrays readably
Date: 
Message-ID: <4naf5vfdlt.fsf@rtp.ericsson.se>
>>>>> "Sam" == Sam Steingold <···@goems.com> writes:

    Sam> Therefore, it is actually impossible to print arrays readably.
    Sam> Am I missing something, or is it a hole in the ANSI spec (just like the
    Sam> one with pathnames)?

I think you can print arrays readably.  You just can't do that for
specialized arrays or for complicated arrays, because there's no way
for the reader to know that (no syntax for the features).

    Sam> BTW, CMUCL:

    Sam> user[16]: (write-to-string (make-array 3 :element-type 'double-float) :readably t)

    Sam> Error in format: No more arguments.
    Sam>   ~S cannot be printed readably.
    Sam>    ^
    Sam> while processing indirect format string:
    Sam>   ~&·@<Error in function ~S:  ~3i~:_~?~:>
    Sam>                                      ^

Yep.  I noticed that about a month ago.  The argument for ~S was
missing.  It's been fixed in the current development sources.

Ray
From: Howard R. Stearns
Subject: Re: printing arrays readably
Date: 
Message-ID: <35BCC1AC.F6690D21@elwood.com>
Raymond Toy wrote:
> 
> >>>>> "Sam" == Sam Steingold <···@goems.com> writes:
> 
>     Sam> Therefore, it is actually impossible to print arrays readably.
>     Sam> Am I missing something, or is it a hole in the ANSI spec (just like the
>     Sam> one with pathnames)?
> 
> I think you can print arrays readably.  You just can't do that for
> specialized arrays or for complicated arrays, because there's no way
> for the reader to know that (no syntax for the features).
> ...

If *print-readably* and *read-eval* are both true, an implementation 
could print #.(make-array ....), using whatever :element-type and
:adjustable arguments are appopriate.

By the way, with respect to complex arrays, note that the definition of
similarity is such that simple arrays are similar to otherwise similar
complex original arrays.  An implementation is required to preserve
"simplicity" through a print/read or compile-file/load cycle, but not
"complexity".

What is required for element-type is that the actual element-type be
similar.  If an implementation returns values other than T for
upgraded-array-element-type when given arguments other than character or
bit, then, my understanding of the spec is that when printing such a
specialied array readably, it must either match the actual element type
or die trying.