Too Many Ways?

[Brian Schröder]

Brian Schröder ha scritto:




well, just because
x...y
could be parsed both as
(x..).y
and as
(x...y)

Should have thought more myself.

The other problem I see now, is that if i can have
x..

Id also expect
..x

And on the other hand, one can always use

INFINITY = 1.0/0.0

and write

-INFINITY..INFINITY

and thats even better readable.

And for own classes it is also possible to create "your own infinity" .

So on further thinking -1 because it would add to language noise.

regards,

Brian

 

[gabriele renzi]

Zach Dennis ha scritto:

Did you mean to say "Submit RCR, you may get many votes" or "you could
submit RCR and get many possible votes, but I dont think it's worthwhile"?

the former, sorry for being unclear
anyway

I will have to do some more thinking on this. I do not know if I like
the idea of an infinite Range. It may do more harm then good, but I will
have to think it out more carefully before I settle at a conclusion.

Actually I meant 'indefinite' not 'infinite', sorry again for being
unclear.
I just suggest that the 1..-1 notation (only meaningful in an array
slicing context, anyway) be superceded from a shorter yet expressive one.

 

[Ara.T.Howard]

Still, it's the 'larger' Range.

not really - you cannot compare infinities like that:

infinity + 1 = infinity

better to simply use the term inclusive or exclusive to stay out of trouble.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[gabriele renzi]

Brian Schröder ha scritto:

<snip>

I've been unclear, sorry.
I don't feel the need for an infinite range (even if IIRC haskell has a
similar data structure with the sme syntax so maybe there is some use
for it I just hate to write:
anarray[x..-1]

 

[James Edward Gray II]

You added more syntax then needed. "-" has higher precendence then
"...".

(0..x.size-1).each

That appears quite clean and it only one more character then:
(0...x.size).each

And it works today with no changes, so you can start using it
immediately while those of us that like ... keep using it.

There's a pretty big irony in the two thread flying by on Ruby Talk
right now. They're really the same thing. Even better, I'm sitting
over here reading the release notes to the new Java 1.5 (sorry, it's my
job).

For those of you who don't know, Java just got some fancy new features
like Generic Types, Autoboxing for Primitives, Variable Length
Parameter Lists for Methods, etc. I keep expecting to see Larry Wall
or matz in the credits somewhere.

I guess we could examine all those features too, see if we really need
them. Java has sure made it a LONG way without them. They finally
added them though, to give developers a choice. Make the easy things
just a little bit easier. Choice is good, I think.

I like it that a..b-1 is the same as a...b. It means I can choose what
I'll use. collect() is the same as map() too, as are size() and
length(). Would you believe I actually use both? I've caught myself
using size() when I think it's closer to my meaning and length() when I
feel it is, though I have know idea how I decide this, their meanings
being so close. I just choose.

We could take away that choice I guess, but you'll have to take away
alias too, or I could put it back. And then even without alias, I
could add the method to the needed class myself, calling the alias.
Failing that, I guess I could just hack the Ruby interpreter... Wow, I
have a lot of choices.

The similar methods are documented together, so I really think this is
hard to miss. You can learn one and basically ignore the other, until
you read it in someone's code, then you'll learn, "Oh, collect() is
just another name for map(), which I already know."

I'm a fan of choice. I don't think we should introduce 10 aliases for
each method, but a few here and there to appeal to a wider audience is
a really nice touch, I think. a..b-1 is also a...b. Nifty, use the
one you can remember and/or like better. I think we should support
choice, not take it away. The Java team is starting to get it, so I
say there really must be hope for us all. Just my two cents, for both
threads.

James Edward Gray II

P.S. If it's not obvious, this message is NOT about whether or not ..
and ... are backwards, unless you're position is that we should just
kill ... to fix it. Do I think they're backwards? Haven't really
thought about it, which to me means it isn't painfully wrong. Should
we swap them? No, I would be against trading any two pieces of syntax
to exact opposite meanings at this point. Again though, this is a
separate issue to me.

P.P.S. Those of you who use collect() are wrong!

 

[Austin Ziegler]

I agree. Having a separate operator for exclusive ranges just
complicates things. Why not just have '..' and the user can specify
either start..end or start..(end + 1) ?

Because of the [start, end] and [start, end) difference. They *are*
different and it is very useful to have both forms.

-austin

 

[Zach Dennis]

