Too Many Ways?

G

Gavin Sinclair

Funny, I never understood what #map did. People used it all the time
and it baffled me. I kept saying "I should learn this method, because
people keep showing how to use it for powerful, terse solutions,
but...I'm baffled."
Then someone showed me the #collect method, and I fell in love. It's
awesome. I extended arrays in Javascript to use it, I love it so much.
...it was a week later than I pulled up the documentation and saw that
they're the same thing.

One of the first things I learned about Ruby was that some methods are
aliased. It never occured to me to dislike this, it's never caused me
any problems, and I _really_ like "map" (the name and the method) and
don't understand where the name "collect" comes from. But 'ri' tells
me they're the same -- it's not like there's a conspiracy to hide the
fact.

Maybe people just need to learn about the alias thing early on, know
how to look out for it, and be happy ever after :)

Gavin

BTW, the method "map" maps a function onto a set and returns the
result. I think that's the right terminology. It comes from
functional languages, anyway. In Miranda (and I presume Haskell):

f(x) = x * 5 + 1
map f [10..15] # -> [51, 56, 61, 66, 71, 76]
 
Z

Zach Dennis

Henrik said:
Hi!

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.

I think the visual difference is exactly why it doesn't make
intelluctual sense. The intellectual sense/point appears to have no
place in language syntax without a visual distinction because syntax
itself cannot be described non-visually. Please correct me if I am wrong.


Zach
 
M

Michael Neumann

Gavin said:
Funny, I never understood what #map did. People used it all the time and
it baffled me. I kept saying "I should learn this method, because people
keep showing how to use it for powerful, terse solutions, but...I'm
baffled."

How would you feel if you were forced to use #map all the time? That's
why I think it's good that Ruby follows TMTOWTDI. Python for example
AFAIK only provides map() and #collect comes from Smalltalk, I think.
Now, everyone from both worlds feel happy in Ruby ;-)

Of course when reading others' sourcecodes you'll get into trouble. But
I don't as often as I write new code.
Then someone showed me the #collect method, and I fell in love. It's
awesome. I extended arrays in Javascript to use it, I love it so much.

...it was a week later than I pulled up the documentation and saw that
they're the same thing. Something about 'map' made absolutely no sense
to me (it implies a hash-like permanent connection between the old and
the new), and collect made perfect sense (go traipsing through the
entire field of daisies, picking up only the best ones).

So if we were deprecating duplicates, I vote to get rid of #map.
(This is the part where 100 rubyists say "No! #collect sucks, #map is
king!" and my entire argument for less duplication is shot down by the
fact that people like different things.)

Well, of course both #map and #collect behave in the same way, but I'm
not sure I use both of them in the same way! That's a bit similar to
"{...}" and "do ... end" block, which are similar but used by some
people in different situations. I think, I use #map when the result is
short and very similar to the source (e.g. {|a| a+1}), and #collect if
it spans multiple lines and the calcluation is big.

Regards,

Michael
 
A

Ara.T.Howard

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


what comes to mind for me is the english meaning of continued, not finished,
open ended, incomplete, ...

-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
===============================================================================
 
G

gabriele renzi

Zach Dennis ha scritto:
How range operators work seems sort of backwards to me. It would appear
as if the "..." (three dots) would be the inclusive one, including the
last value and the ".." (two dots) would be exclusive and exclude the
last value.

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 .


Maybe you can submit an rcr about it, you'll get many positive votes, I
guess.

PS
I also think that if x...k disappear we could have an x.. literal,
(equivalent to x..-1 to express unlimited Ranges) without ambiguity.

I would love to have :
'ciao'[1..]=='iao' #=>true
instead of
'ciao'[1..-1]=='iao' #=>true
 
G

gabriele renzi

Chris Pine ha scritto:

<snipall>
I strongly agree with your view. Actually, I think when you teach
#proc to a functional programmer you just say them 'it is just to
declare a lambda', and when you teach #map to a SmalTalker you say them
"it's just like #collect ". I think it's a good way but it's just my
opinion :)
 
