usefulness in code Peter McGoron (31 Mar 2026 12:07 UTC)
Re: usefulness in code Peter McGoron (31 Mar 2026 14:54 UTC)
Re: usefulness in code John Cowan (31 Mar 2026 16:03 UTC)
Re: usefulness in code Alex Shinn (31 Mar 2026 21:56 UTC)
Re: usefulness in code Peter McGoron (02 Apr 2026 10:46 UTC)
Re: usefulness in code John Cowan (02 Apr 2026 22:38 UTC)

Re: usefulness in code Peter McGoron 02 Apr 2026 10:41 UTC

On 3/31/26 12:02, John Cowan wrote:

 > The reason for that is that the syntax would be ambiguous: #1a
followed by lbounds looks the same as #1a followed by datum.  Lbounds
implies the number of dimensions, so if lbounds were required then we
could do without it.

I would support making lbounds required. Maybe making lbounds either an
integer (the dimension) or a list of integers (the lower bounds implying
the dimension).

That would also make it so that #0 through #9 are not reserved, which is
good.

Modifying the EBNF you had in another thread:

array-literal ::= "#a" [tag] bounds-or-dim datum
tag ::= u8 | ... | u64 | s8 | ... | s64 | f32 | f64 | c64 | c128
bounds-or-dim ::= "(" bound* ")" | integer
bound ::= integer | "(" integer integer ")"

(If flexibility for those writing array literals in source code is desired.)

> That makes sense if we use it for serialization only.

Given that a sample implementation of the reader syntax would be
implementation-specific, the read-* and write-* function would be
portable code for people using implementations that do not support this
SRFI at the reader level. They could use it for
serialization/deserialization.

___________________________________________________________

As another thing: the final "format-array" example uses the SRFI 163
bounds syntax.

"format-array" perhaps could be removed or changed to something that
integrates with SRFI 166 (Monadic Formatting).

-- Peter McGoron