not really - you cannot compare infinities like that:

infinity + 1 = infinity

better to simply use the term inclusive or exclusive to stay out of
trouble.

I agree with Ara. I do not like the term infinity for the example Ara
gave and for other examples:

Example 1: I have infinity marbles, I give you all of my marbles. I
now have 0 marbles. Infinity - Infinity = 0
Example 2: I have infinity marbles, I give you 10 of the marbles. Now
you have infinity and I have infinity marbles. Infinity - 10 = Infinity

There is to much mathematical error when dealing with the Infinite!

Zach

 

[Peter Hickman]

Example 2: I have infinity marbles, I give you 10 of the marbles.
Now you have infinity and I have infinity marbles. Infinity - 10 =
Infinity

No! Wrong!

Example 2: I have infinity marbles, I give you 10 of the marbles. Now
you have 10 and I have infinity marbles. Infinity - 10 = Infinity

There is to much mathematical error when dealing with the Infinite!

So it would seem, lets skip transfinite numbers then.

 

[Zach Dennis]

No! Wrong!

Example 2: I have infinity marbles, I give you 10 of the marbles.
Now you have 10 and I have infinity marbles. Infinity - 10 = Infinity



So it would seem, lets skip transfinite numbers then

Oops...on my behalf. You are correct Peter. Thank you for pointing this
out.

Zach

 

[Ara.T.Howard]

actually, I thought till one moment ago that ... was going to be deprecated.
I looked up and found that I misremembered this:
http://www.rubyist.net/~matz/slides/rc2003/mgp00025.html

I'd strongly advocate the elimination of z...y . It is completely non
obvious, and it has no advantage _i can see_ over x..k .

programming using the 'offset, length' paradigm lead to much more elegant code
than a 'start, end' paradigm and is used everywhere because of it. consider

words = %w( one two three four )

#
# process elements two at a time
#

len = 2
r = 0...(a.size / 2)
r.each{|off| p words[off, len]}

# vs

len = 2
r = 0..((a.size / 2) - 1)
r.each{|off| p words[off, len]}

#
# process first/last half of a
#
n = words.size
a = 0
b = n / 2

puts "first #{ b }"
(a...b).each{|i| p words}

puts "last #{ b }"
(b...n).each{|i| p words}

# vs

puts "first #{ b }"
(a..(b - 1)).each{|i| p words}

puts "last #{ b }"
(b..(n - 1)).each{|i| p words}


in short i think we'd since an instant rush of 'off by one' errors if ruby
disallowed the '...' operator and obfusicate many elegant algorithims which
follow this paradigm.

regards.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Zach Dennis]

I'm a fan of choice. I don't think we should introduce 10 aliases for
each method, but a few here and there to appeal to a wider audience is
a really nice touch, I think. a..b-1 is also a...b. Nifty, use the
one you can remember and/or like better. I think we should support
choice, not take it away. The Java team is starting to get it, so I
say there really must be hope for us all. Just my two cents, for both
threads.

I am not saying requesting we kill '...' . I was merely pointing out an
inconsistency in the language and how the language is expected to be
"easy, elegant ant natural" to increase the enjoyability of programming
to the programmer. '...' is none of those things. '...' appears to be
backwards and there seems to be no logical reasoning for why '...'
should stay as '...' except for "that is how it has always been".

This argument works for those of us who have learned to do things this
way and are content with it, but should we impose these rules for future
versions of the language which will entail future programmers to use
Ruby. Why continue to teach something that doesn't make sense? This
approach seems flawed to me especially with Ruby supposing to "make
sense". Should it not make sense in all areas possible (or at least
stride to do so?) Again I am just asking hypothetically, I do not plan
to go make a RCR for Ruby 1.9.

When I originally posted I thought someone would uncover the golden gun
of reasoning for '..' and '...', but it appears that there is none and
people accept things "as-is" for the sole purpose of them being "as-is".

Zach

 

[Ara.T.Howard]

It's the distinction between
0..5 == [0, 5] # mathematical notation
and
0...5 == [0, 5) # mathematical notation

In part, this is something that Ruby inherits -- I *think* -- from
Perl, which uses the .. and ... in this way.

thank you austin for pointing this out. just to be clear - i'm not opposed to
changing the '..' vs. '...' notation : i'm opposed to eliminating a consise
way to represent both inclusive and exclusive ranges. it would be a grave
mistake to disallowed exclusive ranges as they are the 'norm' in all of
computer science.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[David N. Springer]

