>> We don't need to invent such a strange beast
>>  like a "degenerate range".

> Its already there. Try to specify a search for a single date
> into the search for of dates. You'll find all occurrences of that
> date. These *are* already such strange beasts.

No, not really. Consider the SQL function DATE, which returns the date
part of a datetime field.  This date part is a *value* which can be
compared by equality; it doesn't need to be compared to a range.

SQL:
  WHERE DATE(thedatefield) = date1;     -- single value
  WHERE DATE(thedatefield)
               BETWEEN date1 AND date2; -- inclusive range

(IMO, we should employ such structures whenever possible, as it allows
us to benefit from database engine optimisations)

Of course, this date component is common to a *range* of datetime
values; nevertheless, a date can very well be considered a *value*, when
it comes to search expressions.

(Thanks a lot for this demur, which reminded me of the DATE function ;-)

> Just think about sets of ranges, not just sets of numbers
> and you understand what I mean.

I think I *do* understand very well what you mean:  You'd like exactly
*one* concept for search expressions, and you think this should be
ranges; you even go so far to treat single values of "degenerated
ranges", just to save this idea. IMHO, you go overboard here:

There *are* two fundamental concepts for searching numbers and dates:
- the search for ranges, like already implemented for dates
- the search for sets (or alternatives), like implemented for integers
  and ids.
(for strings, there are regular expressions as well, thus it is a
perfectly normal thing to have different search possibilities for
different types of data)

Everyone understands that.  Most will have felt the need to search for
both a set of known values and a range in one request.  Very few will
have thought of the known values as of "degenerated ranges".

> Then there is no conceptual difference between
> 
> 1 or 2 or 3
> (...)

... no problem with that; we have no differences about the
exchangeability of commas and 'or' keywords ...

> and
> 
> 1 or 2 or 3 or 4;5

I have implemented such a liberal thing, but I went from it.  As it
looks now, it looks nice; but consider

  1, 2, 3, 4; 5

or

  1, 2, 3; 4, 5

These expressions could be interpreted as well, but I consider it
clearly better to demand parentheses here, at least for the range.

The Zen of Python (http://www.python.org/dev/peps/pep-0020/) says:

 (2) Explicit is better than implicit.
 (7) Readability counts.
(10) Errors should never pass silently.

Explicit is better than implicit: better denote a set explicitly if you
have one (and you *do* have a set values -- {1, 2, 3} -- no matter what
you call them).

Readability counts: the curly braces of sets are a widely known syntax,
and it is perfectly readable; no need to mull over precedences.  Braces
are A Good Thing (tm) because they clarify things a lot; for Python
expressions, it has often been recommended to use braces to make the
excecution logic explicit, even when they don't change it.
(we are not talking about LISP here ;-)

Errors should never pass silently:  An explicit syntax would enable us
to tell the user about his defective search expression; if we don't, we
cause inconvenience, because it will happen much more often that a user
doesn't find what (s)he seeked just because the search expression worked
in another way than (s)he thought.

> No. And I've already mentioned that we can simplify it
> in the general case if we can leave out the brackets.

You are quite obsessive about avoiding brackets, are you?

Remember, we don't invent something new here; instead, we'll support a
widely known and easily understood syntax.


>> That's not logic. Strings can *contain* space.
>
> No. For the search engine we only search for words.
> These cannot contain spaces.

Do you really want ordinary users to think about how the roundup backend
implements indexes which certainly look like integers?!


> Why? I'm more concerned with
> - providing backward compatibility

For your "1 or 2 or 3 or 4;5" example, backward compatibility is an
non-issue: combinations of ranges and sets (or, like you'd put it,
several ranges) are currently not supported.

> - making it easy for users

I don't think you make it easy for users if you allow a syntax which can
easily understood wrong, and thus have them think e.g. the issue they
seeked doesn't exist.  Explicit is better than implicit; the 2nd most
important point in the list in the Zen of Python -- a language we all
love for expressiveness and readability!

> - treating integers and dates alike

You are obsessive about treating integers and dates alike; but you are
willing to treat integers and ids differently.  This Is Evil, because --
from a user's point of view -- ids *are* integers, and it is a Very Very
Bad Idea to treat them differently.

* For ids, separation of values by space is supported.
* This is required for backward compatibility (your 1st point)
* To treat integers and ids alike, space support *must* be added
  for integers as well.
* Since spaces *must* be supported for integers and *can't* be
  supported for dates, it is *impossible* to treat dates and integers
  perfectly alike (your 3rd point).

> I don't want to invent two different syntaxes for dates and
> numbers.

You don't need to; I have done it already ;-)

Calm down -- the difference is necessary but minimal.  And it's
well-grounded: by compatibility needs, and by the nature of the data.
(Don't blame me for Roundup's date expression syntax...)

> I still can't understand why you want to support sets of numbers
> *and* sets of ranges.

I want to support sets of numbers because they are simple, expressive,
useful and well-known, and because both Python and SQL support them
(that's 6 reasons).

As for "sets of ranges", see it the other way round; don't call them
"sets of ranges" but a bunch of ranges which are connected by 'or'
keywords (or by commas, if you like, meaning the same).

It is possible to consider the elements of a set or-connected as well:
when checking for

  x in {a, b, c},

this is equivalent to

  x==a or x==b or x==c

Thus, from the search expression point of view, there is really no
difference between a set and this number of or-connected comparison terms.

> So I ask for keep-it-simple: We don't need to introduce sets
> of numbers if we already have sets of ranges.

But people *know* sets of numbers!

> don't try to teach me set theory.

I didn't.  I submitted the link simply to demonstrate that the curly
braces are a well-known set syntax and thus a natural choice.

> My syntax is more convenient:
>
> 3;7 or 9 or 10 or 11

Well, that's of course a matter of taste.  

I like "[3;7] or {9, 10, 11}" much better, and I invoke the Zen of
Python (explicit is better than implicit):

When the range is written down explicitly, *including* the braces, it is
almost impossible to misunderstand the expression.

Some people love Perl for allowing very short (but barely readable)
programs.  I don't.
The Python way is to favour expressiveness to brevity.

Brevity is not everything. And, citing Einstein:
Make everything as simple as possible, but /not simpler/.

Binary numbers are "simpler" than decimals because they get along with
two symbols instead of 10.  There are kinds of simplicity which suit
computers better than humans.  For search expressions, we should suit
the needs of humans.

The curly braces don't impact simplicity very much, but they are
expressive and help avoid errors, and this is A Good Thing (tm).

We have or-connected expressions; think of sets of numbers as an
expressive shortcut for or-connected values. From the user's point of
view, there *are* are no different set concepts for numbers and ranges.