From: gga <ggarra@...>
Date: 2005-10-23T09:37:01+09:00
Subject: Re: A comparison by example of keyword argument styles

Trans said:
>  foo (a=1)  #=> 1

Yes, I am aware of that. But can you actually point to me some library
code that actually uses this as a feature?  I have most definitively
never seen any ruby code using that as of yet, and even then, I would
say that variable assignment within an expression is just something to
win the obfuscated code award, not a useful functionality.

Matz mentioned:
>Besides that, I don't think Python keyword arguments are simple and elegant, but YMMV.

Could you elaborate why you prefer the other syntax?  I can give you my
reasons for strongly suggesting following python's syntax, instead of
what you proposed.

To me, python's approach is simpler because:
a) There is no need for re-definiing a lot of previously written code
with a new syntax.  If you have already written a function like
      def x(a,b,c)
   with the python automatic naming syntax, it makes the code still
work both positionally (as before) and now as named parameters --
automatically.  Using a new syntax like a: or whatever, forces you to
basically have to rewrite all previously written code to make it work
with named parameters.  While certainly functions that have used hashes
to accomplish a similar approach will need to get updated (or those
that used non-sensical names for function parameters), there shouldn't
be the need to update all previously written functions that did not
suffer from this.  By not using any new special symbols, you gain the
functionality in pretty much most already written functions -- all of
ruby library, for example.  A big, big plus, in my opinion.  For the
parser and interpreter, it does makes things harder, but that's more or
less as it should be -- complexity on the side of the interpreter, not
on the side of the user.

b)  There is a symetry between default parameter values and passing new
values to parameters in functions.  This makes the code easier to
comprehend and the language easier to learn.  That is:
      def function(a, b = 2, c = 3):
          ...
      function( 1, b = 4, c = 5)

      or (sans parenthesis)
      function  b = 4, c = 5

     (Yes, I know that with the current use of = in ruby, the above
"function b = 4, c = 5" makes it impossible for the interpreter to
disambiguate, but assume dispatching of equality was not allowed within
functions -- as it isn't during a def definition, so that parsing the
above should be possible).

     Compared to (if I understood the proposal correctly):
      def function(a, b: = 2, c: = 3)  # ugly
      end

      function( 1, b : 4, c : 5)
      function b: 4, c: 5                  # use of :  looks nicer, but
see also point c for issues

      In this proposed ruby syntax, colons are used as assignment in
one situation, while in another situation, it is equality that it is
used.  Confusing.

c) ruby already uses the :x syntax to denote symbols and, in the
ruby1.9 head also for hash definitions with symbol keys.  This presents
another big, big, big source of confusion.
There was already a mail in this thread that already showed the big
confusion this leads to, as someone used the symbol notation in the
function definition incorrectly.  Also,  compare the invokation issues:
       function to = :london, from = :paris
      to:
       function to: :london, from: :paris

    The first example can not lead to typos that the interpreter will
misinterpret.
    However, the second example can lead to two very easy to make
typos:
     function :to :london  # oops, two symbols used, etc. probably
flagged as syntax error during parsing?
     function to::london   # oops, this can NOT flagged as syntax
error, but leads to a runtime error only.  Bad.

     True, with the appearance of named parameters, the use of symbols
in function invokations will probably be much less than what it is now,
but...

Anyway, my 2 cents on the issue.