December 29, 2011
On Thu, 29 Dec 2011 11:48:13 +0200, Don <nospam@nospam.com> wrote:

> I'm not aware of any languages where positional arguments are not supported. The restrictions imposed by named arguments are a pure superset of the restrictions imposed by positional arguments.

Don, it is a made up argument no one suggesting that.
Forget their implementations in other languages.
NP won't change a single thing for those that don't want to use it.

Rules must be simple. As a user you either use NP for the function entirely or don't use it, no mix.

> David's post implies that they are two independent approaches.
>
> It's pretty obvious what happens when you have named arguments: if you make a poor choice in naming an argument, you generally shouldn't fix it. Documentation suffers.
> Named arguments WILL reduce code quality in some cases.

When you change a parameter name, you change interfaces file and documentation.
Your user will recompile/reread regardless, because you came up with a new version.
Now with NP those that "want to bother" will edit their codes, he asked for it.

If you say someone will be forced to do that i have no argument against that, you are right.
December 29, 2011
On Thursday, 29 December 2011 at 09:07:21 UTC, Max Samukha wrote:
> it is obvious that JavaScript is unnecessarily noisy.

Meh, one man's music is another man's noise.
December 29, 2011
On Fri, 30 Dec 2011 01:16:56 +1100, Mehrdad <wfunction@hotmail.com> wrote:

> On 12/29/2011 3:07 AM, Don wrote:
>> sin(real x);
>> sin(real theta);
>>
>> The argument name is *completely* irrelevant. That shouldn't be part of the interface.
>>
>> I have a really really bad taste in my mouth from named arguments in COM.
> Great example... I can totally think that 'x', 'theta', 't', 'angle', 'radians', 'value', 'val', 'v', etc. could all be valid parameter names (some better than others, obviously).

I'm not so convinced ...

  sin(real elephant);

  set_color( int JohnSmith, int penis, int dictionary);


Actually, names do matter.

-- 
Derek Parnell
Melbourne, Australia
December 29, 2011
On Thursday, December 29, 2011 18:49:51 so wrote:
> When you change a parameter name, you change interfaces file and
> documentation.
> Your user will recompile/reread regardless, because you came up with a new
> version.
> Now with NP those that "want to bother" will edit their codes, he asked
> for it.
> 
> If you say someone will be forced to do that i have no argument against that, you are right.

Recompilation is one thing. Having to change your code is another. Sure, if a file gets changed, when you recompile, any code importing that module will have to be rebuilt, but it doesn't have to be changed. With named arguments, if a parameter change were made, youe'd have to go and change any code which used it as a named argument - just like if you rename a function, you have to change any code which calls that function even if that function does exactly the same thing that it did before.

Introducing named arguments makes a function's parameters part of the API and introduces yet another point where code breakage can occur due to code changes. And that is a _very_ negative aspect of named arguments IMHO.

- Jonathan M Davis
December 29, 2011
Jacob Carlborg:

> When you're implementing a lot of properties that basically just forwards to the instance variables it can be really useful.

http://d.puremagic.com/issues/show_bug.cgi?id=7176

Bye,
bearophile
December 30, 2011
On 12/29/2011 10:19 AM, Don wrote:
> On 28.12.2011 17:41, Jacob Carlborg wrote:
>> On 2011-12-27 23:27, Timon Gehr wrote:
>>> On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
>>>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Andrei
>>>
>>> Great! =)
>>>
>>> What about making => syntax available to named functions as well?
>>>
>>> class C{
>>> private int x;
>>> int getX() => x;
>>> }
>>>
>>>
>>> void main(){
>>> int[] arr;
>>> bool isOdd(int x) => x&1;
>>> writeln(arr.filter!isOdd());
>>> }
>>>
>>
>> I wouldn't say no to that.
>>
>
> I don't think it improves readability,
> since it doesn't occur in
> arbitrary contexts. It'll always be the only thing on the line.

I think it does, certainly as soon as there are multiple short functions. In case the function is used for code generation, it can get rid of one level of indentation.

bool isOdd(int x)  { return x & 1; }
bool isEven(int x) { return !isOdd(x); }
bool isPrime(int x){ return x in primes; }

