On Tue, Jul 14, 2009 at 09:30:27PM +0000, Tobias wrote:
> 
> >> 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.

You're mixing up implementation is SQL and the input syntax. You
currently can specify a range
date1;date2
or a single date
date1

these are roundup.date.Range objects
The translation to SQL is something completely different.

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

I'm just taking the current implementation which works fine.
It's a matter of input syntax to make it usable.

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

I agree. I just don't want two diffenent sorts of set, sets of numbers
and sets of ranges.
Do you agree that we *need* sets of ranges?
Do you agree that your proposal generates two distinct types of sets (of
ranges and of integers)?

For SQL as far as I know there is no generic regex search in roundup.

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

If find these clear and concise.

> The Zen of Python (http://www.python.org/dev/peps/pep-0020/) says:
> 
>  (2) Explicit is better than implicit.
>  (7) Readability counts.

I thinks thats a heavy argument *against* curly braces.

> (10) Errors should never pass silently.

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

Why do you think python has left out the braces for statement blocks?

Curly braces not brackets, yes.

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

I'm thinking of users of some trackers I maintain.

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

Hmm. So our tastes are different there. For me the example

1 or 2 or 3 or 4;5 or 6

is perfectly understandable. Note that meanwhile I think we should *not*
use commas or spaces instead of 'or'.

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

You are arguing that "explicit is better than implicit" but want to make
a space and implicit indicator of "or". I can't follow that.

And, yes, I want to treat dates and integers (all things where range
searching makes sense) alike. Thats sound software engineering practice.

So we might want to fix that. But that would be major surgery because
you'd have to change the representation of ids -- something at the very
core of roundup. I also don't think that in the shortterm you will be
able to apply our little query-language for ranges to IDs. IDs are
strings in SQL currently.

No. For integers no spaces are currently allowed/used.

No.

No.

:-(

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

The difference is not minimal since you're obsoleting all stored queries
of all users.

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

You can still compile our expressions to something using sets of numbers
in python and/or SQL. My point is the input syntax should be easy to use
and understand with a minimum of different notations.

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

Huh? What makes it different from a set by calling it something else?

No.

> > My syntax is more convenient:
> >
> > 3;7 or 9 or 10 or 11
> 
> Well, that's of course a matter of taste.  

Yes. I thinks so.

Simple is better than complex
Beautiful is better than ugly
Readability counts
Special cases aren't special enough to break the rules
There should be one-- and preferably only one --obvious way to do it
If the implementation is hard to explain, it's a bad idea

all argue for an easier syntax.

Except if the concept of sets has to be mastered first.

But you're just trying to introduce more obscure symbols into the query
language, are you? Perl is full of these.

There aren't any expressions that can be formulated in your syntax that
can't be formulated in my syntax. At least you haven't come up with an
example.
There should be one-- and preferably only one --obvious way to do it

You didn't make it as simple as possible.

They impact simplicity very much in my opinion.

Then lets drop the sets of numbers when they're not needed from the user
perspective.

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