One issue that I think is worth raising before trying to wrap up
SRFI-107/-108/-109 is how should one write an enclosed expression
to yield all the elements of a list or vector.

Assume vals is a 10-element vector, how would one express:

&foo{values: &[(vector-ref vals 0) ... (vector-ref vals 9)]}

The use-cases and issues are a little different for 107 vs 108 vs 109.

For SRFI-107 (xml) one might want a list of subelements. For example:

(define items (map (lambda (datum) #<li>&[datum]</li>) data))
(define mylist #<ol>&[items]</ol>)

In this case it seems reasonable to deal with an enclosed
expression whose value a list of elements by just adding them
all as children.  I.e. the list is implicitly flattened.

For SRFI-109 (strings) one can always use a helper function
that concatenates the values.  For example:

#{values: &[(apply string-append vals)]}

Also, if the implementation support Common Lisp-style format
specifiers, one can use the ~{...~} controls.  For example
(and this works in Kawa):
&{values:&~{ &[vals]&~}}
This format each element of vals, with a prefix space.
(Infix-only space can be done with the ~^ specifier.)

For SRFI-108 (named constructors) it doesn't seem right to
implicitly flatten the list.  An individual named constructor
might do so, but the framework should not.  Which means it is
desirable to have some kind of looping construct or syntax to
perform explicit flattening.

This could be the ... used in syntax-rules templates:

&foo{&[vals ...]}

However, this usage of ... doesn't quite match that used in
syntax-rules, which depends on a kind of iteration valuable.

Another idea is to use '@' as a slice operator, since
it is already used as such as part of ",@" unquote-splicing:

&foo{&[@vals]}

In both cases '@' and '...' may be generally useful, not
just for enclosed expressions.  For example:

(apply proc a b c rest) === (proc a b c @rest)

I'm exploring both of these ideas for Kawa, but they're
far from fully baked, and I don't want to hold up SRFI-10[789]
until they are.

Not sure what the answer is, but I'm leaning towards the following:
* Implicit flattening for SRFI-107.  (Modulo that John Cowan
prefers SRFI-107 a pure reader form, without semantics.)
* No implicit flattening for SRFI-108 or SRFI-109.
* Individual named constructors (SRFI-108) may of course do
implicit flattening.
* Explicit flattening has to be done by the programmer, if
desired.  For SRFI-109 ~{...~} format specifiers are an
acceptable though cryptic (and non-required) solution.
* Think more about more generally useful explicit
flattening and operation operators for Kawa and maybe a SRFI.

By the way, it worth pointing that if we had implicit
flattening then we'd have a binding for the $<<$ and $>>$
forms that is both portable and "invisible" (i.e. implicitly
binds to no characters in the output):

(define $<<$ (list ""))
(define $>>$ (list ""))
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/