any feedback on SRFI-163 (array literals)? Per Bothner (14 Nov 2018 18:53 UTC)
Re: any feedback on SRFI-163 (array literals)? Shiro Kawai (14 Nov 2018 21:16 UTC)
Re: any feedback on SRFI-163 (array literals)? Per Bothner (14 Nov 2018 22:28 UTC)
Re: any feedback on SRFI-163 (array literals)? Bradley Lucier (15 Nov 2018 00:45 UTC)
Re: any feedback on SRFI-163 (array literals)? Shiro Kawai (16 Nov 2018 00:39 UTC)

Re: any feedback on SRFI-163 (array literals)? Per Bothner 14 Nov 2018 22:28 UTC

On 11/14/18 1:16 PM, Shiro Kawai wrote:
> Small nitpicks:
>
> - Editorial: In the "Reader syntax" section, after the syntax definitions, it reads "The vectag> syntax ..." (extraneous '>')

Fixed in my work copy. Thanks.

> - Clarification: Maybe it's obvious, but we may say the datum need to be delimited from array-literal-header.  It only matters for rank 0 arrays. That is, #0u321 must not be interpreted as #0u32 1.

How about:

     The array-literal-header must be terminated by a delimiter. This is trivially the case for
     rank-1 and above (since the left parenthesis of a list is a delimiter). For rank-0 arrays,
     a single space before datum is recommended style, even if the datum starts with a delimiter.

Though it is worth noting that Common Lisp (at least sbcl) does not require a delimiter - thus
     #0aabc
is the same as:
     #0a abc

> - In output, it can be read that the implementation is allowed to print rank-1 zero-based arrays as vector even if those two are not the same type.  I prefer saying the implementation may do so *only* if it treats (uniform) vectors as subtypes of arrays. I've been bitten by Common Lisp losing array properties on printing.

How about:

     In an implementation where vector is a subtype of array (which is recommended), rank-1
     arrays with zero lower bound should be printed as vectors, though an exception may be
     made for a specified subset of non-simple vectors (such as shared vectors).
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/