B

Bill Atkins

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

Bill Atkins


Zach Dennis ha scritto:
How range operators work seems sort of backwards to me. It would appear
as if the "..." (three dots) would be the inclusive one, including the
last value and the ".." (two dots) would be exclusive and exclude the
last value.

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 .

Maybe you can submit an rcr about it, you'll get many positive votes, I
guess.

PS
I also think that if x...k disappear we could have an x.. literal,
(equivalent to x..-1 to express unlimited Ranges) without ambiguity.

I would love to have :
'ciao'[1..]=='iao' #=>true
instead of
'ciao'[1..-1]=='iao' #=>true
 
B

Brian Schröder

gabriele said:
Zach Dennis ha scritto:
How range operators work seems sort of backwards to me. It would
appear as if the "..." (three dots) would be the inclusive one,
including the last value and the ".." (two dots) would be exclusive
and exclude the last value.


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 .


Maybe you can submit an rcr about it, you'll get many positive votes, I
guess.

PS
I also think that if x...k disappear we could have an x.. literal,
(equivalent to x..-1 to express unlimited Ranges) without ambiguity.

I would love to have :
'ciao'[1..]=='iao' #=>true
instead of
'ciao'[1..-1]=='iao' #=>true

That is nice, but why does it conflict with having the ... operator?
I've used ... when I translated some algorithms from pseudocode in
constructs like
for i = 0...n

I like that I don't have to write n-1. On the other hand that seems a
bit cryptic (and we don't want to end up with perl like line noise ;)

And most for constructions can be better expressed by iterators/generators.

Anyhow. Why does your proposal conflict with the ... operator?

Regards,

Brian
 
P

Peter Hickman

gabriele said:
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 .

I find the ... notation useful when the upper limit is the size of
something but the max index is one less.

This

(0...x.size).each { blah }

reads better than

(0..(x.size - 1)).each { blah }

For me at least.
 
F

Florian Frank

...it was a week later than I pulled up the documentation and saw that
they're the same thing. Something about 'map' made absolutely no sense
to me (it implies a hash-like permanent connection between the old and
the new), and collect made perfect sense (go traipsing through the
entire field of daisies, picking up only the best ones).

But this isn't what collect does. It picks up all the daisies. I think
it's called collect because it returns a collection of the same type
as the receiver in Smalltalk. The elements in this collection are the
result of evaluating the given block with each element of the original
collection as first argument. The funny thing is that collect in Ruby
always returns an array and not the same type. If Ruby would know
a default way of adding to a collection (like <<) one could define
collect like this:

module Enumerable
def collect
inject(self.class.new) { |s, x| s << yield(x); s }
end
end

Map (or mapcar) was invented in the LISP world. It maps a given
function f on each value of the (list x1 x2 ...) and returns the
resulting new (list (f x1) (f x2) ...). Ruby doesn't have a builtin
list type but uses Array instead. So it makes a lot of sense to have
map return an array. I think the idea behind Ruby's map is: If
i have the enumerable enum let's pretend it was already an array. Now
lets yield the given block to each of its values and build a new array
of the same size that consists of the return values of the block.

The ruby block does act pretty much like a function here:

You can translate from Scheme

(map (lambda (x) (+ x 1)) (list 1 2 3))

into Ruby pretty easy

[1, 2, 3].map &lambda { |x| x + 1 }

Now, you can call Non-Prefix-LISP if you like. ;)
 
Z

Zach Dennis

gabriele said:
Zach Dennis ha scritto:



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 .
I agree.
Maybe you can submit an rcr about it, you'll get many positive votes,
I guess.
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"?

PS
I also think that if x...k disappear we could have an x.. literal,
(equivalent to x..-1 to express unlimited Ranges) without ambiguity.

I would love to have :
'ciao'[1..]=='iao' #=>true
instead of
'ciao'[1..-1]=='iao' #=>true

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.

Zach
 
E

Edgardo Hames

On Sep 30, 2004, at 7:12 AM, Chris Pine wrote:

