On Tue, Jul 14, 2009 at 08:47:52AM +0000, Tobias wrote:
> 
> Tobias <tobias.herp@gmx.de> added the comment:
> 
> > 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".

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.

Fine with me. Just think about sets of ranges, not just sets of numbers
and you understand what I mean. Then there is no conceptual difference
between

1 or 2 or 3

and

1 or 2 or 3 or 4;5

(I'm using "or" not comma here to show that we can leave out the
brackets in the general case if the syntax isn't ambiguous.)

or degenerate ranges
- a = x

so we can translate the thing above to
(a=1 or a=2 or a=3 or (a>=4 and a<=5))
or use the "between" operator or use "in" for separate ranges. Thats the
*backend*. I'm arguing about the frontend.

> 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.

I have no problem of using sets in python and/or sql to implement the
mini-query language for numbers and dates. I just don't want to force
that concept on the users of that mini-language.

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

> > 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.

No. For the search engine we only search for words. These cannot
contain spaces.

Why? I'm more concerned with
- providing backward compatibility
- making it easy for users
- treating integers and dates alike

> > 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*.

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

> Roundup date expressions are very special beasts, and everyone will
> understand the difference.

I don't think so. And I don't want two different code-bases for dates
and ints.

No.

I still can't understand why you want to support sets of numbers *and*
sets of ranges. Is there a good technical argument for that -- syntax
left aside for a moment? I think we can come up with a good syntax that
covers all.
Are there search terms that use your number-sets which can express
queries you cannot express in terms of sets of ranges? Mathematically,
leave aside the syntax for a moment. (and I think the answer to that
question is 'no').
So I ask for keep-it-simple: We don't need to introduce sets of numbers
if we already have sets of ranges.

Just for the record: I'm holding a Phd in computer science, so don't try
to teach me set theory. 
On the other hand I've found that the users of roundup I'm working with
will have a hard time understanding set theory. Thats why I argue that we
should not put this into our mini-query-language if it can be avoided.

> "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 ;-)

Note that I still think that set-queries of numbers are a special case.
You usually want ranges. Or sets of *ranges*. So lets make the number a
special case of the range and come up with a convenient syntax.

No we don't need to "anyway". And the more I'm thinkig about it I tend
to abolish the comma too. That would give us a form where we can leave
out the brackets/parentheses in the general case.

I don't think we need that. If we use the 'or' syntax we can leave out
the brackets and can rewrite that as

1 or 2 or 5

My syntax is more convenient:

3;7 or 9 or 10 or 11

See above. If we only allow 'or' (and not ',' or space) we can leave out
the brackets.

We already have sets of ranges. I'm arguing against a separate
set-of-nubmers concept.

Ralf