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 John Cowan 31 Mar 2026 16:02 UTC

On Tue, Mar 31, 2026 at 8:07 AM Peter McGoron <xxxxxx@mcgoron.com> wrote:

> How often would array literals be used in code?

Talking to folks on #commonlisp, the typical use cases are tests and
noodling at the REPL. I've posted to r/lisp to try to get more
feedback.

> You can't quasiquote numerical
> constants[1] so one can only write constant numerical arrays.

We could allow quasiquotation of homogeneous vectors if we wanted to.
I've raised this as issue #312.

> I like array literals for data serialization, however. In that case,
> there is not much use to have all of the special cases and shortcuts
> that the current grammar has, because it's designed to be machine
> readable. It could be simplified so that one does not have to omit the
> number of dimensions.

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 like to see a EBNF grammar for the syntax. Whatever design we
> end up going with, I'm willing to write that.

A simple version (omitting whitespace) is:

array-literal ::= "#" integer "A" datum | "#A" lbounds datum
integer ::= digit+
lbounds ::= "(" integer* ")"

> I would also like to see `read-array` and `write-array` procedures,
> similar to the procedures in SRFI 267 (raw string literals) and in SRFI
> 207 (string notated bytevectors). I could also write those.

That makes sense if we use it for serialization only.