[#58149] [ruby-trunk - Feature #9076][Open] New one-argument block syntax: &. — "asterite (Ary Borenszweig)" <ary@...>
23 messages
2013/11/04
[#58259] [ruby-trunk - Feature #9099][Open] Train emoji lambda operator — "charliesome (Charlie Somerville)" <charliesome@...>
9 messages
2013/11/10
[#58312] [ruby-trunk - Feature #9107][Open] Introduce YES and NO as aliases of true and false — "gsamokovarov (Genadi Samokovarov)" <gsamokovarov@...>
5 messages
2013/11/13
[#58350] [ruby-trunk - Feature #9113][Open] Ship Ruby for Linux with jemalloc out-of-the-box — "sam.saffron (Sam Saffron)" <sam.saffron@...>
59 messages
2013/11/15
[#60851] Re: [ruby-trunk - Feature #9113][Open] Ship Ruby for Linux with jemalloc out-of-the-box
— Eric Wong <normalperson@...>
2014/02/19
Btw, I also hope to experiment with a slab allocator since many internal
[#62721] [ruby-trunk - Feature #9113] Ship Ruby for Linux with jemalloc out-of-the-box
— nobu@...
2014/05/24
Issue #9113 has been updated by Nobuyoshi Nakada.
[#62735] [ruby-trunk - Feature #9113] Ship Ruby for Linux with jemalloc out-of-the-box
— normalperson@...
2014/05/25
Issue #9113 has been updated by Eric Wong.
[#58391] [ruby-trunk - Bug #9119][Assigned] TestTime#test_marshal_broken_offset broken under MinGW — "luislavena (Luis Lavena)" <luislavena@...>
10 messages
2013/11/17
[#58396] [ruby-trunk - Bug #9121][Open] [PATCH] Remove rbtree implementation of SortedSet due to performance regression — "xshay (Xavier Shay)" <contact@...>
15 messages
2013/11/18
[#58404] [ruby-trunk - Feature #9123][Open] Make Numeric#nonzero? behavior consistent with Numeric#zero? — "sferik (Erik Michaels-Ober)" <sferik@...>
40 messages
2013/11/18
[#58411] [ruby-trunk - Bug #9124][Open] TestSocket errors in test-all on Arch 64-bit — "jonforums (Jon Forums)" <redmine@...>
14 messages
2013/11/18
[#58515] [ruby-trunk - Bug #9124] TestSocket errors in test-all on Arch 64-bit
— "jonforums (Jon Forums)" <redmine@...>
2013/11/23
[#58841] [ruby-trunk - Bug #9124] TestSocket errors in test-all on Arch 64-bit
— "jonforums (Jon Forums)" <redmine@...>
2013/12/04
[#58842] Re: [ruby-trunk - Bug #9124] TestSocket errors in test-all on Arch 64-bit
— Eric Wong <normalperson@...>
2013/12/04
"jonforums (Jon Forums)" <redmine@ruby-lang.org> wrote:
[#58452] [ruby-trunk - Bug #9133][Open] logger rotates log files more than expected — "no6v (Nobuhiro IMAI)" <nov@...>
8 messages
2013/11/21
[#58473] Object identity for string hash keys — Andrew Vit <andrew@...>
I'm not sure if this is a bug. I'm creating a hash like this:
5 messages
2013/11/21
[#58490] Re: [ruby-cvs:50910] drbrain:r43767 (trunk): * lib/rubygems: Update to RubyGems master 50a8210. Important changes — Tanaka Akira <akr@...>
2013/11/22 <drbrain@ruby-lang.org>:
4 messages
2013/11/22
[#58492] Re: [ruby-cvs:50910] drbrain:r43767 (trunk): * lib/rubygems: Update to RubyGems master 50a8210. Important changes
— Eric Wong <normalperson@...>
2013/11/22
Tanaka Akira <akr@fsij.org> wrote:
[#58496] [ruby-trunk - Feature #9140][Open] Allow each_with_index to get start index — "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>
8 messages
2013/11/22
[#58545] [ruby-trunk - Feature #9145][Open] Queue#pop(true) return nil if empty instead of raising ThreadError — "jsc (Justin Collins)" <redmine@...>
9 messages
2013/11/24
[#58599] [ruby-trunk - Bug #9159][Open] [patch] use rb_fstring for internal strings — "tmm1 (Aman Gupta)" <ruby@...1.net>
5 messages
2013/11/26
[#58653] [ruby-trunk - Bug #9170][Open] Math.sqrt returns different types when mathn is included; breaks various gems - this bug can be reproduced in Ruby 1.8 as well — "kranzky (Jason Hutchens)" <JasonHutchens@...>
7 messages
2013/11/28
[#58719] [ruby-trunk - Feature #5446] at_fork callback API — "tmm1 (Aman Gupta)" <ruby@...1.net>
6 messages
2013/11/30
[ruby-core:58171] Re: [ruby-trunk - Feature #9049] Shorthands (a:b, *) for inclusive indexing
From:
"Martin J. Dürst" <duerst@...>
Date:
2013-11-05 09:11:34 UTC
List:
ruby-core #58171
[Sorry for the delay of this message. I wrote most of this mail on a
plane, but had to check a few loose ends, and forgot about that when off
the plane.]
I'm not at all convinced that we need to add ':' to '..' for ranges (or,
to say it more clearly, I'm against changing/adding it). In Ruby, ranges
use '..', and exponentiation uses '**', and so on. Other languages may
use different conventions. That's just it, there's no need to fix it.
For more details, please see below.
On 2013/10/25 2:29, David MacMahon wrote:
>
> On Oct 23, 2013, at 11:39 PM, Fuad Saud wrote:
>
>> How is a:b better than a..b? two dots are straightforward, unambiguous, well known.
>
> The tongue-in-cheek answer is that it's better because it's one character shorter. :-) The real answer is somewhat more subtle and perhaps subjective. Here are a few reasons.
>
> 1) The a:b form is more compact that a..b
&& is also used more than &, and is less compact, and 'and', which is
mostly used these days, is even less compact.
> and the vertical dots of the ':' character stand out better (visually) than two horizontal dots when reading code:
>
> Proposed: foo[bar.x0:bar.x1, bar.y0:bar.y1, bar.z0:bar.z1]
>
> Current: foo[bar.x0..bar.x1, bar.y0..bar.y1, bar.z0..bar.z1]
Yes. But if we are at aesthetics and the like, the '..' is actually the
better expression of a range than ':', at least if you ask me. And you
can write the above as:
foo[bar.x0 .. bar.x1, bar.y0 .. bar.y1, bar.z0 .. bar.z1]
Or add spaces or parentheses to your liking to make it clearer and
easier to read. That's what's done all the time to make the structure of
an expression easier to grasp.
> 2) The first:last form opens up the possibility of a first:step:last syntax for Ranges that have a step size other than 1.
There are many other ways to get there. It should be fairly easy e.g. to
make first..step..last behave that way, 1..2..7 currently produces a
syntax error, but that could be changed.
(also please note that Python uses first:last:step)
> 3) It would make transliteration to Ruby of existing Matlab/OctavePython code easier.
Not really. I worked with some of my students on a project to
support/automate conversion from Python to Ruby. Some of it was easy,
some of it was tedious but straightforward, and some of it is
essentially hopeless. Converting ":" to "..", even if only in certain
circumstances, falls into the easy bucket.
The hopeless stuff includes semantic differences, in particular what
different languages take as truthy and falsy. Every
if expression:
in Python has to be rewritten as
if python_true?(expression)
in Ruby, because otherwise the program will do the wrong thing if
expression evaluates to an empty array or string or 0 or so.
> 4) It is more intuitive for new Ruby programmers who come from a Matlab/Octave/Python background. I'm not sure how much weight this reason carries (maybe negative? :-))
Not negative, and probably even positive, but way not enough to actually
implement it. Different programming languages have (more or less)
different ways of writing operators, but there are many more important
differences that people have to get used to anyway.
> 5) Even if it's not deemed to be "better", it does provide another convenient way to make a Range. What's wrong with that?
Ranges with steps sound interesting (not personally for me but in
general), but that's a separate issue from the actual syntax, and in
particular from the :/.. discussion. I actually think we should close
the current issue and open a separate issue for ranges with steps.
Other than that, yes there are for example a lot of ways to make a
String, but each of them is there for a reason (even if in some cases it
may be only because it was adopted from Perl and not kicked out yet).
Regards, Martin.