[#46] Introduce ... type for lists creation

[vrom911]

Resolves #46

[vrom911]

Okay, I designed it so that when you write [Hour ... Second] and [Second ... Hour] it would behave the same way. Tell me if that is not the best choice..

[chshersh]

@vrom911 Nice! I like this solution. Probably, most often mistake will be to write Microsecond ... Millisecond or something like that. Current interface is good to me! I was thinking about type error in case arguments are not ordered. But current behavior is much more convenient. I think you can squash, I will review it once more and most likely approve.

[int-index]

I'd prefer a type error when lower/upper bound are not in order.

[chshersh]

@int-index Could you explain why Type Error is better than arbitrary order?

[int-index]

Could you explain why Type Error is better than arbitrary order?

Because I believe that source code should reflect author's intention.

Let's consider two cases:

• person (A) is unware of the flipped semantics
• person (B) is aware of the flipped semantics

If formatting with [Hour...Second] corresponds to 1h5m35s, then the intuitive semantics that person (A) infers is "write time components in specified order". Then, person (A) would expect [Second...Hour] to provide formatting like 35s5m1h, which it doesn't, and it's unexpected and frustrating.

Now consider person (B). Why would he prefer to write [Second...Hour] over [Hour...Second]? Now he has an arbitrary decision to make each time he writes a time range. One option is better because its order corresponds to the resulting formatting, so the other option now seems redundant, and it becomes one more bit of arcane knowledge of how to do things right (a similar case is return vs pure, fmap vs liftM, etc, often it's hard to decide which one to use).

[chshersh]

@int-index Ok, sees legit and convincing.