> I'm considering enumerations of numbers (1,2,3)
> to be enumerations of degenerate ranges (with a single point).
IMO, the more natural way would be to consider them sets (for our topic
here, I consider sets and enumerations equivalent).
We don't need to invent such a strange beast like a "degenerate range".
A set can have 0, 1, 2 or more members. It is a natural choice.
Btw, SQL "WHERE" supports:
- a BETWEEN x and y (for [x; y] ranges)
- a IN (x, y, z, ...) (for {x y z ...} sets
Sets do exist. We don't have to invent them. They are known to Python
and to SQL. There is definitely no need to work around them. This
would be as useful as a Brainfuck
(http://en.wikipedia.org/wiki/Brainfuck) implementation of Roundup.
> This makes the curly-brace syntax obsolete. We can specify it as
> [1] or [2] or [3]
> I agree that this is not a very nice syntax.
Right. And unnecessary.
> IDs are *strings* in roundup.
Yes, but
- they *look* like integers
- they can only be strings which can be interpreted as integers
- they *should be* integers
- they are considered integers by users
- concerning search expressions, they should be considered integers
by Roundup.
> That's why you can combine them with space!
That's not logic. Strings can *contain* space.
It would be very, very bad to have different expression syntax for
integers and ids.
> date expressions like '. -1d' can contain spaces.
> That rules out the space as a separator.
Wrong. That rules out the space as a separator *for dates*.
Roundup date expressions are very special beasts, and everyone will
understand the difference.
We *need* space as a separator for ids, and thus for integers.
We *would* consequently support it as a separator for floats if we
decided to support sets (and [x; y] ranges) of floats.
> Ah, curly braces for enumerations?
Yes, of course. As far as search expressions are concerned,
enumerations are sets. Have a look at
http://en.wikipedia.org/wiki/Set_theory :
"The union of {1, 2, 3} and {2, 3, 4} is the set {1, 2, 3, 4}."
Thus, we simply would support the mathematical notation of sets.
It will be very easily understood. Nobody will expect a C block or
Python dictionary in a search expression ;-)
For convenience, we would allow "{1 2 5}" as the equivalent notation for
"{1, 2, 5}" (which we must anyway because of the existing id search syntax).
Curly braces for sets are not only *a* solution; they are *the*
solution. There is definitely no reason why we should try to avoid them.
Remember my proposal: All of
- "1 2 5" (neede because of existing id search)
- "1, 2, 5"
- "{1 2 5}"
- "{1, 2, 5}" (the mathematical notation)
are equivalent.
Curly braces allow us to threat sets as sets, and to easily combine sets
with ranges:
[3; 7] or {9, 10, 11}
is much more convenient and understandable than
[3;7] or [9] or [10] or [11]
The idea is in the world. If we implement something new now and miss the
opportunity to support sets, complaints are sure to come.
To be continued in a next message, addressing the other topics... |