From an intellectual point I sort of understand the '..' and '..'
notation. What distracts me most, is the visual difference ... that the
visually longer three dot form contains fewer elements than the shorter
two dot form.

(1..5).to_a
=>[1,2,3,4,5]
(1...5).to_a
=>[1,2,3,4]

That's a dangerous consideration -- and not always true:

irb(main):001:0> (1..5).include?(4.99)
=> true
irb(main):002:0> (1...5).include?(4.99)
=> true
irb(main):003:0>

1...5 doesn't include only the numbers 1, 2, 3, and 4 -- it contains
the infinities between the numbers, and the infinity between 4 and 5,
but not 5 itself.

-austin

I see the distinction but a some point the reality of the limits of the
internal representation lets us down:

irb(main):001:0> (1...5).include?(4.999999999999999)
=> true
irb(main):002:0> (1...5).include?(4.9999999999999999)
=> false
irb(main):003:0> 4.999999999999999 < 5
=> true
irb(main):004:0> 4.9999999999999999 < 5
=> false
irb(main):005:0>

 

[Florian Pflug]

But one could argue that, since 1...5 is an open set and 1..5 an closed
set, the open set must of course contain more open space. And 1...5
contains argueable more "open space" than "1..5" ;-))

greetings, Florian Pflug

 

[Massimiliano Mirra - bard]

I have been thinking lately about rangess and I will give you the two
different range operators and what comes to mind first.

Whose mind?

Operator One: .. (two dots)
Example: 1..5
What comes to mind: Exclusive
How It Works: Inclusive (the last number 5, is included)

Operator Two: ... (three dots)
Example: 1...5
What comes to mind: Inclusive
How It Works: Exclusive (the last number 5, is excluded)

I'd be curious to know, provided it lies close enough to the
consciousness level, why 1..5 brings to your mind the idea of
exclusive whereas 1...5 brings to your mind the idea of inclusive.

