From: Jean-Hugues ROBERT <jean_hugues_robert@...>
Date: 2002-04-17T07:26:53+09:00
Subject: Re: RCR: xx: yy as shorter notation for :xx => yy

Hello,

At 21:17 16/04/2002 +0900, Paul Brannan wrote:
>On Tue, Apr 16, 2002 at 11:10:20AM +0900, Yukihiro Matsumoto wrote:
> > Hmm, I was thinking to use "xxx: yyy" for keyword arguments in the
> > future release.  But this one too is intresting.  I'd like to hear
> > opinion from others.
>
> From the few posts we have so far, it sounds like mixing the two would
>be tricky (and possibly painful on the programmer).  If I have to choose 
>between the two, I think I would take keyword arguments, since there is 
>more to be gained.


Such a choice may not be necessary, keyword arguments and xxx: yyy shorter 
notation for :xxx => yyy work together well =>

Considering the fact that methods callable with keyword arguments are yet 
to be developed / something of the future (existing methods where not 
designed to be called this way), there is little pain in asking the 
developer to tag the arguments that are keyword arguments.

Today (without keyword arguments):
   def drawline( x = O, y = 0, thick = false) xxx end

Tomorrow with keyword argument (my proposal)
   def drawline( x: 0, y: 0, thick: false ) xxx end

Rationnal for tagging keyword arguments using ":" postfix:
   1) The look of the def is similar to the one of a call.
     obj.drawline( x: 45, y: 55, thick: true) # call drawline method
   2) Specifying a default value makes more sense for keyword arguments 
than it does for unamed ones. Hence A) the "=" can be avoided, B) the bad 
looking form def m( x:, y:) where x and y have no default values will be 
rare (btw: it would mean that the argument is mandatory, not optional ; for 
aesthetic reasons an optional "x: mandatory" or "x: required" sugar may be 
permitted).
   3) Having some ":" inside the formal argument list makes it possible for 
the interpreter to know that a method expects keyword arguments. For such a 
method there is less need for the convenient hash object built when extra 
arguments are provided at call time. But such a convenient construction is 
still relatively easy to implement: built the hash with the values that 
remains after the first nth values, where nth matches the number of 
arguments (minus one, the one that will hold the hash). ex:
   def m( x: 0, y: 0, *args ) xxx end
   obj.m( 2, 4, foo: "hello", bar: "world") # positional, not keyworded
   obj.m( x: 2, y: 4, foo: "hello", bar: "world") # args gets foo & bar
   obj.m( x: 2, y: 4) # args gets empty hash
   obj.m( x: 2) # y gets 0, args gets empty hash
   obj.m( y: 4) # x gets 0, args gets empty hash
   obj.m( foo: "hello", bar: "world")
     => exception, bad parameter, expecting x:, y:.
   In this last case, the interpreter could potentially do a better job and 
figure out that x: & y: should get their default value. It would have to 
build the hash first and then unshift the first elements of the hash *if* 
their key matches the name of one of the keyword arguments (pretty 
inefficient I'm afraid)
   obj.m( bar: "world", foo: "hello", x: 0)
     => exception, bad parameter, expecting x:, y:.
   In this case the interpreter might still figure out the intend of the 
caller. However I would question how much readable/contrived this is. That 
keyword arguments should appear before hash entries seems a rather 
reasonable constraint.

Nota: if xxx: yyy is to become equivalent to :xxx => yyy then the previous 
examples would be valid using the current :xxx => yyy form too:
   obj.m( 2, 4, :foo => "hello", :bar => "world")
   obj.m( :x => 2, :y => 4, :foo => "hello", :bar => "world")
   obj.m( :x => 2, :y => 4)
   obj.m( :x => 2)
   obj.m( :y => 4).
Comparing the two, I certainly prefer the former versions (with xxx: yyy) 
but I guess that seasoned Ruby/Perl developers are used to the later 
versions (with :xxx => yyy). Yet, one version is shorter/clearer than the 
other one (to fresh innocent eyes, at least mine).

There is no way a call with keyword arguments can be as efficient as a call 
with "positional" arguments. As a result, the language should make it 
easier to use positional arguments in most cases. keywords arguments should 
be used mostly when there are more than one optional argument. Else you 
design a language that promotes the use of inefficient constructs and this 
may have bad impacts on the success of such a language (that would be 
considered "slow" by people who don't known how much speed they are trading 
to get more flexibility and consequently make the wrong tradeoffs).

Jean-Hugues


---------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17