[#24648] [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Run Paint Run Run <redmine@...>

Bug #1852: Enumerable's #hash Raises ArgumentError When Recursive Values are Present

20 messages 2009/08/01
[#24649] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Tanaka Akira <akr@...> 2009/08/01

In article <4a73e51b5a4f9_138119f2a982704e@redmine.ruby-lang.org>,

[#24652] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Run Paint Run Run <runrun@...> 2009/08/01

> Is it valuable to implement such function?

[#24682] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Tanaka Akira <akr@...> 2009/08/02

In article <67e307490908010125r6fa76654pa8e2224f714588fc@mail.gmail.com>,

[#24673] [Feature #1857] install *.h and *.inc — Roger Pack <redmine@...>

Feature #1857: install *.h and *.inc

21 messages 2009/08/01

[#24732] [Bug #1873] MatchData#[]: Omits All But Last Captures Corresponding to the Same Named Group — Run Paint Run Run <redmine@...>

Bug #1873: MatchData#[]: Omits All But Last Captures Corresponding to the Same Named Group

12 messages 2009/08/03

[#24775] [Feature #1889] Teach Onigurma Unicode 5.0 Character Properties — Run Paint Run Run <redmine@...>

Feature #1889: Teach Onigurma Unicode 5.0 Character Properties

30 messages 2009/08/05

[#24786] [Bug #1893] Recursive Enumerable#join is surprising — Jeremy Kemper <redmine@...>

Bug #1893: Recursive Enumerable#join is surprising

24 messages 2009/08/06
[#28422] [Bug #1893] Recursive Enumerable#join is surprising — Yusuke Endoh <redmine@...> 2010/03/02

Issue #1893 has been updated by Yusuke Endoh.

[#28438] Re: [Bug #1893] Recursive Enumerable#join is surprising — Yukihiro Matsumoto <matz@...> 2010/03/03

Hi,

[#24854] embedding ruby 1.9 frustration — Rolando Abarca <funkaster@...>

Hello,

12 messages 2009/08/10

[#24982] [Feature #1961] Kernel#__dir__ — Yutaka HARA <redmine@...>

Feature #1961: Kernel#__dir__

26 messages 2009/08/19
[#28898] [Feature #1961] Kernel#__dir__ — Roger Pack <redmine@...> 2010/03/23

Issue #1961 has been updated by Roger Pack.

[#28900] Re: [Feature #1961] Kernel#__dir__ — Kornelius Kalnbach <murphy@...> 2010/03/23

On 23.03.10 19:10, Roger Pack wrote:

[#25025] [Backport #1975] Backport Dir.mktmpdir — Kirk Haines <redmine@...>

Backport #1975: Backport Dir.mktmpdir

12 messages 2009/08/21

[#25041] Proposal: Simpler block format — Yehuda Katz <wycats@...>

I'd like to propose that we add the following syntax for procs in Ruby:

45 messages 2009/08/23
[#25046] Re: Proposal: Simpler block format — Caleb Clausen <caleb@...> 2009/08/23

Yehuda Katz wrote:

[#25049] Re: Proposal: Simpler block format — Yehuda Katz <wycats@...> 2009/08/23

On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen <caleb@inforadical.net>wrote:

[#25058] Re: Proposal: Simpler block format — Yukihiro Matsumoto <matz@...> 2009/08/23

Hi,

[#25059] Re: Proposal: Simpler block format — Yehuda Katz <wycats@...> 2009/08/23

On Sun, Aug 23, 2009 at 3:33 PM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:

[#25063] Re: Proposal: Simpler block format — "David A. Black" <dblack@...> 2009/08/23

Hi --

[#25068] Re: Proposal: Simpler block format — brian ford <brixen@...> 2009/08/24

Hi,

[#25086] [Bug #1991] ruby should use twolevel namespace on OS X — Michal Suchanek <redmine@...>

Bug #1991: ruby should use twolevel namespace on OS X

12 messages 2009/08/24

[#25208] Module#prepend and Array#prepend — Yehuda Katz <wycats@...>

Matz,

23 messages 2009/08/30

[#25210] [Feature #2022] Patch for ruby-1.8.6 and openssl-1.0 — Jeroen van Meeuwen <redmine@...>

Feature #2022: Patch for ruby-1.8.6 and openssl-1.0

15 messages 2009/08/30

[#25220] [Bug #2026] String encodings are not supported by most of IO on Linux — Vit Ondruch <redmine@...>

Bug #2026: String encodings are not supported by most of IO on Linux

18 messages 2009/08/31

[ruby-core:25078] Re: Proposal: Simpler block format

From: Yehuda Katz <wycats@...>
Date: 2009-08-24 05:48:26 UTC
List: ruby-core #25078
Essentially, we currently have two semantic constructs: method-style and
block-style. I am suggesting that we take the literals of each style and use
them as literals whenever those semantics are expected.
    my_method { block_semantics }

In this case, { block } is the literal for block-semantics. I am suggesting
that we extend the use of this literal to the other case where
block-semantics are used: Procs.

    my_method({ still_block_semantics })

Similarly:

    def method_name() method_semantics end

In this case, def is the literal for method-semantics. I am suggesting that
we extend the use of this literal to the other case where method-semantics
are used: Lambdas.

    name = def { still_method_semantics }

As you can see, by using the same literals for equivalent constructs, we
simplify the problem in the mind of the programmer. When he sees "def" he
knows that method semantics are to be used, and required arguments are
required, return will return from the block, and yield will yield to the
block. When he sees bare {} he knows that block semantics are used, all
arguments are optional, return will return from enclosing "def", and yield
will yield to block passed into enclosing "def".

This will always be true, no matter if lambda is being used, proc is being
used, method is being used, or block is being used.

-- Yehuda

On Sun, Aug 23, 2009 at 9:36 PM, Evan Phoenix <evan@fallingsnow.net> wrote:

> Hi everyone,
>
> I know that one of the original reasons for having -> was because it
> allowed for default arguments. Since that has since been fixed for || args,
> what about simply moving where the arguments for -> are?
>
> Rather than:
>
> ->(a,b) { a + b }
>
> you have:
>
> ->{ |a,b| a + b }
>
> I find that quite a bit easier to read, and it's syntax everyone is used
> to. In addition, it removes the case that I find incredibly hard to read:
>
> -> a, b { a + b }
>
> For defaults, from:
>
> -> a = 1 { a + 3 }
>
> to:
>
> ->{ |a=1| a + 3 }
>
> Seems like it would be fine to allow space between -> and { as it is now as
> well:
>
> -> { |a,b| a + b }
>
> I think of this as sort of a middle ground between the current ->
> implementation and the bare {} implementation. It unifies the idea of a
> separate identifier with syntax that all ruby programmers are accustom to
> today.
>
>  - Evan
>
>
>
> On Aug 23, 2009, at 9:21 PM, Yukihiro Matsumoto wrote:
>
>  Hi,
>>
>> In message "Re: [ruby-core:25068] Re: Proposal: Simpler block format"
>>   on Mon, 24 Aug 2009 13:03:53 +0900, brian ford <brixen@gmail.com>
>> writes:
>>
>> |Could we add def {} and see by usage which prevails? Or take a
>> |world-wide vote (perhaps weighted by number of lines of Ruby code
>> |written by the voter)?
>>
>> The def keyword is to define a method.  I assume your def {} proposal
>> is to declare an anonymous procedure object, which is NOT a method at
>> all.  For me, the difference is big enough to reject the proposal.
>>
>>                                                        matz.
>>
>>
>>
>
>


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

In This Thread