[#35599] Proc#== behaviour on 1.8.7 and 1.9.2 — Adam Prescott <adam@...>
I've encountered a problem when using Proc#== (with both lambdas and
[#35613] [Ruby 1.9 - Feature #4539][Assigned] Array#zip_with — Yui NARUSE <redmine@...>
> http://redmine.ruby-lang.org/issues/4539
Hi,
[#35618] Redmine issues — Benoit Daloze <eregontp@...>
Hello,
[#35621] [Ruby 1.9 - Bug #4555][Open] [PATCH] ext/socket/init.c: rsock_connect retries on interrupt — Eric Wong <normalperson@...>
[#35629] [Ruby 1.9 - Bug #4473] Calling return within begin still executes else — Mayank Kohaley <redmine@...>
[#35631] [Ruby 1.9 - Bug #4558][Open] TestSocket#test_closed_read fails after r31230 — Tomoyuki Chikanaga <redmine@...>
> ----------------------------------------
KOSAKI Motohiro <[email protected]> wrote:
Tomoyuki Chikanaga <[email protected]> wrote:
> Issue #4558 has been updated by Eric Wong.
KOSAKI Motohiro <[email protected]> wrote:
[#35632] [Ruby 1.9 - Bug #4559][Open] Proc#== does not match the documented behaviour — Adam Prescott <redmine@...>
(2012/11/28 16:10), matz (Yukihiro Matsumoto) wrote:
I believe this will be a spec change, albeit a small one. Can we
[#35636] [Ruby 1.9 - Feature #4560][Open] [PATCH] lib/net/protocol.rb: avoid exceptions in rbuf_fill — Eric Wong <redmine@...>
[#35637] [Ruby 1.9 - Bug #4561][Open] 1.9.2 requires parentheses around argument of method call in an array, where 1.8.7 did not — Dave Schweisguth <redmine@...>
[#35644] [Ruby 1.8 - Bug #4563][Open] Dir#tell broken — Daniel Berger <redmine@...>
[#35648] mvm branch status? — Eric Wong <normalperson@...>
Hello, I noticed the "mvm" branch in SVN hasn't been updated in over a year.
Hi Eric.
Has there been any thought on solving the C extension problem in MVM? In the present state, I've stopped working on it in Rubinius because there is no workable solution if there are C extensions in the mix.
Evan Phoenix <[email protected]> wrote:
On Thu, Apr 7, 2011 at 6:18 PM, Eric Wong <[email protected]> wrote:
[#35666] caching of the ancestor chain — Xavier Noria <fxn@...>
Why does Ruby cache the ancestors chain? I mean, not why the implementation i=
Ah, in case it is not clear, where I find the metaphor broken is in that you=
Hi,
On Fri, Apr 8, 2011 at 7:56 PM, Yukihiro Matsumoto <[email protected]> wro=
[#35678] [Ruby 1.9 - Bug #4564][Open] mingw-w64, truncate, ftruncate and ftello -- properly evalute it's existence — Luis Lavena <redmine@...>
[#35699] [Ruby 1.9 - Feature #4568][Open] [PATCH] file.c (rb_group_member): kill 256K of stack usage — redmine@...
[#35707] [Ruby 1.9 - Feature #4569][Open] Replace IPAddr with IPAddress — redmine@...
[#35713] [Ruby 1.9 - Bug #4571][Open] YAML.load given an ISO8601 timestamp creates an incorrect value for usec — redmine@...
[#35734] [Ruby 1.9 - Feature #4574][Open] Numeric#within — redmine@...
[#35753] [Ruby 1.9 - Bug #4576][Open] Range#step miss the last value, if end-exclusive and has float number — redmine@...
Can somebody please reopen this issue? Since the test suite fix is
2011/9/16 Marc-Andre Lafortune <[email protected]>:
On 16 September 2011 15:49, Tanaka Akira <[email protected]> wrote:
Hi,
2011/9/16 Kenta Murata <[email protected]>:
2011/9/17 Marc-Andre Lafortune <[email protected]>:
2011/9/17 Tanaka Akira <[email protected]>:
(2011/09/17 9:07), Tanaka Akira wrote:
I have not been watching ruby-core, but let me give a comment for this issu=
2011/9/17 Masahiro TANAKA <[email protected]>:
2011/9/20 Tanaka Akira <[email protected]>:
I haven't explained the reason of the error estimation in
On 21 September 2011 14:25, masa <[email protected]> wrote:
[#35754] [Ruby 1.9 - Bug #4577][Open] (int...float).max should not raise an error — redmine@...
[#35759] [Ruby 1.8 - Bug #4578][Open] Fixnum.freeze not frozen? — redmine@...
[#35765] [Ruby 1.9 - Bug #4579][Open] SecureRandom + OpenSSL may repeat with fork — redmine@...
[#35777] hashes are not consistent across ruby processes? — Roger Pack <rogerdpack2@...>
Hello all.
[#35813] [Ruby 1.9 - Bug #4320] Bus Error in digest/sha2 on sparc — redmine@...
[#35814] [Ruby 1.9 - Bug #4320] Bus Error in digest/sha2 on sparc — redmine@...
[#35825] [Ruby 1.8 - Bug #4587][Open] RMATCH_REGS definition is wrong — redmine@...
[#35828] [Ruby 1.9 - Feature #4589][Open] add Queue#each() method and include Enumerable — redmine@...
[#35830] [Ruby 1.9 - Feature #3436] Spawn the timer thread lazily — redmine@...
[#35850] [Ruby 1.9 - Feature #4189] FileUtils#ln_r — Sakuro OZAWA <redmine@...>
[#35866] [Ruby 1.9 - Bug #4603][Open] lib/csv.rb: when the :encoding parameter is not provided, the encoding of CSV data is treated as ASCII-8BIT — yu nobuoka <nobuoka@...>
On Sun, Apr 24, 2011 at 1:33 AM, yu nobuoka <[email protected]>wrote:
2011/4/25 James Gray <[email protected]>:
On Sun, Apr 24, 2011 at 11:29 PM, NARUSE, Yui <[email protected]> wrote:
[#35879] [Ruby 1.9 - Bug #4610][Open] Proc#curry behavior is inconsistent with lambdas containing default argument values — Joshua Ballanco <jballanc@...>
[#35883] [Ruby 1.9 - Bug #4611][Open] [BUG] Segementation fault reported — Deryl Doucette <me@...>
[#35895] [Ruby 1.9 - Feature #4614][Open] [RFC/PATCH] thread_pthread.c: lower RUBY_STACK_MIN_LIMIT to 64K — Eric Wong <normalperson@...>
[#35923] [Ruby 1.9 - Feature #4621][Open] NilClass#to_hash — Tsuyoshi Sawada <sawadatsuyoshi@...>
[#35933] [Ruby 1.9 - Bug #4623][Open] Consistent crash related to action_mailer — Alex Neth <alex@...>
[#35943] [Ruby 1.9 - Feature #3905] rb_clear_cache_by_class() called often during GC for non-blocking I/O — Motohiro KOSAKI <kosaki.motohiro@...>
[ruby-core:35914] Re: [Ruby 1.9 - Feature #4610] Proc#curry behavior is inconsistent with lambdas containing default argument values
On Tue, Apr 26, 2011 at 7:57 AM, Yusuke ENDOH <[email protected]> wrote: > Hello, > > 2011/4/26 Joshua Ballanco <[email protected]>: > > Regarding the consistency argument, as I understand Currying (or at least > the way that it is implemented in most other languages), the result of a > Proc#curry call should be a chain of Proc's with arity 1 that return Proc's > with arity 1 until all arguments have been satisfied. It would be nice if > Ruby behaved similarly. > > How should Ruby handle *rest parameter? > > proc {|x, y, z, *rest| }.curry.(1).(2).(3).(4).(5)... ? I agree rest is a complication, but terminal rest seems to be ok. I would argue that, in the case you provide, the final proc yielded could have arity -1. proc {|x, y, z, *rest| puts "#{x}, #{y}, #{z}, #{rest.join(',')}" }.curry.(1).(2).(3).(4) # => "1, 2, 3, 4" proc {|x, y, z, *rest| puts "#{x}, #{y}, #{z}, #{rest.join(',')}" }.curry.(1).(2).(3).(4, 5) # => "1, 2, 3, 4, 5" proc {|x, y, z, *rest| puts "#{x}, #{y}, #{z}, #{rest.join(',')}" }.curry.(1).(2).(3).(4).(5) # => "1, 2, 3, 4" # => NoMethodError: undefined method `call' for nil:NilClass The real problem is interstitial rest argument, but even here I would argue that at the point where the rest argument is encountered, the proc should have arity -1 (and keeping arity strictness between lambda and proc): proc {|x, y, *rest, z| puts "#{x}, #{y}, #{z}, #{rest.join(',')}" }.curry.(1).(2).(3).(4) # => "1, 2, 4, 3" lambda {|x, y, *rest, z| puts "#{x}, #{y}, #{z}, #{rest.join(',')}" }.curry.(1).(2).(3).(4, 5) # => ArgumentError: wrong number of arguments (2 for 1) proc {|x, y, *rest, z| puts "#{x}, #{y}, #{z}, #{rest.join(',')}" }.curry.(1).(2).(3).(4, 5) # => "1, 2, 4, 3" Essentially, if you keep to the notion of currying pulling argument lists apart and creating new methods for each argument, I think this is still doable in Ruby. > For example, in OCaml (which auto-curries functions): > > If you quote OCaml, you should note that Ocaml also provides > optional arguments. > Actually, OCaml handles optional arguments as Ruby does. > IOW, OCaml function also fires as soon as all the required > arguments are given: > > > # let foo ?(a="ichi") ?(b="ni") ?(c="san") () = > print_endline (S(String.concat ", " [a; b; c]);; > val foo : ?a:string -> ?b:string -> ?c:string -> unit -> unit = <fun> > # foo ();; > ichi, ni, san > - : unit = () > # foo ~a:"first" ();; > first, ni, san > - : unit = () > # foo ~a:"first" ~b:"second" ();; > first, second, san > - : unit = () > # foo ~a:"first" ~b:"second" ~c:"third" ();; > first, second, third > - : unit = () > > > There are some differences between OCaml and Ruby: > > - OCaml function requires at least one mandatory argument. > (In this case, () is the only mandatory argument.) > > - Optional arguments always requires labels (= keywords). > > > I believe your concern (and #4601) will be solved by keyword > arguments. > > def foo(a:"ichi", b:"ni", c:"san") > puts "#{ a }, #{ b }, #{ c }" > end > > foo(b:"second") #=> ichi, second, san > > method(:foo).curry. > pass_option(a: "first"). > pass_option(b: "second"). > pass_option(c: "third"). > call() #=> first, second, third > > Unfortunately, a new method (Proc#pass_option) is needed > because Proc#call(key: val) passes a hash { key => val } as > a normal argument, unless we accept the incompatibility. > This is an interesting approach I hadn't considered. I agree that OCaml's approach works because of the requirement of naming optional arguments (so, for example, I can still pass just the second of three). This also makes me wonder if keyword arguments and currying might not be more related than I had thought. Forgive me for speculating, but what if a curried proc could remember the variable name for its argument? This could provide a mechanism for keyword arguments. In other words, assuming you could do: c = lambda {|first, second="bar"| puts "#{first}, #{second}" }.curry # => #<CurriedProc(lambda)> c.argument_key # => "first" c = c.('foo') c.argument_key # => "second" c.default_value # => "bar" c.("baz") # => "foo, baz" Then you could conceptually implement keyword arguments like so: class KeywordProc def initialize(curried_proc) @curried = curried_proc end def call(args) c = @curried.dup while c.kind_of? Proc do arg = args[c.argument_key] if arg.nil? if c.default_value c = c.() else raise ArgumentError end end c = c.(arg) end end end l = lambda { |first, second="san", third="three"| puts "#{first}, #{second}, #{third}" } k = KeywordProc.new(l.curry) k.call(second: "dos", first: "bir") # => "bir, dos, three" > The future of keyword arguments is promised by matz > [ruby-core:32131]: > > > Keyword arguments will be available on 2.0. I look more and more forward to 2.0 every day, now! Cheers, Josh