On Fri, Apr 20, 2012 at 3:04 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> There's a few places where our grammars would be much simpler (less
> repetition)
> if we had a combinator that meant "this or that or both, but in this order".
> (We have the double-bar, which means "this or that or both", but there's no
> ordering requirement there.)
Note that we already have a "zero or more of these, in order" pattern:
a? b? c?
It's just that implementing a "one or more of these, in order" pattern
requires some confusing grammar contortions:
[
a b? c?
|
b c?
|
c
]
This is obviously ugly, confusing, and repetitive.
However, the only place I know of that uses this pattern is the
radial-gradient() grammar. This is an odd case because, while the
"one or more in order" combinator is a valid solution to the grammar
woes, the real problem there is simply that it's very awkward to deal
with comma-separated lists when some components may be omitted.
If I had an "comma if required" symbol, I wouldn't need the above
combinator for radial-gradient().
The "comma if required" symbol would also help with other grammar
issues, like the stacking brackets for optional arguments at the *end*
of a comma-separated list. For example, I go through some contortions
in the grammar for the image() function:
image( [ <image-decl> , ]* [ <image-decl> | <color> ] )
This ensures that I can have (a) a list of <image-decls>, (b) a list
of <image-decls>s with a <color> at the end, and (c) a <color> all by
itself.
With maybe-comma, it could look like this:
image( <image-decl>#? MAYBECOMMA <color> )
And since I only say <image-decl> once now, I could potentially even
inline that definition (though I do use it in the prose below, so
maybe not).
So anyway, are there more places that would benefit from "one or more,
in this order" than radial-gradient()?
~TJ