[#15359] Timeout::Error — Jeremy Thurgood <jerith@...>

Good day,

41 messages 2008/02/05
[#15366] Re: Timeout::Error — Eric Hodel <drbrain@...7.net> 2008/02/06

On Feb 5, 2008, at 06:20 AM, Jeremy Thurgood wrote:

[#15370] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Eric Hodel wrote:

[#15373] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15374] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Nobuyoshi Nakada wrote:

[#15412] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15413] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/07

Nobuyoshi Nakada wrote:

[#15414] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15360] reopen: can't change access mode from "w+" to "w"? — Sam Ruby <rubys@...>

I ran 'rake test' on test/spec [1], using

16 messages 2008/02/05
[#15369] Re: reopen: can't change access mode from "w+" to "w"? — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15389] STDIN encoding differs from default source file encoding — Dave Thomas <dave@...>

This seems strange:

21 messages 2008/02/06
[#15392] Re: STDIN encoding differs from default source file encoding — Yukihiro Matsumoto <matz@...> 2008/02/06

Hi,

[#15481] very bad character performance on ruby1.9 — "Eric Mahurin" <eric.mahurin@...>

I'd like to bring up the issue of how characters are represented in

16 messages 2008/02/10

[#15528] Test::Unit maintainer — Kouhei Sutou <kou@...>

Hi Nathaniel, Ryan,

22 messages 2008/02/13

[#15551] Proc#curry — ts <decoux@...>

21 messages 2008/02/14
[#15557] Re: [1.9] Proc#curry — David Flanagan <david@...> 2008/02/15

ts wrote:

[#15558] Re: [1.9] Proc#curry — Yukihiro Matsumoto <matz@...> 2008/02/15

Hi,

[#15560] Re: Proc#curry — Trans <transfire@...> 2008/02/15

[#15585] Ruby M17N meeting summary — Martin Duerst <duerst@...>

This is a rough translation of the Japanese meeting summary

19 messages 2008/02/18

[#15596] possible bug in regexp lexing — Ryan Davis <ryand-ruby@...>

current:

17 messages 2008/02/19

[#15678] Re: [ANN] MacRuby — "Rick DeNatale" <rick.denatale@...>

On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

18 messages 2008/02/28
[#15679] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#15680] Re: [ANN] MacRuby — Yukihiro Matsumoto <matz@...> 2008/02/28

Hi,

[#15683] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Re: Proc#curry

From: Trans <transfire@...>
Date: 2008-02-26 18:00:23 UTC
List: ruby-core #15668

On Feb 16, 7:48 am, Trans <transf...@gmail.com> wrote:
> On Feb 15, 8:10 pm, "Brian Mitchell" <binar...@gmail.com> wrote:
>
>
>
> > On Fri, Feb 15, 2008 at 5:06 PM, Trans <transf...@gmail.com> wrote:
>
> > >  On Feb 15, 12:46 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> > >  > Hi,
>
> > >  > In message "Re: Proc#curry"
>
> > > >     on Sat, 16 Feb 2008 02:35:23 +0900, Trans <transf...@gmail.com> writes:
>
> > >  > |Is there a link where I can read about how this new function works?
>
> > >  > [ruby-dev:33676], if you don't mind seeing Japanese ;-)
>
> > >  > If you do mind, it's OK.  It's not difficult at all,
>
> > >  >   proc {|x, y, z| x + y + z }.curry
>
> > >  > returns the proc object equivalent to
>
> > >  >   proc {|x| proc {|y| proc {|z| x + y + z } } }
>
> > >  > See?
>
> > >  Yep. I see.
>
> > >  It is rather trivial, I agree. Unfortunately maybe too trivial because
> > >  were stuck with the order of arguments. Or doe curry take some
> > >  argument to vary that? To clarify what I mean, Facets has an
> > >  implementation of curry, for both Proc and Method, like so:
>
> > >   proc {|x, y, z| x + y + z }.curry(__,__,__)
>
> > >  Of course I like your better in this case ;-)  BUT, it does allow:
>
> > >   proc {|x, y, z| x + y + z }.curry(__,5,__)
>
> > >  for:
>
> > >   proc {|x| proc {|z| x + 5 + z } }
>
> > Isn't that partial application not currying per say (one could curry
> > as a way to implement partial application)?
>
> I've also heard it called "partial currying". I'd rather have a
> superset of funtionality then a subset. Currying is about isolating a
> single argument. It doesn't dictate in which argument to isolate. It
> could be x, y, or z, etc. Nor does it mean currying every variable all
> the way down that line.
>
> If we give matz's curry function an arity-slot number as an optional
> argument, then we could do it all like so:
>
>   P = proc { |x,y,z| x+y+z }
>   P.curry(1) => proc { |y| proc |x,z| x+y+z } }
>
> Which would then allow partial applicaiton via:
>
>  P.curry(1)[5]
>
> A second argument could dictate the next level of currying
>
>   P.curry(1,1) => proc { |y| proc |z| proc |x| x+y+z } }

Here is an example implementation:

  class Proc

    def curry(*args)
      if args.empty?
        idx = (0...arity).to_a
      else
        raise ArgumentError, "argument count is greater than arity
(#{args.size} > #{arity})" if args.size > arity
        raise ArgumentError, "arguments must be unique indexes" if
args.uniq != args
        raise ArgumentError, "arguments must be indexes" if args.any?
{ |a| !Fixnum===a }
        idx = (0...arity).to_a
        idx = args + (idx - args)
      end

      rec = ''
      idx.each do |i|
        rec << "proc { |a#{i}| "
      end
      rec << "self["
      rec << (0...arity).to_a.collect{|i| "a#{i}"}.join(',')
      rec << "]"
      rec << "}" * arity

      instance_eval rec
    end

  end

Example:

>> a = proc { |x,y| x**y }
=> #<Proc:0x00002aae4fd50638@(irb):5>
>> b = a.curry(0)
=> #<Proc:0x00002aae4fd4b110@(eval):1>
>> c = a.curry(1)
=> #<Proc:0x00002aae4fd45aa8@(eval):1>
>> b[2][3]
=> 8
>> c[2][3]
=> 9

I'd appreciate suggestions for improvement, as I certainly expect
there are a plenty.

T.

In This Thread