The peak of the iceberg, was Range cannot loop down and RCR Integer#pred

[Robert Dober]

Hi all

I was just following the thread about "loop cannot count down" and
was about to propose a monkey patched method which might have been
convenient for the poster.

Like e.g. Range#each_down (bad name I know).

The point is, I cannot, because Range#each is based on succ, and
Range#each_down would be based on pred.

I just wonder if it might not be a good idea to define pred for all
core classes for which succ is defined. I kind of feel stupid not
having suggested that in the first place, now .
(http://rcrchive.net/rcrs/6)

Opinions?

Cheers
Robert

 

[SonOfLilit]

Sometimes #pred is harder than #succ, e.g. singly linked list.

But yes, I agree.

Didn't we have some "step x" syntax?

Googling found it:

http://www.ruby-doc.org/core/classes/Numeric.html#M000139

Aur

 

[Daniel Schierbeck]

Hi all

I was just following the thread about "loop cannot count down" and
was about to propose a monkey patched method which might have been
convenient for the poster.

Like e.g. Range#each_down (bad name I know).

The point is, I cannot, because Range#each is based on succ, and
Range#each_down would be based on pred.

I just wonder if it might not be a good idea to define pred for all
core classes for which succ is defined. I kind of feel stupid not
having suggested that in the first place, now .
(http://rcrchive.net/rcrs/6)

Opinions?

It seems you beat me to it

I'm sure it's been brought up before, and it will surely add more
complexity to a problem that seems relatively small, based on the low
volume of posts on it here on the mailing list.


Cheers,
Daniel

 

[Robert Dober]

It seems you beat me to it

Really my fault, I did not discuss it on the list, I did announce it
though, because it seemed so simple.
AAMOF Matz accepted it surely because of its simplicity.
Really a mistake of mine because it could have been discussed for many
more classes and its impact on Ranges.

Maybe you would like to lead discussion about this one, as I stole the
other one from you ?

I'm sure it's been brought up before, and it will surely add more
complexity

But I do not advocate any usage of #pred, I just advocate its presence.
The user has the power than

to a problem that seems relatively small,

I am not really sure it is that small, this unidirectionality seems
somehow incorrect to me and what I said in the beginning really
bothers me

I cannot iterate through a Range in the reverse sense.

based on the low
volume of posts on it here on the mailing list.

It is not an issue for most of us I did not run into it in two years
of Ruby Programming but now that it was brought up for me an iceberg
emerged.

Cheers,
Daniel

Robert

 

[Daniel Schierbeck]

Really my fault, I did not discuss it on the list, I did announce it
though, because it seemed so simple.
AAMOF Matz accepted it surely because of its simplicity.
Really a mistake of mine because it could have been discussed for many
more classes and its impact on Ranges.

Maybe you would like to lead discussion about this one, as I stole the
other one from you ?
But I do not advocate any usage of #pred, I just advocate its presence.
The user has the power than
I am not really sure it is that small, this unidirectionality seems
somehow incorrect to me and what I said in the beginning really
bothers me

I cannot iterate through a Range in the reverse sense.

It is not an issue for most of us I did not run into it in two years
of Ruby Programming but now that it was brought up for me an iceberg
emerged.

True all dat, I'm just playing the devil's advocate


Cheers,
Daniel

 

[Robert Dober]

True all dat, I'm just playing the devil's advocate

Boy that must be a well paying client

Cheers,
Daniel

R.

 

[SonOfLilit]

-1

Though I can understand why it looks like an iceberg, I think it's one
of those programmer icebergs that we invent to complete sets.

Why?

#succ is for #each .

#each is truly essential, as it gives totally new functonality.

#pred would be for a "different order of each". Now, yes, I do know
that there /is/ some use for reverse-each, but there are MANY OTHER
different order-eaches that are as important. That's why
#to_a.reverse.each is for those cases, that aren't so abundant as to
/need/ a #reverse_each .

If a fast reverse_each is needed, it's usually about numbers and then
you have Numeric#step .


Perhaps there would be use for this as a library, MAYBE even a
standard library, but I wouldn't throw this in core Ruby.

reverse_each isn't more useful than any other case of sorted_each.

Hmm, maybe we should implement that (no ue really, it's so slow it's
better left out of the path of least resistance.)

 

[Robert Dober]

-1

First I want to say that I do not mind hijacking threads at all so be
me guest
But I have not talked about the things you are talking here.

Though I can understand why it looks like an iceberg, I think it's one
of those programmer icebergs that we invent to complete sets.

The iceberg is somewhere else but I do not want to talk about it yet.

Why?

#succ is for #each .

#each is truly essential, as it gives totally new functonality.

#pred would be for a "different order of each".

No sir, your interpretation, I do not advocate a different order of
each I am only talking about #pred.

It was just when I wanted for demonstration purpose implement a
generic reverse_each that I realized that I was missing #pred in a
more general way.

Now, yes, I do know
that there /is/ some use for reverse-each, but there are MANY OTHER
different order-eaches that are as important. That's why
#to_a.reverse.each is for those cases, that aren't so abundant as to
/need/ a #reverse_each .

If a fast reverse_each is needed, it's usually about numbers and then
you have Numeric#step .


Perhaps there would be use for this as a library, MAYBE even a
standard library, but I wouldn't throw this in core Ruby.

What I am talking about *is* already in the core for Integer and I am
drying to apply the same logic to other #succ receivers.

I really feel very bad not having given enough thought to the RCR.

reverse_each isn't more useful than any other case of sorted_each.

That could be argued but is completely OT.

Hmm, maybe we should implement that (no ue really, it's so slow it's
better left out of the path of least resistance.)

Again you'r making valid and reasonable points, no problem with that,
but they are not related to what I wanted to say. Well I feel at
least.

Robert

 

[SonOfLilit]

Well, perhaps we both didn't understand each other

I'll try to be clearer and also understand your points better.

First I want to say that I do not mind hijacking threads at all so be
me guest
But I have not talked about the things you are talking here.
The iceberg is somewhere else but I do not want to talk about it yet.
No sir, your interpretation, I do not advocate a different order of
each I am only talking about #pred.

Have you found useful uses of #pred in a general case (not just for
Integer) that is not essentially built on iteration? If so, I
apologize. I couldn't find any clue to the existence of such from your
post. Would you please elaborate?

It was just when I wanted for demonstration purpose implement a
generic reverse_each that I realized that I was missing #pred in a
more general way.

What is this more general way?

What I am talking about *is* already in the core for Integer and I am
drying to apply the same logic to other #succ receivers.

I really feel very bad not having given enough thought to the RCR.
That could be argued but is completely OT.

What I meant is that any use case of #pred I could find is a use case
that I would attribute to "traverse the range in an arbitrary order".
Not because it is more general, just because it fits the thought
template of it. It "feels" like a particular case of aforementioned
abstraction, and not like a particular abstraction.

Again you'r making valid and reasonable points, no problem with that,
but they are not related to what I wanted to say. Well I feel at
least.

What use cases for #pred did you find that you were missing?

 

[Robert Dober]

Well, perhaps we both didn't understand each other

I'll try to be clearer and also understand your points better.



Have you found useful uses of #pred in a general case (not just for
Integer) that is not essentially built on iteration? If so, I
apologize. I couldn't find any clue to the existence of such from your
post. Would you please elaborate?


What is this more general way?

E.g. for String, alas David just showed me in the countdown thread
that this is not possible.
So this thread stops here from my POV because my ideas are not
"reasonable" anymore.

What I meant is that any use case of #pred I could find is a use case
that I would attribute to "traverse the range in an arbitrary order".
Not because it is more general, just because it fits the thought
template of it. It "feels" like a particular case of aforementioned
abstraction, and not like a particular abstraction.

It is of course a good idea when concieving a tool thinking about
usage, 1:0 for you

What use cases for #pred did you find that you were missing? None anymore

I will try to get some sleep now, and in some days I will throw the
rage of the ruby gods on myself again, and I will talk about the
Iceberg.
For now just as much, *I am not happy with Comparable* and I like the
less pattern.

Cheers
Robert