[#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: [ANN] MacRuby

From: "Rick DeNatale" <rick.denatale@...>
Date: 2008-02-29 13:06:37 UTC
List: ruby-core #15697
On 2/28/08, Eero Saynatkari <ruby-ml@kittensoft.org> wrote:
> On 2008.02.29 08:15, Yukihiro Matsumoto wrote:
>  > That is very important design decision.  Objective-C-ish calling or
>  > Ruby-ish calling.  The latter makes program consistent, but the former
>  > makes program obvious. Hmm.
>
>
> Actually, this would be a really great time to talk about trying to unify
>  the keyword argument syntax across implementations so that we do not have
>  to have that discussion later or contend with several variants. I know that
>  we are not at the 2.0 threshold yet, but obviously folks are starting to
>  get there.
>
>  In the particular case of MacRuby, I would go for implicitness unless
>  there is a reason that the programmer needs to know the difference. If
>  we can define an official syntax (and semantics) for keyword arguments
>  that also helps MacRuby, I think that would be the optimal solution.
>
>  I would probably prefer one of the Smalltalkish variants as the standard:
>
>
>   duck foo: 1, bar: 2
>
>
> This plausibly conforms to current method semantics:
>
>   def duck(**kwargs)              # Implicit in the vcall
>     sym, arg = kwargs.shift
>     __send__ sym, arg, **kwargs
>   end

Except, as I understand the discussion, here duck is a variable
representing the receiver of a message with an objective-c message
selector of foo:bar: and which in Ruby might be written as:

class PotentialClassOfDuck
      def foo(first_arg, keywords={})

      end
end

I think that a reasonable Ruby parser would have a hard time seeing:

     duck foo: 1, bar: 2

as anything other that

    self.duck(foo:1, foo:2)

So I think we'd need to give it some help and write:

   duck.foo: 1, bar:2

which given optional parentheses might also be written(?):

   duck.foo(: 1, bar: 2)

but I'm not happy with either of those for several hopefully obvious
reasons having to do with the dependence on the presence or absences
of easily misread punctuation and whitespace.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

In This Thread

Prev Next