To me 1..5 is `from one to five', and should I say to someone ``go
from point one to five'', I'd surely mean it to reach point five in
the end, not just stop short of it.

1...5 is simply nothing I had ever thought of and, as such, it
couldn't go against anything that came to mind (since nothing came to
mind). A couple of years ago someone here wrote something like ``Just
think of it as the same of 1..5, just with the 5 pushed aside and thus
not reached''. I didn't need anything else.

But, of course, I might just be one among a thousand with something in
my head wired backwards. Then again, I might not.

Massimiliano

 

[Bill Guindon]

I'd be curious to know, provided it lies close enough to the
consciousness level, why 1..5 brings to your mind the idea of
exclusive whereas 1...5 brings to your mind the idea of inclusive.

On 1st pass, with little prior knowledge to influence it (my perl was
years ago), I assumed "one more dot means one more digit". It was as
simple as that.

Of course, then I read the docs, found out I was wrong, and retrained
my brain. Now I read it as "up to" and "up to, but not including"
(which is a hell of a lot to hang on one dot).

 

[Zach Dennis]

Whose mind?

Obviously the email is going to be based on a bias by the OP...me. The
whole sentenced was based around "I have", "I will", etc...so it should
be of no surprise to bridge the next logical gap and consider it to be
my mind. Nor did I ever mention or even give the slightest implication
that this was the result of anyone else's mind, or a collective of
thoughts from a group of people.

I'd be curious to know, provided it lies close enough to the
consciousness level, why 1..5 brings to your mind the idea of
exclusive whereas 1...5 brings to your mind the idea of inclusive.

The '..' and the '...' are used only in the context which includes both
of those operators (or methods..i know they are methods). If you take
them outside of that context to where '..' is viewed separately then I
agree I can come to the same conclusion as you. It means 1 to 5. But
when you put it in a larger context which includes '...' and consider
the behavior of both '..' and '...' then it appears that they are
backwards. Two dots is less then three, so you would assume that two
dots would include less values, then that of three dots. I have not seen
a reasonable argument for why the other way around, besides that it is
the way it is done now.

1...5 is simply nothing I had ever thought of and, as such, it
couldn't go against anything that came to mind (since nothing came to
mind). A couple of years ago someone here wrote something like ``Just
think of it as the same of 1..5, just with the 5 pushed aside and thus
not reached''. I didn't need anything else.

But, of course, I might just be one among a thousand with something in
my head wired backwards. Then again, I might not.

I don't think your mind is wired backwards. I think you are arguing your
point based on '..' alone. And I agree with you when I do that.

My best guess is that the '..' was created in whatever language it
showed up in first. Later down the road someone came up with the idea to
have an "exclusive" range operator and they implemented the '...' so
they would not break compatibility.

I do not have a problem with the current behavior except that it isn't
natural, and it isn't the expected behavior *unless* you have already
learned what '..' and '...' do. My hope is that as Ruby becomes a better
language in the future that this be rethought.

I think that as Ruby becomes more natural it should do so in every way
possible, where it makes sense (which is of course Matz's decision to
make, where these improvements are made). We have already discovered on
this thread alone that many people had to retrain their brain to accept
the behavior of '..' and '...'. Wouldn't it be great if future
programmers didn't have to do that? If we made it one more step more
natural to where it makes sense to the programmer?

Of course these are rhetorical questions. I don't expect anyone to
answer them. If Matz decides that the Range theory I have posted in this
thread isn't the direction he wants to take Ruby in, then I am 100% ok
with that. I have already trained my brain to accept '..' and '...'
behavior. If he thinks it is a good idea then that is 100% ok with me to.

I trust that whatever direction Matz takes Ruby in will be the best one
and I do not want to influence his decision unless some of my reasoning
or argument makes sense for him to do. I will still use Ruby either way.
You don't see me posting this on a Perl list now do you?

Zach

 

[Brian Candler]

"Duplicate names and techniques to do the same

atomic thing ends up confusing the nubys" ...
#insert your own examples here

I second your example of:

def foo
...
yield stuff if block_given?
end

versus:

def foo(&blk)
...
blk.call(stuff) unless blk.nil?
end

I think I would have found iterators much easier to get my head round if I
had seen the second, rather than the first, initially.

And if you use the first syntax, there is the leap you have to make sooner
or later: "hang on - how do I pass this block to another method?"; or
conversely, "I have a proc object, but how do I pass it to a method which
expects a block?"

Regards,

Brian.

 

[Dave Burt]

Sometimes I'm tempted to think this is already the way; in the doco for
these duplicate methods, usually one will simply be a reference to the
other. I think it would be nice if one was "canonical".

Bad example:
% ri Hash#each_pair
--------------------------------------------------------- Hash#each_pair
hsh.each_pair {| key, value | block } -> hsh
------------------------------------------------------------------------
Synonym for Hash#each.

I suppose that's my wish, too. As unrealistic as it may be.
("Sorry, play time is over. All your existing code may crash and burn, but
in the end it'll make you a better programmer.")

What I'd think was nice is if a bunch of things were officially
deprecated; no runtime warning (although perhaps with a -w or something)
but where exact duplicates exist, the King from on High would say "thou
shalt use #foo and not #bar". (I was even thinking of removing the
deprecated names from the documentation, but then that's no good for
someone needing to decipher existing code.)

(snip)

 

[Markus]

The '..' and the '...' are used only in the context which includes both
of those operators [...] when you put it in a larger context which
includes '...' and consider the behavior of both '..' and '...' then
it appears that they are backwards. [...] I have not seen a reasonable
argument for why the other way around, besides that it is the way it is
done now. [...] My best guess is that the '..' was created in whatever
language it showed up in first. Later down the road someone came up
with the idea to have an "exclusive" range operator and they implemented
the '...' so they would not break compatibility.

I do not have a problem with the current behavior except that it isn't
natural, and it isn't the expected behavior *unless* you have already
learned what '..' and '...' do. My hope is that as Ruby becomes a better
language in the future that this be rethought. [...] Wouldn't it be
great if future programmers didn't have to do that? If we made it one
more step more natural to where it makes sense to the programmer?

By the same logic you could argue (as some did, years ago) that the
terms String and List are backwards. In non-programming usage, a "list
of things" connotes propinquity while a "string of things" implies some
sort of linkage of each to its successor. Yet their usage in computer
science is the opposite of this.

Should we then start calling sequences of characters in adjacent
storage "lists" and things threaded together by pointers "strings" so
that future programmers don't have to retrain their brains?

This may sound absurd, but only a few decades ago the question was
raised in much the same spirit as the present discussion.

-- MarkusQ