> In R7RS, :|123| is always going to be indistinguishable from |:123|; this has nothing to do with keywords being disjoint or not.
*In*distinguishable? At present, the former in Chibi gives me a symbol which the writer gives back out as |:\|123\||; |:123| is a symbol :123.
Actually it seems that :|123| is indeterminate in the R7RS formal syntax, which only allows tokens without |s or with one at each end. Consequently, something like abc|DEF| is not a token, but what is it? Is it two consecutive tokens without intertoken word space? Apparently no implementation thinks so. But whereas Chibi and Larceny commit as soon as they see the "a" that this is an ordinary identifier and treat the |s as identifier characters, the other Schemes I have tried use the CL rules, by which | treats all characters up to the next | unchanged as identifier characters, so that 'abc|DEF| => |abcDEF|. I was presuming the latter interpretation.
> Identifier-syntax always behaves the same way whether in operator or operand position. So it is syntax-case alone that can provide this behavior.
I think this is conflating things. If we adopt explicit renaming only, we can still specify identifier syntax with the behaviour needed, albeit (as I recently mentioned to Marc) no existing explicit renaming system actually does this at present, to my knowledge.
Yes, identifier-syntax is orthogonal to syntax-rules vs. syntax-case vs. ER. But by "this behavior" I meant "expanding differently in operator vs. operand position.
R6RS syntax-rules can do this too,
Actually it's forbidden: a top-level syntax-rules pattern has to be a list, not anything else.
> Default vs. no-default keywords: the signature of CL's `make-array` is (make-array dimensions &key adjustable fill-pointer displaced-to displaced-index-offset element-type initial-element initial-contents). Of these, all have defaults except the last two, or perhaps it is more accurate to say the default is implementation-specified. But it is definitely not nil, because filling the array with nils is not the same as not filling the array.
Are you saying that in CL, if I pass nil explicitly to all those keyword arguments of make-array, it has a different effect to if I’d omitted them?
Yes. Specifically:
:element-type defaults to `t`, meaning "any type", because defaulting to `nil` would mean "no type" which is useless. `t` and `nil` are the names of the top and the bottom of the CL type lattice. (This is quite independent of the types of their values: `t` and `nil` are immutably bound to `t` (of type `symbol`) and `nil` is immutably bound to `nil (of types `symbol` and `list`).)
:displaced-index-offset is a non-negative integer, and its default is 0. Since `nil` is not a meaningful value, it wouldn't be hard to convert `nil` to 0.
:initial-element is a particular value of type `:element-type` with which the elements of the array are initialized; if it is omitted, the elements are not initialized. So specifying `nil` means something different from not specifying this keyword.
:initial-contents is a nested sequence (list or vector) that is converted to the contents of the array. Since `nil` is (), `nil` would specify the contents of a 1-dimensional array containing no elements, quite different from not specifying it at all. (This wouldn't be true in Scheme). However, a zero-dimensional array has only a single cell and as such :initial-contents can be any object.
I will mention it, but I don’t think even Guile supports this in Scheme. What’s the intended use?
To wrap a keyword function in another keyword function, thus (from CLHS):
(defun array-of-strings (str dims &rest named-pairs
&key (start 0) end &allow-other-keys)
(apply #'make-array dims
:initial-element (subseq str start end)
:allow-other-keys t
named-pairs))
The &allow-other-keys allows make-array arguments to be accepted by array-of-strings without having to enumerate them in the lambda-list, which allows implementation-specific keywords to be passed (for example, a keyword that causes the array to be stored in unmanaged memory). However, make-array does not make use of keywords :start and :end, but by specifying :allow-other-keys, the call to apply will not reject them. (Note that `apply` itself has no keywords, so all the key-value pairs passed to it are simply prepended to named-pairs.)