string generate(string x){
    return mixin(X!q{
        @(x) = 2;
    });
}

vs

bool isOdd(int x)   => x & 1;
bool isEven(int x)  => !isOdd(x);
bool isPrime(int x) => x in primes;

string generate(string x) => mixin(X!q{
    @(x) = 2;
});


> I think that example is close to the best case, but
>
> bool isOdd(int x) { return x & 1; }
>
> is not terribly difficult to read.
> So all you're doing is saving 6 characters + one space.

I think it improves both readability and uniformity. Currently we have

        (){...} // anonymous function
void foo(){...} // named function
        () => ...;  // anonymous function

It would make sense to also allow

void foo() => ...; // named function


> The longer the return expression becomes, the less it matters.
>
> real isComplicated(int param1, Foo param2, real param3) => 43.4 *
> foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
> param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);
>
> doesn't look any more readable than the equivalent code with a return
> statement. Especially not in the member function case.
>

My intention is that it would be used with short expressions. Such monster expressions as in your example are rare in real world code.
December 30, 2011
On 29.12.2011 23:00, Derek wrote:
> On Fri, 30 Dec 2011 01:16:56 +1100, Mehrdad <wfunction@hotmail.com> wrote:
>
>> On 12/29/2011 3:07 AM, Don wrote:
>>> sin(real x);
>>> sin(real theta);
>>>
>>> The argument name is *completely* irrelevant. That shouldn't be part
>>> of the interface.
>>>
>>> I have a really really bad taste in my mouth from named arguments in
>>> COM.
>> Great example... I can totally think that 'x', 'theta', 't', 'angle',
>> 'radians', 'value', 'val', 'v', etc. could all be valid parameter
>> names (some better than others, obviously).
>
> I'm not so convinced ...
>
> sin(real elephant);
>
> set_color( int JohnSmith, int penis, int dictionary);
>
>
> Actually, names do matter.
>
Some names are better than others. But are they part of the API? That's the issue.
Often, parameter names (such as in sin(x)) are arbitrary and meaningless. This is fundamental: the parameter names are arbitrary in mathematics.
December 30, 2011
On Fri, 30 Dec 2011 16:22:49 +1100, Don <nospam@nospam.com> wrote:


> Some names are better than others. But are they part of the API? That's the issue.

Yes, that is an issue.

> Often, parameter names (such as in sin(x)) are arbitrary and meaningless. This is fundamental: the parameter names are arbitrary in mathematics.

Why is that? I just assumed that it was because mathematicians did a lot of repetitive handwriting and thus brevity was important to them.

-- 
Derek Parnell
Melbourne, Australia
December 30, 2011
On 12/30/11 12:25 AM, Derek wrote:
> On Fri, 30 Dec 2011 16:22:49 +1100, Don <nospam@nospam.com> wrote:
>
>
>> Some names are better than others. But are they part of the API?
>> That's the issue.
>
> Yes, that is an issue.
>
>> Often, parameter names (such as in sin(x)) are arbitrary and
>> meaningless. This is fundamental: the parameter names are arbitrary in
>> mathematics.
>
> Why is that? I just assumed that it was because mathematicians did a lot
> of repetitive handwriting and thus brevity was important to them.

Well one non-partisan opinion (in any direction) is I've recently played with e.g. Python's POpen (http://docs.python.org/library/subprocess.html#subprocess.Popen). It's quite comfy to be able to say stdout=somefile, stderr=somefile instead of enumerating arguments and relying on order to make them sensible.

Using such functions is not math, but is part of writing programs.


Andrei
December 30, 2011
Andrei Alexandrescu wrote:

> is part of writing programs

If libraries from more than one author are used with named parameters, inconsistencies in the naming will be a normal problem.

For example: a boolean parameter for generating ouput might be named differently in two libraries as `print' (aka C) or `doWrite' (aka D).

Another: Directions in two dimensions be named `up, down, left, right' or `north, south, west, east'.

Of course the positions for such parameters are also not fixed.

BTW: those who really want named (optional) parameters can already define their own,as   Gor pointed out in digitalmars.D:153790. The expenditures at the call are minimal, i.e `([' parantheses and restating the name of the function for every parameter:

|    f([ f.g= 1, f.h= 2 ]);

-manfred