GenericRange and @experimental

I'm with whoever brought up that this GenericRange isn't Generic enough. I can't extend it for anything other than numeric classes. I'd prefer it with a view bound over a Discrete[T] plus Ordering[T], so that I could use it to extend anything from date&time to arbitrary abstract data types.

On Wed, Nov 4, 2009 at 6:42 PM, Seth Tisue <seth@tisue.net> wrote:

I hadn't realized before Paul sent out his list of @experimental stuff
that GenericRange was @experimental.  Have any serious objections been
raised to including it in 2.8...?  It makes using numeric types other
than Int much more convenient.

I haven't studied the design or implementation, but I have been using
GenericRange for some months now without issues, in a "it just works and
I don't have to think about it" kind of way.

For those who haven't seen GenericRange, it lets you write such
things as:

 1L to 10L
 BigInt("1") to BigInt("10")
 0.0 to 1.0 by 0.1

--
Seth Tisue @ Northwestern University / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

--
Daniel C. Sobral

Veni, vidi, veterni.

>>>>> "Daniel" == Daniel Sobral writes:

Daniel> I'm with whoever brought up that this GenericRange isn't
Daniel> Generic enough.

Do you guys mean this in a "it's good, but someday wouldn't it be great
if it were even more awesome" way? Or in a "it sucks let's axe it from
2.8" way? The 2.8 train is in the process of leaving the station, so at
the moment it's too late to wish for awesomeness that isn't even
designed or implemented yet. I'd hate to lose the ability to say "1L to
10L" in 2.8 just because of some theoretical future possibility of being
able to say other things too.

(not that we shouldn't discuss potential future improvements, perhaps on
scala-debate or something, but at the moment, I suggest we keep this
thread focused on what's of immediate relevance to the 2.8 release)

On Wed, Nov 4, 2009 at 10:24 PM, Seth Tisue wrote:
>>>>>> "Daniel" == Daniel Sobral writes:
>
>  Daniel> I'm with whoever brought up that this GenericRange isn't
>  Daniel> Generic enough.
>
> Do you guys mean this in a "it's good, but someday wouldn't it be great
> if it were even more awesome" way?  Or in a "it sucks let's axe it from
> 2.8" way?  The 2.8 train is in the process of leaving the station, so at
> the moment it's too late to wish for awesomeness that isn't even
> designed or implemented yet.  I'd hate to lose the ability to say "1L to
> 10L" in 2.8 just because of some theoretical future possibility of being
> able to say other things too.
>
> (not that we shouldn't discuss potential future improvements, perhaps on
> scala-debate or something, but at the moment, I suggest we keep this
> thread focused on what's of immediate relevance to the 2.8 release)
>
I have no sring opinions on GenericRange. But it's indicative of a
larger problem. Do you do the quick thing now, with the risk of making
the more general thing later impossible without breakage, or do you
wait until you have something more general? That's why I proposed the
incubator idea.

Cheers

I mean this in a "we cannot extend it to cover other use cases". Which I'm pretty sure was what the other guy meant.   For instance, let's say I want a range from today to the end of the month, by 1 day. If such thing is common in my application, then I may well create the necessary implicit to support it.   However, the implicit required by GenericRange is Integral, which extends Numeric. Does "abs" make any sense for dates? Or most of the other abstract Numeric methods? No. And they may make even less sense for other stuff.   And let's look at the methods inside GenericRange itself. Can we do "multiply the entire range by some constant"?   So, back to what would be really generic. I need to be able to tell the boundaries of the range, I need to find out if something is inside or outside the range, and I need to be able to step through it. Given a step unit, I need to be able to add it to a boundary and get a new boundary back. Ideally, the boundary types and the step type would not, necessarily, be the same.   This would account for all methods inside GenericRange except "*". To me, that is a small loss for a greater gain. But, of course, it would require something other than "Integral" as implicit. Something simple and to the point.

On Wed, Nov 4, 2009 at 7:24 PM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Daniel" == Daniel Sobral <dcsobral@gmail.com> writes:

 Daniel> I'm with whoever brought up that this GenericRange isn't
 Daniel> Generic enough.

Do you guys mean this in a "it's good, but someday wouldn't it be great
if it were even more awesome" way?  Or in a "it sucks let's axe it from
2.8" way?  The 2.8 train is in the process of leaving the station, so at
the moment it's too late to wish for awesomeness that isn't even
designed or implemented yet.  I'd hate to lose the ability to say "1L to
10L" in 2.8 just because of some theoretical future possibility of being
able to say other things too.

(not that we shouldn't discuss potential future improvements, perhaps on
scala-debate or something, but at the moment, I suggest we keep this
thread focused on what's of immediate relevance to the 2.8 release)

--
Seth Tisue @ Northwestern University / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

--
Daniel C. Sobral

Veni, vidi, veterni.

On Wed, Nov 04, 2009 at 07:52:33PM -0200, Daniel Sobral wrote:
> And let's look at the methods inside GenericRange itself. Can we do
> "multiply the entire range by some constant"?

Yeah, maybe you should review the commit history.

Minor nit. It still receives an Integral as implicit.

On Wed, Nov 4, 2009 at 8:26 PM, Paul Phillips <paulp@improving.org> wrote:

On Wed, Nov 04, 2009 at 07:52:33PM -0200, Daniel Sobral wrote:
> And let's look at the methods inside GenericRange itself. Can we do
> "multiply the entire range by some constant"?

Yeah, maybe you should review the commit history.

--
Paul Phillips      | Simplicity and elegance are unpopular because
Analgesic          | they require hard work and discipline to achieve
Empiricist         | and education to be appreciated.
i pull his palp!   |     -- Dijkstra

--
Daniel C. Sobral

Veni, vidi, veterni.