On 12/16/18 2:15 AM, Sudarshan S Chawathe wrote:
> Here are some very minor comments on SRFI 163.  (On a related note, I am
> also studying SRFI 164 and hope to post some comments in a day or two.)
>
>    - Ref. Draft #4 published: 2018/12/8
>
>    - The examples of Rank-0 arrays and empty arrays are very useful.

I took them from SRFI 58.

>    - format-array: The last example uses arr which isn't defined,
>      although the context does indicate it should be the array from the
>      first example.

Fixed in my local copy.

>    - Implementation: Kawa's format-array does not seem to accept the
>      port/boolean second argument.  (Could be a problem in my setup,
>      which uses a recent Kawa version from Gitlab.)

The 'port' argument wasn't originally part of format-array,
but was added in an updated.

I just added support for it to the Kawa implementation - it's now in GitLab.

>    - (re. Issue 2) format-array is very useful from a pragmatic
>      perspective, and I hope it gets some standardization.  However,
>      this SRFI may not be the best place for it.  Based on the
>      discussion, it seems to me that the array-literals syntax itself
>      is simple and noncontroversial but format-array is a bit of a
>      rabbit hole, getting into format-strings and combinator-based
>      formatting and so on.

That's why I left out the optional 'element-format' argument, but
mentioned it as a possible extension.

It would be simpler for me to keep format-array as it currently is.

>    - Related to the above: I hope format-array and combinator-based
>      formatting (SRFI 159) can work well together.  (I read John
>      Cowan's suggestion but have not explored the issue enough to know
>      if it suffices.)

I agree but I don't have enough understanding of combinator formatting.
It appears that SRFI 159 doesn't handle some of the more complex Common
Lisp formatting - specifically general pretty-printing is not handled.
(The 'pretty' procedure is insufficient.)

>    - What is the motivation for not making the Output part normative?
>      In contrast to format-array, the situation here seems fairly
>      simple.

I guess we might as well make it normative.

>    - (re. Issue 3) I like the idea of always requiring format-array's
>      output to begin with a # character for the reason stated here.  (I
>      don't think it will reduce the prettiness much either.)

Changed it in my work copy, along with a note about a "Possible extension"
to parse format-array output.

--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/