[#39810] 2.0 feature questionnaire — SASADA Koichi <ko1@...>

I made a questionnaire "What do you want to introduce in 2.0?" in my

59 messages 2011/10/01
[#39822] Re: 2.0 feature questionnaire — Jeremy Kemper <jeremy@...> 2011/10/02

2011/10/1 SASADA Koichi <ko1@atdot.net>:

[#39827] Re: 2.0 feature questionnaire — Yukihiro Matsumoto <matz@...> 2011/10/02

Hi,

[#40324] Re: 2.0 feature questionnaire — Charles Oliver Nutter <headius@...> 2011/10/25

2011/10/1 SASADA Koichi <ko1@atdot.net>:

[#39823] Discussion results — SASADA Koichi <ko1@...>

Hi,

34 messages 2011/10/02
[#39840] Re: Discussion results — Intransition <transfire@...> 2011/10/02

I did not have the fortune of attending the discussion, but I would

[#39844] Re: Discussion results — Yukihiro Matsumoto <matz@...> 2011/10/02

Hi,

[#39851] Re: Discussion results (here documents with indents) — "Martin J. Dürst" <duerst@...> 2011/10/03

Hello Matz,

[#39862] Re: Discussion results (here documents with indents) — Yusuke Endoh <mame@...> 2011/10/03

Hello,

[#39874] Re: Discussion results (here documents with indents) — Trans <transfire@...> 2011/10/03

On Mon, Oct 3, 2011 at 8:16 AM, Yusuke Endoh <mame@tsg.ne.jp> wrote:

[#39915] [Ruby 1.9 - Feature #5400][Open] Remove flip-flops in 2.0 — Magnus Holm <judofyr@...>

29 messages 2011/10/04

[#39957] [Ruby 1.9 - Bug #5407][Open] Cannot build ruby-1.9.3-rc1 with TDM-GCC 4.6.1 on Windows XP SP3 — Heesob Park <phasis@...>

11 messages 2011/10/05

[#39993] [Ruby 1.9 - Feature #2348] RBTree Should be Added to the Standard Library — David Graham <david.malcom.graham@...>

10 messages 2011/10/06

[#40037] [Ruby 1.9 - Bug #5422][Open] File.fnmatch != Dir.glob # {no,sets} — Suraj Kurapati <sunaku@...>

14 messages 2011/10/07

[#40073] [Ruby 1.9 - Feature #5427][Open] Not complex patch to improve `require` time (load.c) — Yura Sokolov <funny.falcon@...>

31 messages 2011/10/09

[#40090] [Ruby 1.9 - Bug #5433][Open] PTY.spawn Kernel panic on macos lion — Gamaliel Toro <argami@...>

14 messages 2011/10/10

[#40188] [Ruby 2.0 - Feature #5454] keyword arguments — Yukihiro Matsumoto <matz@...>

16 messages 2011/10/17
[#40189] Re: [Ruby 2.0 - Feature #5454] keyword arguments — Evan Phoenix <evan@...> 2011/10/17

This looks very interesting! Would someone be willing to translate to english? I've only got a vague idea of what is being discussed.

[#40191] Re: [Ruby 2.0 - Feature #5454] keyword arguments — Yutaka Hara <yutaka.hara@...> 2011/10/18

Hi,

[#40192] Re: [Ruby 2.0 - Feature #5454] keyword arguments — Yukihiro Matsumoto <matz@...> 2011/10/18

Hi,

[#40259] Counseling — Perry Smith <pedzsan@...>

Ruby and I are back in counseling... Its always the same thing with her. "I'm throwing an Encoding exception!!!"

21 messages 2011/10/21
[#40263] Re: Counseling — "Haase, Konstantin" <Konstantin.Haase@...> 2011/10/21

What's your $LC_CTYPE? What OS are you on?

[#40264] Re: Counseling — Gon軋lo Silva <goncalossilva@...> 2011/10/21

Hi all,

[#40266] Re: Counseling — Bill Kelly <billk@...> 2011/10/21

Gon軋lo Silva wrote:

[#40267] Re: Counseling — Perry Smith <pedzsan@...> 2011/10/22

[#40268] Re: Counseling — Eric Hodel <drbrain@...7.net> 2011/10/22

On Oct 21, 2011, at 9:43 AM, Perry Smith wrote:

[#40269] Re: Counseling — Joshua Ballanco <jballanc@...> 2011/10/22

To try and cut to the core of the issue: in Ruby 1.8 it was common practice to use the String class to represent both "proper strings" as well as a "bag-o-bytes". In Ruby 1.9, you can only properly use the String class to represent "proper strings". For a "bag-o-bytes" we're left with Array, but there are times when Array is not the right abstraction (e.g. reading data from a socket, identifying a start and stop token, and writing the bytes between to a file on disk). Also, the "BINARY" encoding is not the right abstraction, because you still have an object which will worry about encodings and, due to Ruby always trying to do "the right thing", bugs can be very difficult to track down. Consider:

[#40271] Can rubygems save us from "binary-compatibility hell"? — Yusuke Endoh <mame@...>

Hello, rubygems developers --

17 messages 2011/10/22

[#40290] [ruby-trunk - Feature #5474][Assigned] keyword argument — Yusuke Endoh <mame@...>

36 messages 2011/10/23
[#40414] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Charles Oliver Nutter <headius@...> 2011/10/26

More refinement below. I think we're on a good path here.

[#40416] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Yukihiro Matsumoto <matz@...> 2011/10/26

Hi,

[#40418] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Joshua Ballanco <jballanc@...> 2011/10/26

On Wed, Oct 26, 2011 at 2:08 PM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:

[#40425] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Yukihiro Matsumoto <matz@...> 2011/10/27

Hi,

[#40298] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Yukihiro Matsumoto <matz@...> 2011/10/24

Hi,

[#40311] [ruby-trunk - Feature #5478][Open] import Set into core, add syntax — Konstantin Haase <Konstantin.Haase@...>

33 messages 2011/10/24

[#40312] [ruby-trunk - Feature #5479][Open] import StringIO into core, add String#to_io — Konstantin Haase <Konstantin.Haase@...>

9 messages 2011/10/24
[#40350] [ruby-trunk - Feature #5479] import StringIO into core, add String#to_io — Charles Nutter <headius@...> 2011/10/25

[#40316] [ruby-trunk - Feature #5481][Open] Gemifying Ruby standard library — Hiroshi Nakamura <nakahiro@...>

86 messages 2011/10/24
[#40334] [ruby-trunk - Feature #5481] Gemifying Ruby standard library — Lucas Nussbaum <lucas@...> 2011/10/25

[#40322] [ruby-trunk - Feature #5482][Open] Rubinius as basis for Ruby 2.0 — Thomas Sawyer <transfire@...>

19 messages 2011/10/25

[#40356] JIT development for MRI — Carter Cheng <cartercheng@...>

Hello,

25 messages 2011/10/25
[#40390] Re: JIT development for MRI — SASADA Koichi <ko1@...> 2011/10/26

Hi,

[#40394] Re: JIT development for MRI — Carter Cheng <cartercheng@...> 2011/10/26

Dear Koichi SASADA,

[#40395] Re: JIT development for MRI — Carter Cheng <cartercheng@...> 2011/10/26

I noticed that you used context threading in YARV. Do you have some analysis

[#40417] Re: JIT development for MRI — SASADA Koichi <ko1@...> 2011/10/26

Thanks for reference.

[#40423] Re: JIT development for MRI — Carter Cheng <cartercheng@...> 2011/10/26

Thanks Koichi.

[#40412] [ruby-trunk - Bug #5486][Open] rb_stat() doesn’t respect input encoding — Nikolai Weibull <now@...>

15 messages 2011/10/26

[#40462] [ruby-trunk - Bug #5492][Open] MinGW Installation with Ruby 1.9.3rc1 Broken — Charlie Savage <cfis@...>

14 messages 2011/10/27

[#40573] [ruby-trunk - Bug #5530][Open] SEEK_SET malfunctions when used with 'append' File.open mode — "Joshua J. Drake" <ruby-lang.jdrake@...>

17 messages 2011/10/31

[#40586] [ruby-trunk - Feature #5531][Open] deep_value for dealing with nested hashes — Kyle Peyton <kylepeyton@...>

19 messages 2011/10/31

[ruby-core:40518] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument

From: Benoit Daloze <eregontp@...>
Date: 2011-10-29 23:08:46 UTC
List: ruby-core #40518
Hi,
On 23 October 2011 14:53, Yusuke Endoh <mame@tsg.ne.jp> wrote:
>
> Issue #5474 has been reported by Yusuke Endoh.
>
> ----------------------------------------
> Feature #5474: keyword argument
> http://redmine.ruby-lang.org/issues/5474
>
> Author: Yusuke Endoh
> Status: Assigned
> Priority: Normal
> Assignee: Koichi Sasada
> Category: core
> Target version:
>
>
> Hello,
>
> I'm sending a patch for keyword arguments.
>
> (This feature had been discussed in #5454, but I'm re-creating
>  new ticket because the old ticket was resigtered in ruby-dev)
>
>
> Matz himself proposed this feature. t is also basically
> promised to include the feature in 2.0. ruby-core:39837]
> I'm planning to commit the patch after it is reviewed by koichi.
>
> But the detail of the spec is not fixed yet, and may be changed
> drastically.
> We would like to hear your comments and suggestions, especially,
> with a use case and/or an actual experience.
>
>
>
> The background of this proposal is that, in the recent Ruby,
> the last argument (as a Hash) is often used to pass optional
> information. his feature is intended to aid the style.
>
> Look an example:
>
> ef create_point(x, y, color: "white", size: 1)
>  keyword arguments ^^^^^^^^^^^^^^^^^^^^^^ here!
>
>  [x, y, color, size]
> nd
>
> reate_point(2, 3, color: "red")
> => [2, 3, "red", 1]
>
> The caller size is a traditional hash argument notation.
> This feature is Hash parsing in the callee side.
>
> (So it is more suitable to call it "keyword parameter."
> ut I use "keyword argument" because everyone calls so.)
>
>
> We can implement the similar behavior in pure Ruby. owever,
> this feature is easier to read/write, and richer in the some
> aspects:
>
> - it raises an TypeError when unknown keyword is given
>
> reate_point(2, 3, style: "solid")
> => unknown keyword (TypeError)
>
> - you can use ** argument to suppress the TypeError and/or
> o get the given hash itself:
>
> ef create_point(x, y, color: "white", size: 1, **h)
>  [x, y, color, size, h]
> nd
> reate_point(2, 3, style: "solid")
> => [2, 3, "red", 1, {:style=>"solid"}]
>
> - it is easily used even when there is a rest argument
>
> ef create_point(x, y, *r, color: "solid", size: 1)
> ..
> nd
>
> a complex and non-essential code is required to
> implement the same behavior in pure Ruby)
>
> - there is room for optimizing the speed (though I have
> ot done any optimization yet)
>
>
>
> An alternative design is to treat all parameters as keyword
> arguments (as Evan said in [ruby-core:40195]).
>
> ef create_point(x, y, color = "white", size = 1)
>  [x, y, color, size]
> nd
> reate_point(color: "red", x: 2, y: 3)
> => [2, 3, "red", 1]
>
> Actually I also like this, but I'm afraid if it is too flexible
> and seems difficult to implement and optimize.
>
>
> Thanks,
>
> --
> Yusuke Endoh <mame@tsg.ne.jp>
>
>
> --
> http://redmine.ruby-lang.org
>
>

It sounds great!

I agree mandatory keyword arguments should be positional arguments and
  all parameters should not be treated as keyword arguments.

I have a few questions/remarks:
1) What is the way to pass keyword arguments ?
I would guess `**h` like:

def meth(a, **h)
  other(a, **h)
end # => syntax error

BTW, using **h in the argument list does not seems to work in some cases for me:

def a(**h)
end # => syntax error, unexpected tPOW

def m(k: nil, **h, &block)
end
m() # => undefined method `key?' for nil:NilClass

2) I'm a bit dubious about the `**h` syntax to get (and I guess to
pass) a Hash though.
I know it's the way it's done in Python, but I don't like it
(esthetically), especially when it is used to pass the Hash:

def meth(a, *r, **h)
  other(a, *r, **h)
end

I believe `*args` is appropriate for the rest argument, because the
star is the splat operator.
I cannot think of any clear logic like that for `**h` except "another
rest argument".
Also `**` is the power operator, which is unrelated.
Something related to `{}`, the literal Hash syntax, would fit better
in my opinion.

Do you have any idea of an alternate syntax to `**h` ?

(Or maybe we should introduce `a, b = **h` as a joke for `a, b =
h.values_at(:a, :b)`)

3) What would {Proc,Method,UnboundMethod}#parameters returns for
keywords arguments ?

def meth(mandatory, optional = nil, *rest, post, keyw: nil, **h, &block)
end
p method(:meth).parameters
Currently: [[:req, :mandatory], [:opt, :optional], [:rest, :rest],
[:req, :post], [:block, :block]]
Something like:
[[:req, :mandatory], [:opt, :optional], [:rest, :rest], [:req, :post],
[:key, :keyw], [:keyrest, :h], [:block, :block]] ?

4)  I noticed a few problems while experimenting:
def a(k: :a, **h)
  p [k,h]
end
a(:b, c: :d, e: :f) # => wrong number of arguments (2 for 0) (ArgumentError)
It should be "1 for 0"

def a(k: :a)
  p [k,h]
end
a(r: :a) # => unknown keyword (TypeError)
It should say which keyword is missing (and an ArgumentError rather
than TypeError, no?).

(Of course I do not expect the current patch to pass these details, I
just mention them to be sure they will be considered.)

In This Thread