Sorry, this has become quite long as I'm trying to show my syntax
proposal alongside yours. Some comments on your proposal to use two
distinct syntaxes are at the end.

My proposal boils down to 
- Use ';' or 'to' for ranges
- Use ',' or 'or' for enumeration of ranges (joining them)
- Require brackets/parentheses around ranges if several are used (needed
  only if decimal comma should be supported)
- Make inclusive ranges the default (brackets)
This is compatible with existing date range syntax except that current
date ranges use an implicit interval of [) where the end of a range is
*not* included. So maybe we want the default range to be [)

On Sun, Jul 12, 2009 at 03:04:52PM +0000, Tobias wrote:
> 
> Thus, here is my new proposal:
> 
> expression                resulting set  remarks     
> ==========                =============  =======
> 
> 1; 2; 3                   1, 2, 3        no parentheses nor 'to'

This breaks compatibility with existing date ranges where the ";"
represents the range operator. So this would be a syntax error in my
proposal, if you want to specify an 'or' of three numbers you'd have to
write [1], [2], [3] (except if we don't allow decimal comma, then we can
leave out the brackets yielding 1,2,3)

These two should be equivalent as in the existing date syntax.
The existing syntax uses the ";" as the range operator. And there currently
is no need to write explicit brackets. Think of stored queries by users!

I'd prefer this to mean the same thing as without brackets.

.. and *require* brackets if you want several ranges. This can
disabiguate the use of the ",", i.e, I'd write here
[1 to 3] , [6] Note that you require the brackets/parentheses only if
you want to support alien number formats using a decimal comma. They
wouldn't be needed if we can live with a decimal point (see comments at
the end).

BTW: Roundup represents number as floats and you're using integer
examples only. The real benefit of the round parantheses comes with real
numbers (e.g., "less than" instead of "less or equal")

> [1; 3] or (6; 9)          1, 2, 3, 7, 8
> [3;]                      3, 4, 5 ...
> (3;)                      4, 5, 6 ...
> (3;) or 1                 1, 4, 5, 6 ...
> (3;);1                    1, 4, 5, 6 ...
> 
> With comma support (whitespace after semicolon is optional; whitespace
> after comma is significant):

Uh, I don't think you can train users that whitespace is significant.
Lets use the comma for multiple ranges and the semicolon for ranges.
In that way the comma inside braces/parentheses is used for separation
of ranges while inside the braces/parentheses it can be used as a
decimal comma (if we really want to support that).

> 1, 2, 3                   1, 2, 3        natural language
> 1,2,3                     ERROR          possible ambiguity
> 1,5                       ERROR          possible ambiguity
> (1,5)                     ERROR          possible ambiguity
> (1, 5)                    2, 3, 4
> [1,]                      1, 2, 3, ...
> 
> (all examples with ";" should work, with ";\s*" replaced by ", ";
> commas raise errors unless followed by whitespace or parentheses)
> 
> Thus, the 'to' keyword would imply a closed range, *including* the
> boundary values: "a to b" is the same as "[a; b]" (or "[a to b]").

I'd prefer to make the exclusive range explicit with round parentheses
while making angular brackets (inclusive range) the default. And use the
"to" and the ";" interchangeably (as in the current date implementation).

Fine (execpt for introducing a third form with curly braces here).
A range opening with a round paranthesis may be closed by an agular
bracket and vice versa.

Fine.

Fine.

As said above, I prefer the ';' to mean the same as "to" as it is
currently implemented for date ranges. Otherwise you'll break all stored
queries by all users.

Should be [1 to 3] , [5]
brackets could be left out if we stick to the number format with decimal
point only.

definitely :-)

5 should be bracketed:
[1; 3] or [5]

As said above: I'd prefer to use the semicolon inside braces while using
the comma for enumerating ranges:
[1; 3] , [5]

(1; 3) or [5]

[1] or [3] or [5]
or
[1], [3], [5]

But see below: If we stick to decimal-point only we can leave out
brackets in most examples.

No, don't mix ranges and enumeration.

Require ranges to be bracketed/parenthesized if enumeration is used

Dont mix ranges and enumeration.

Dont mix ranges and enumeration.

Don't use curly braces, this makes the syntax even harder to understand.

Error. If you want no limit, use
[1] or [3;]

This is the same as currently implemented for date ranges. With or
without braces and no matter if inclusive or not would be an extension.

Don't add an additional syntax with spaces.

See my proposal:
- Use ';' for range separation, if several ranges are used, use 
  explicit brackets/parentheses. Use ',' or 'or' for combining ranges.
  This is completely backward compatible.

You're right, [a; b] *will* contain a *but not* b. You just don't see this
because usually you don't have anything that starts/ends at exactly 0:00
on the given date and specifying a search date up to the second is
seldomly done.

Currently if no hours and minutes are specified this means 0:00 and I
don't think this should/can be changed. I've implemented a time-tracker
using roundup and I'm relying on the current date semantics. So I
strongly vote against changing that.

Uh. No please don't. You don't want to maintain two semantics for the
future. Lets make the expression syntax compatible with the current
syntax.

I strongly vote against this proposal. It adds a maintenance headache
(think two sets of regression tests for all time to come).
And think of the user-experience: There are *lots* of stored queries
now (in the trackers I'm running at least). They need to be in one or
the other syntax. So you're forcing users to switch at some point.
I don't want to think about the other option of setting a syntax-flag
for queries containing date expressions ...

> A function which takes an expression and returns a function,
> could/should return a normalized version of the expression as well, e.g.
> replacing all semicolons with 'or' or 'to', like this:
> 
> >>> evaluate("[3;8)")
> ("[3 to 8)", lambda x: 3 <= x < 8)
> 
> If this normalized version would be used in a "refine search" input
> field of the result page -- or displayed/inserted by some AJAX
> functionality -- it could make the whole feature quite self-explanatory.
> The only difficult bit would be about "open" ("()") or "closed" ("[]")
> ranges.

I don't understand the purpose of the expression function.
In most backends you'll want to directly generate SQL. Only for the
non-sql backend(s) (there is only dbm left?) you need to evaluate the
expression.

And another thing for consideration: Although I'm german (living in
austria for quite some time) and here we have a decimal comma instead of
a decimal point, I *can* live with an expression syntax that uses
decimal points for numbers. In that case we can leave out the brackets
in many of my examples. But such a decision shouldn't be taken lightly.
Note that if you support several different number formats, switching of
the browser language will invalidate existing queries!

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  Fax:   +43/2243/26465-23
Reichergasse 131                        www:   http://www.runtux.com
A-3411 Weidling                         email: office@runtux.com
osAlliance member                       email: rsc@osalliance.com