So if we were deprecating duplicates, I vote to get rid of #map.
(This is the part where 100 rubyists say "No! #collect sucks, #map is
king!" and my entire argument for less duplication is shot down by the
fact that people like different things.)

Being a Haskell programmer, I prefer map to collect. Actually, the
name "map" makes more sense to me than "collect". To many names for
the same thing can make newcomers' life a bit confusing, but after a
while you get rid of duplicates in your own mind and settle down to
the ones you like the most.

Regards,
Ed
 
B

Bill Guindon

How range operators work seems sort of backwards to me. It would appear
as if the "..." (three dots) would be the inclusive one, including the
last value and the ".." (two dots) would be exclusive and exclude the
last value.

Am I off in my own little world here or have others pondered this?
(Perhaps it has been brought up before?) I am not requesting a change on
this, I am merely pointing out what seems unnatural in a very natural
language.

Yep, at first glance I read the dots as "up to" and "up to including".
Took a bit to reverse that to "up to excluding". It wasn't intuitive
for me.

Given the choices of reversing it, losing the '...' or leaving it
alone, I'd probably go with leave it alone. I've already paid the
price of learning it, and I have used it, so might as well keep it.
 
Z

Zach Dennis

Peter said:
I find the ... notation useful when the upper limit is the size of
something but the max index is one less.

This

(0...x.size).each { blah }

reads better than

(0..(x.size - 1)).each { blah }
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

Zach
 
E

Edgardo Hames

Austin Ziegler wrote:

Still, it's the 'larger' Range.
Otherwise, good point, thx.

They are actually the same length! Nevermind, I like Cantor way too much ;)

Ed
 
Z

Zach Dennis

Bill said:
Given the choices of reversing it, losing the '...' or leaving it
alone, I'd probably go with leave it alone. I've already paid the
price of learning it, and I have used it, so might as well keep it.
I agree that for now and the recent upcoming releases we leave it alone,
but if Matz is going to work on making the language more natural and to
have it make more sense then perhaps for future versions of Ruby (2.0?)
this could be rethought. He has already made the distinction that Ruby2
will not be backwards compatible.

Zach

P.S. - I would love to hear Matz's opinion on this but I know he is
probably sleeping right now and I will have to wait untl tomorrow most
likely.
 
Z

Zach Dennis

Zach said:
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 makes more sense when reading it.
 
G

gabriele renzi

Brian Schröder ha scritto:

Anyhow. Why does your proposal conflict with the ... operator?

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

Chris Pine

 Chris Pine ha scritto:

 <snipall>
 I strongly agree with your view. Actually, I think when you teach
 #proc to a functional programmer you just say them 'it is just to
 declare a lambda', and when you teach #map to a SmalTalker you say
 them "it's just  like #collect ".  I think it's a good way but it's
 just my opinion :)

My point was that if I am teaching Ruby to a functional programmer, I don't teach them proc at all, and they already know what lambda means, so no problem. Similiarly, I wouldn't teach map to a Smalltalker.

Of course, later on, when they are fairly confident with Ruby (and no longer nubys), then I would say exactly what you said: proc is just like lambda (well, except that I guess it isn't), and map is just like collect.

To clarify, I have no problem with aliasing at all. In fact, I even kind of like it, precisely because it makes teaching *easier* (based on where a person is coming from). Of course, they have to learn it all to really learn Ruby; I'm just arguing about the order things ought to be taught in. Why confuse a fp'er with proc when they already get lambda? Move on to other things, get them hooked on Ruby, *then* mention TMTOWTDI later.

Chris
 
M

Markus

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.


It must be something pre-perl; at least, I was using this
convention (but don't recall where I picked it up) long before coming to
ruby. I know it wasn't perl because I don't know perl.

-- Markus

P.S. The notation is useful; (as others have pointed out) x...y is NOT a
synonym for x..y-1, although the effect is the same when you're dealing
with integers.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,022
Latest member
MaybelleMa

Latest Threads

Top