www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A nice way to step into 2012

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

Andrei
Dec 26 2011
next sibling parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Tuesday, 27 December 2011 at 04:25:00 UTC, Andrei Alexandrescu 
wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei

This change is cooooool! Masahiro
Dec 26 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jdbhas$2ftb$1 digitalmars.com...
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei

Fanfuckingtastic!
Dec 26 2011
prev sibling next sibling parent reply Long Chang <changedalone gmail.com> writes:
Lambda very cooooool!

I hope we can add shared lib support for linux & freebsd in 2012.


On 27 December 2011 12:25, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei

Dec 26 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-27 07:00, Long Chang wrote:
 Lambda very cooooool!

 I hope we can add shared lib support for linux&  freebsd in 2012.


 On 27 December 2011 12:25, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei


And Mac OS X. -- /Jacob Carlborg
Dec 27 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 2:38 PM, Jacob Carlborg wrote:
 On 2011-12-27 07:00, Long Chang wrote:
 Lambda very cooooool!

 I hope we can add shared lib support for linux& freebsd in 2012.


 On 27 December 2011 12:25, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei


And Mac OS X.

Win64 comes to mind. Andrei
Dec 27 2011
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 27 December 2011 at 04:25:00 UTC, Andrei Alexandrescu 
wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei

Finally, it's here! I'll be able to use std.algorithm stuff without tons of named, nested functions now :)
Dec 27 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

Since some time thanks to a post in this newsgroups I am able to compile DMD, so I am able to test the changes early. It seems to work in various situations: import std.stdio, std.range, std.algorithm; int foo(alias callMe)(int a) { return callMe(a); } int bar(alias callMe)() { return callMe(1, 10, 100); } void main() { auto r = foo!((x) => x ^^ 2)(4); assert(r == 16); r = foo!((x,) => x ^^ 2)(5); assert(r == 25); // r = foo!((x,,) => x ^^ 2)(5); // error, good r = foo!(x=>x^^2)(6); assert(r == 36); r = bar!((x, y, z) => x + y + z)(); assert(r == 111); double delegate(double)[] f; f ~= (double x) => x ^^ 2; assert(f[0](10) == 100); // Syntax variety, fit for everyone: auto pow4 = (int x) => x ^^ 4; writeln(map!(function int(in int x) pure nothrow { return x ^^ 4; })(iota(10))); writeln(map!(function int(int x){ return x ^^ 4; })(iota(10))); writeln(map!(function(int x){ return x ^^ 4; })(iota(10))); writeln(map!((int x){ return x ^^ 4; })(iota(10))); writeln(map!((x){ return x ^^ 4; })(iota(10))); writeln(map!((int x) => x ^^ 4)(iota(10))); writeln(map!((x) => x ^^ 4)(iota(10))); writeln(map!(x => x ^^ 4)(iota(10))); writeln(map!q{ a ^^ 4 }(iota(10))); writeln(map!"a^^4"(iota(10))); writeln(map!pow4(iota(10))); } ----------------------- This program contains wrong syntax because x lacks a type: void main() { double delegate(double) f; f = (x) => x + 1; } DMD gives the error messages: test.d(3): Error: undefined identifier x, did you mean variable f? test.d(3): Error: cannot implicitly convert expression (__dgliteral1) of type _error_ delegate(_error_) to double delegate(double) Is it wise to try to improve the second error message? Bye, bearophile
Dec 27 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 3:35 AM, bearophile wrote:
 This program contains wrong syntax because x lacks a type:

 void main() {
      double delegate(double) f;
      f = (x) =>  x + 1;
 }


 DMD gives the error messages:

 test.d(3): Error: undefined identifier x, did you mean variable f?
 test.d(3): Error: cannot implicitly convert expression (__dgliteral1) of type
_error_ delegate(_error_) to double delegate(double)

 Is it wise to try to improve the second error message?

Actually that's an old bug in the compiler. Lambdas without parameter types are really templates, and a template should be assignable to a function or delegate if the parameter type binding works. Andrei
Dec 27 2011
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei

Maybe I'll seem bitter, but I do not think this changement was really that important. This is nice, ok, but we have some other really serious flaw, like shared not doing what it is supposed to do.
Dec 27 2011
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 27/12/11 10:51 AM, deadalnix wrote:
 Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei

Maybe I'll seem bitter, but I do not think this changement was really that important. This is nice, ok, but we have some other really serious flaw, like shared not doing what it is supposed to do.

You seem bitter :-) Seriously though, it's a fair point, but the syntax of lambdas is fairly important and this appears to be a simple change so the cost/benefit ratio is particularly high in this case.
Dec 27 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, December 27, 2011 14:07:25 Jakob Ovrum wrote:
 And it is indeed very important. It's one of the few syntax woes
 we have to deal with in D, it would be a shame to let the
 benefits of std.algorithm and any other functional D code be
 overshadowed by the powerful but often excessive syntax of
 anonymous functions.

I find this sort of discussion to be somewhat funny. I don't think that it's a problem that D has added a new lambda syntax, but what we've had _so_ much better than C++ 98 that I never really cared. Sure, putting the return in there and all that is a bit verbose, but at least we have lambdas! I almost never use the algorithms in C++, because you have to define separate functors elsewhere. You don't even get nested functions! So, I've never seen much reason to complain about D's verbose lambda syntax, because it's so nice to have what we have rather than be forced to create functors and the like. So, this is certainly a welcome change, but I've also found it kind of odd that some people have been complaining about it so much. Most of them probably aren't C++ programmers. - Jonathan M Davis
Dec 27 2011
prev sibling parent "foobar" <foo bar.com> writes:
On Wednesday, 28 December 2011 at 00:21:40 UTC, Jonathan M Davis 
wrote:
 On Tuesday, December 27, 2011 14:07:25 Jakob Ovrum wrote:
 And it is indeed very important. It's one of the few syntax 
 woes
 we have to deal with in D, it would be a shame to let the
 benefits of std.algorithm and any other functional D code be
 overshadowed by the powerful but often excessive syntax of
 anonymous functions.

I find this sort of discussion to be somewhat funny. I don't think that it's a problem that D has added a new lambda syntax, but what we've had _so_ much better than C++ 98 that I never really cared. Sure, putting the return in there and all that is a bit verbose, but at least we have lambdas! I almost never use the algorithms in C++, because you have to define separate functors elsewhere. You don't even get nested functions! So, I've never seen much reason to complain about D's verbose lambda syntax, because it's so nice to have what we have rather than be forced to create functors and the like. So, this is certainly a welcome change, but I've also found it kind of odd that some people have been complaining about it so much. Most of them probably aren't C++ programmers. - Jonathan M Davis

So your argument basically boils down to: "I find it funny that car owners (Non C++ programmers) complain about bicycles not being fast enough. I mean, it's way better than walking (Programming in C++)" I fail to understand what's odd about that.
Dec 28 2011
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 27 December 2011 at 10:57:35 UTC, Peter Alexander 
wrote:
 On 27/12/11 10:51 AM, deadalnix wrote:
 Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei

Maybe I'll seem bitter, but I do not think this changement was really that important. This is nice, ok, but we have some other really serious flaw, like shared not doing what it is supposed to do.

You seem bitter :-) Seriously though, it's a fair point, but the syntax of lambdas is fairly important and this appears to be a simple change so the cost/benefit ratio is particularly high in this case.

This. You can let people play around with it, test it and provide feedback with just a small patch. And it is indeed very important. It's one of the few syntax woes we have to deal with in D, it would be a shame to let the benefits of std.algorithm and any other functional D code be overshadowed by the powerful but often excessive syntax of anonymous functions. It's important when presenting D to initiates that high-level code looks nice.
Dec 27 2011
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 11:51, deadalnix wrote:
 Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei

Maybe I'll seem bitter, but I do not think this changement was really that important. This is nice, ok, but we have some other really serious flaw, like shared not doing what it is supposed to do.

I don't quite agree. Short lambda syntax is *extremely important* for lambdas to actually be useful. If lambda syntax is not short and concise, it's not worth using over, say, a plain foreach loop. I greatly welcome this change. - Alex
Dec 27 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 4:51 AM, deadalnix wrote:
 Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei

Maybe I'll seem bitter, but I do not think this changement was really that important. This is nice, ok, but we have some other really serious flaw, like shared not doing what it is supposed to do.

Imagine how bitter I am that the string lambda syntax didn't catch on! Andrei
Dec 27 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 7:11 AM, Andrei Alexandrescu wrote:
 Imagine how bitter I am that the string lambda syntax didn't catch on!

As I told Andrei last night, I think it was a great experiment. Sure, it failed, but it was a great idea, technically sound, and the fact that it worked is a testament to D's power. If we're not willing to try things like that, we've failed in a much grander sense. So I have no regrets at all about that.
Dec 27 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 11:50 AM, so wrote:
 If C++ or Java (or what have you) had support for string as template
parameters,
 string lambdas probably would be irreplaceable to many.

 |"a % 2"|
 |a => a % 2|

 Still it is shorter.

I know. Unfortunately, the C/C++ text preprocessor has left such a bad taste in peoples' mouths that anything even remotely suggestive of it has an "ick" factor that it is hard to get past.
Dec 27 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 7:21 AM, dsimcha wrote:
 On Tuesday, 27 December 2011 at 15:19:07 UTC, dsimcha wrote:
 On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei Alexandrescu wrote:
 Imagine how bitter I am that the string lambda syntax didn't catch on!

 Andrei

Please tell me they're not going anywhere. I **really** don't want to deal with those being deprecated.

...and they were kind of useful in that you could introspect the string and apply optimizations depending on what the lambda was. I wrote a sorting function that introspected the lambda that was passed to it. If it was "a < b", "a<b", "a > b", etc., and the array to be sorted was floating point, it punned and bit twiddled the floats/doubles to ints/longs, sorted them and bit twiddled and punned them back.

It's not going anywhere, though it likely will disappear from the sample code.
Dec 27 2011
prev sibling next sibling parent "dsimcha" <dsimcha yahoo.com> writes:
On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei Alexandrescu 
wrote:
 Imagine how bitter I am that the string lambda syntax didn't 
 catch on!

 Andrei

Please tell me they're not going anywhere. I **really** don't want to deal with those being deprecated.
Dec 27 2011
prev sibling next sibling parent "dsimcha" <dsimcha yahoo.com> writes:
On Tuesday, 27 December 2011 at 15:19:07 UTC, dsimcha wrote:
 On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei 
 Alexandrescu wrote:
 Imagine how bitter I am that the string lambda syntax didn't 
 catch on!

 Andrei

Please tell me they're not going anywhere. I **really** don't want to deal with those being deprecated.

...and they were kind of useful in that you could introspect the string and apply optimizations depending on what the lambda was. I wrote a sorting function that introspected the lambda that was passed to it. If it was "a < b", "a<b", "a > b", etc., and the array to be sorted was floating point, it punned and bit twiddled the floats/doubles to ints/longs, sorted them and bit twiddled and punned them back.
Dec 27 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 2:51 AM, deadalnix wrote:
 Maybe I'll seem bitter, but I do not think this changement was really that
 important. This is nice, ok, but we have some other really serious flaw, like
 shared not doing what it is supposed to do.

Technically, it is not important at all. It adds zero power and functionality. All it is is a simple syntactical rewrite within the compiler to the old syntax. However, and this is a big however, aesthetically it is a large improvement. People using many diverse languages have made it clear that this is the preferred syntax for lambdas. They expect to see it, or else they mark D as "not having lambdas" and "not supporting functional programming". Syntax matters.
Dec 27 2011
prev sibling next sibling parent so <so so.so> writes:
On Tue, 27 Dec 2011 20:11:41 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 12/27/2011 7:11 AM, Andrei Alexandrescu wrote:
 Imagine how bitter I am that the string lambda syntax didn't catch on!

As I told Andrei last night, I think it was a great experiment. Sure, it failed, but it was a great idea, technically sound, and the fact that it worked is a testament to D's power. If we're not willing to try things like that, we've failed in a much grander sense. So I have no regrets at all about that.

If C++ or Java (or what have you) had support for string as template parameters, string lambdas probably would be irreplaceable to many. |"a % 2"| |a => a % 2| Still it is shorter.
Dec 27 2011
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 27.12.2011, 16:11 Uhr, schrieb Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org>:

 On 12/27/11 4:51 AM, deadalnix wrote:
 Le 27/12/2011 05:25, Andrei Alexandrescu a =C3=A9crit :
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0b=



 Andrei

Maybe I'll seem bitter, but I do not think this changement was really=


 that important. This is nice, ok, but we have some other really serio=


 flaw, like shared not doing what it is supposed to do.

Imagine how bitter I am that the string lambda syntax didn't catch on!=

 Andrei

I used it and I am not sure if it had draw backs, but looking at the cod= e = to support them, it gave me the feeling that you were doing part of the = = job, the compiler should be doing: test if the alias is a string, if it = = can be compiled and assigning variable names to parameters. I once adapt= ed = that style to write something similar to binaryFun and the algorithm = templates. It worked for me after a while, but I found it a bit = complicated. (Before D, I only used templates as far as generic types go= .) = The source code didn't *look* exactly concise and going with the languag= e = to me, if you know what I mean. It shows a nice capability of the langua= ge = - maybe the first time newbies stumble over mixin string, but a short = lambda syntax is as good (because the string mixin doesn't get us anythi= ng = beyond that) and saves the if-else to identify the kind of alias and the= = support code. Honestly, I never really liked the idea of string mixins f= or = general use :D like saving on boilerplate code, multi-inheritance etc. I= t = may seem odd, but I prefer a dozen language features over one string mix= in = feature that can cover them all. That brings me to another point: I like to use IDEs and they must have = difficulties in understanding string mixins and giving hints. There are = no = rules to what you can put in a string, but a lambda syntax defined in th= e = specification can be checked in the IDE.
Dec 28 2011
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei

Awesome! Now the only gripe I have left is type inference for lambdas passed as regular function parameters. Is this something we will see anytime soon? - Alex
Dec 27 2011
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 15:19, Alex Rønne Petersen wrote:
 On 27-12-2011 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei

Awesome! Now the only gripe I have left is type inference for lambdas passed as regular function parameters. Is this something we will see anytime soon? - Alex

Just to make it clear what I want to be able to do (simple example with arrays): T[] filter(T)(T[] items, scope bool delegate(T) predicate) { T[] newItems; foreach (item; items) if (predicate(item)) newItems ~= item; return newItems; } auto ints = filter([0, 1, 2, 3, 4, 5], x => x % 2 != 0); Or perhaps even better, when we get fully working UFCS: auto ints = [0, 1, 2, 3, 4, 5].filter(x => x % 2 != 0); DMD should be able to infer the parameter type(s) of the delegate I'm passing, since that's clear from the array being passed. (I would recommend looking at how C#'s type inference rules work; they're quite sophisticated for an imperative language.) - Alex
Dec 27 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jdckl1$1hfb$1 digitalmars.com...
 Or perhaps even better, when we get fully working UFCS:

 auto ints = [0, 1, 2, 3, 4, 5].filter(x => x % 2 != 0);

That is just beautiful.
Dec 27 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:
 Wouldn't it be great if Santa were to give us named arguments this year too?
 :)

Only if he hates me. But I guess that I'm in the minority around here in that I hate the idea of named arguments. - Jonathan M Davis
Dec 27 2011
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 28/12/11 2:57 PM, Andrej Mitrovic wrote:
 But I bet one day Walter&  Co. will have another phone conversation
 and then magically we'll have named arguments the next day, without
 asking the community about how it feels about the inclusion (e.g. just
 like D1 deprecation, this lambda syntax, and other behind-the-scenes
 decisions between Walter and Andrei). All it will take is probably an
 angry Redditor or maybe some coworker at Facebook that asked for the
 feature.

 I'm just against decisions made between the two heads of state that
 happen over night. I'd like a little more transparency from our "D
 government", if you know what I mean. ;-)

The lambda syntax was discussed at length with the community a while ago.
Dec 28 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 16:14, Peter Alexander wrote:
 On 28/12/11 2:57 PM, Andrej Mitrovic wrote:
 But I bet one day Walter& Co. will have another phone conversation
 and then magically we'll have named arguments the next day, without
 asking the community about how it feels about the inclusion (e.g. just
 like D1 deprecation, this lambda syntax, and other behind-the-scenes
 decisions between Walter and Andrei). All it will take is probably an
 angry Redditor or maybe some coworker at Facebook that asked for the
 feature.

 I'm just against decisions made between the two heads of state that
 happen over night. I'd like a little more transparency from our "D
 government", if you know what I mean. ;-)

The lambda syntax was discussed at length with the community a while ago.

... and it was basically decided that it should be added to the language. -- /Jacob Carlborg
Dec 28 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/11 8:57 AM, Andrej Mitrovic wrote:
 I can understand how Jonathan has no problem writing verbose code, but
 I'd rather not have to write enums all over the place just to use a
 true/false flag that is obvious at the call site compared to calls
 like this:

 showWidget(true, false);

 But I bet one day Walter&  Co. will have another phone conversation
 and then magically we'll have named arguments the next day, without
 asking the community about how it feels about the inclusion (e.g. just
 like D1 deprecation, this lambda syntax, and other behind-the-scenes
 decisions between Walter and Andrei). All it will take is probably an
 angry Redditor or maybe some coworker at Facebook that asked for the
 feature.

Well as Peter said, this is a tad unfair. The decision on lambdas is a logical consequence of many months of discussing the issue back and forth across the community. The decision to discontinue D1 could have been carried more elegantly, and I apologize for that. Nevertheless it would have been just as inevitable, and clearly it is doing and will continue to do a world of good to D. If anything I am sorry we didn't take the step earlier. Announcing a two-year expiration of D1 at the end of 2010 would have been even better.
 I'm just against decisions made between the two heads of state that
 happen over night. I'd like a little more transparency from our "D
 government", if you know what I mean. ;-)

Roger that. Also, I'm not sure if you were around - things did improve quite a bit compared to a while ago. Andrei
Dec 28 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 14:18, Marco Leise wrote:
 Am 28.12.2011, 01:22 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:
 Wouldn't it be great if Santa were to give us named arguments this
 year too?
 :)

Only if he hates me. But I guess that I'm in the minority around here in that I hate the idea of named arguments. - Jonathan M Davis

Despite that feature being optional to use, I could understand you if you think it only makes sense on obscure 'true'/'false' flags and prefer named enums there. Then there would be two ways to do the same thing, which annoys language purists like me ^^. (…, overwrite = true); vs. (…, CreateMode.overwrite); But named parameters can do more, like skipping some optional parameters and using others. int foo(int a = 0, int b = 1, int c = 2) {} foo(c = 3);

That's where they are really useful. When C# got named arguments and optional arguments it became a lot easier to use COM functions: http://msdn.microsoft.com/en-us/library/dd264739.aspx -- /Jacob Carlborg
Dec 28 2011
prev sibling next sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 28.12.2011, 01:22 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>=
:

 On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:
 Wouldn't it be great if Santa were to give us named arguments this ye=


 too?
 :)

Only if he hates me. But I guess that I'm in the minority around here =

 that
 I hate the idea of named arguments.

 - Jonathan M Davis

Despite that feature being optional to use, I could understand you if yo= u = think it only makes sense on obscure 'true'/'false' flags and prefer nam= ed = enums there. Then there would be two ways to do the same thing, which = annoys language purists like me ^^. (=E2=80=A6, overwrite =3D true); vs. (=E2=80=A6, CreateMode.overwrite); But named parameters can do more, like skipping some optional parameters= = and using others. int foo(int a =3D 0, int b =3D 1, int c =3D 2) {} foo(c =3D 3);
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 09:25 PM, Jonathan M Davis wrote:
 On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:
 I can understand how Jonathan has no problem writing verbose code, but
 I'd rather not have to write enums all over the place just to use a
 true/false flag that is obvious at the call site compared to calls
 like this:

 showWidget(true, false);

I'm not a big fan of the enum's for true/false either. I have no problem whatsoever with the above line of code. I'd much rather have that than named arguments. The primary reason that I really don't like named arguments is the fact that the names of the parameters become part of the API.

That assumes every parameter is implicitly named. If named arguments ever get into the language, then they should imho be marked as named arguments explicitly at function declaration point.
 I also don't think that they add much unless you have functions with way too
many parameters, and
 those sorts of functions shouldn't be happening anyway. And I don't like the
 additional complication of the possibility of reordering functiion arguments.
 You should be able to look at a function and know which parameters its
 arguments go with purely by the order, which named arguments destroy.

Why would that be beneficial?
 But all of that has been discussed at length before. I'm completely opposed to
 the idea, but I seem to be in the minority (at least out of those who spoke
 up).

 - Jonathan M Davis

I don't need named arguments either, but I don't think they would hurt if implemented as a purely optional feature.
Dec 28 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 09:57 PM, Jonathan M Davis wrote:
 On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
 I also don't think that they add much unless you have functions with way
 too many parameters, and those sorts of functions shouldn't be
 happening anyway. And I don't like the additional complication of the
 possibility of reordering functiion arguments. You should be able to
 look at a function and know which parameters its arguments go with
 purely by the order, which named arguments destroy.


I'd hate to have a function like void func(float x, float y); where calling it func(1.0, 2.0); and func(y : 1.0, x : 2.0); don't do the same thing. All of a sudden, I have to pay attention to what names the arguments were given. I can't just read the function call like I would now. It becomes error-prone in that regard and violates the current expectations of argument order. It will make code harder to read for minimal benefit IMHO. I do _not_ think that name arguments are an improvement.

So it is the usual "because the feature can be misused it is bad" argument?
 But all of that has been discussed at length before. I'm completely
 opposed to the idea, but I seem to be in the minority (at least out of
 those who spoke up).

 - Jonathan M Davis

I don't need named arguments either, but I don't think they would hurt if implemented as a purely optional feature.

Since they affect the API, they _do_ hurt. Since then any changes to parameter names break code. So, it has a definite affect on code maintainibility even if I don't use the feature myself. I also don't want to see them in code. If the example above were possible, then someone would use it in their code (even if I didn't), and I'd have to deal with all of the code readibility issues that it causes. Named arguments _would_ hurt the language even if they were purely optional. - Jonathan M Davis

That is not what I'd call purely optional. Timon Gehr wrote:
 That assumes every parameter is implicitly named. If named arguments ever get
 into the language, then they should imho be marked as named arguments
explicitly
 at function declaration point.

Dec 28 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 11:34 PM, so wrote:
 If you change "anything" in your interface, it is already a breaking
 change.

That is why it is desirable to not let parameter names contribute to the interface. Jonathan definitely has a point against making all parameters named parameters by default. From a recent thread in D.learn: Christophe wrote:
 Timon Gehr wrote:
 but the drawback is that the parameter names become part of the
 public interface.

Well, that's precisely the point. And it is a drawback if parameters are systematically names, but not if it is triggered only on demand. Example : void foo(int a, int b:, int c:); void main() { foo(1, 2, 3); foo(1, c: 3, b: 2; foo(a: 1, b: 2, c: 3); // error : a is not a named parameter. } In the example, ":" is used to make a named parameter to recall the use when you call the function.

I thought that was pretty convincing.
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 12:29 AM, so wrote:
 On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 12/28/2011 11:34 PM, so wrote:
 If you change "anything" in your interface, it is already a breaking
 change.

That is why it is desirable to not let parameter names contribute to the interface. Jonathan definitely has a point against making all parameters named parameters by default.

/// A.d void fun1(int Arg); void fun2(int x); /// B.d void fun1(int arg); void fun2(int y); I am having hard time understanding the issue really. Now as a user i don't know why the library dev. changed the interface: /// without NP fun1(arg); // recompile no edit, fun2(x); // well You are saying like changing a parameter name in lib code is always so harmless. You guys making your case on a dumb developer that goes for a breaking change just to fix a always harmless typo.

I have a hard time understanding your case. You wrote /// without NP. Without NP it is perfectly reasonable to fix the typo and there is no breaking change. That is part of why having no NP by default is desirable. The moment NP by default is introduced is the moment all parameter names in all libraries are set in stone. Those names were mere implementation details prior to that point in time. Having parameter names contribute to the interface means that all developers need to spend time thinking about the best possible names for their function parameters.
 Then, what makes you so sure he won't do this?

What makes you so sure that if he does, he actually remembers to change the functionality too?
Dec 28 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:

 Having parameter names contribute to the interface means that all 
 developers need to spend time thinking about the best possible names for 
 their function parameters.

And this is a good thing :-) It helps you understand the function purpose better. Bye, bearophile
Dec 28 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 12:58 AM, so wrote:
 On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:

 The moment NP by default is introduced is the moment all parameter
 names in all libraries are set in stone.

This is completely false. NP affects only those that "want" to use it, no one else. Again, no one. It is just like inline asm.

No, it is not. If all parameters are named parameters, then the library writers have to be aware of the fact that some users might use named arguments. Again, every library writer is affected.
 Those names were mere implementation details prior to that point in time.
 Having parameter names contribute to the interface means that all
 developers need to spend time thinking about the best possible names
 for their function parameters.

 Then, what makes you so sure he won't do this?

What makes you so sure that if he does, he actually remembers to change the functionality too?

You are not making any sense here i am sorry.

That was the point. I was continuing the reasoning in your previous post.
Dec 28 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 02:02 AM, so wrote:
 On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 12/29/2011 12:58 AM, so wrote:
 On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch>
 wrote:

 The moment NP by default is introduced is the moment all parameter
 names in all libraries are set in stone.

This is completely false. NP affects only those that "want" to use it, no one else. Again, no one. It is just like inline asm.

No, it is not. If all parameters are named parameters, then the library writers have to be aware of the fact that some users might use named arguments. Again, every library writer is affected.

Show me any library code from any language where library writer is not already "aware" their argument names define their function. They even document it that way. /// a does this, b does that void fun(int a, int b)

Documentation can be improved over time. It cannot be argued that the widening of the set of exposed names is a positive aspect of named arguments.
Dec 28 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 29.12.2011 02:02, so wrote:
 On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 12/29/2011 12:58 AM, so wrote:
 On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch>
 wrote:

 The moment NP by default is introduced is the moment all parameter
 names in all libraries are set in stone.

This is completely false. NP affects only those that "want" to use it, no one else. Again, no one. It is just like inline asm.

No, it is not. If all parameters are named parameters, then the library writers have to be aware of the fact that some users might use named arguments. Again, every library writer is affected.

Show me any library code from any language where library writer is not already "aware" their argument names define their function. They even document it that way. /// a does this, b does that void fun(int a, int b)

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.
Dec 29 2011
next sibling parent Don <nospam nospam.com> writes:
On 29.12.2011 09:34, Derek wrote:
 On Thu, 29 Dec 2011 19:07:17 +1100, Don <nospam nospam.com> 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.

Were you forced to use named parameters or was it optional?

Forced to support them. The great evil is that the named arguments can arrive in any order. You're not forced to use them. It's just for the benefit of VB.
Dec 29 2011
prev sibling parent reply Mehrdad <wfunction hotmail.com> writes:
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.

'radians', 'value', 'val', 'v', etc. could all be valid parameter names (some better than others, obviously).
Dec 29 2011
parent reply Don <nospam nospam.com> writes:
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.

'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.

the issue. Often, parameter names (such as in sin(x)) are arbitrary and meaningless. This is fundamental: the parameter names are arbitrary in mathematics.
Dec 29 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 29 2011
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
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
Dec 30 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 30.12.2011 07:36, Andrei Alexandrescu wrote:
 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.

There are definitely cases when you can create a much nicer API, when you can use named parameters. This is particularly true of flags, and where there are default parameters. But I think that (a) it's not _all_ functions; and (b) you probably want to use named parameters consistently. I think it would be poor form to write these two lines in the same module: Popen(args, None, None, somefile, somefile); Popen(args, stdout : somefile, stderr : somefile); so in the particular example of Popen, I think *requiring* all those parameters to be named in all calls wouldn't be a bad thing. Dunno if that's true in general though. Note that in C/C++ you can easily create a header file where the parameters aren't named. But that isn't really available in D. So there isn't even an opt-out mechanism. I think: there are cases when named parameters are beneficial. There are cases where they are detrimental. Is it possible to get the first, without the second, and without much complexity? (I'm thinking of something like, a colon before the parameter name means the name is part of the API).
Dec 30 2011
parent reply Don <nospam nospam.com> writes:
On 31.12.2011 02:27, so wrote:
 On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:

 I think: there are cases when named parameters are beneficial. There
 are cases where they are detrimental.
 Is it possible to get the first, without the second, and without much
 complexity?

If we keep rules simple as possible i think it is possible. For that we need our own rules i think, remembering all those rules suggested here i can understand why people have issues with them.
 (I'm thinking of something like, a colon before the parameter name
 means the name is part of the API).

This i don't like, we shouldn't change anything on API side. All they need to know is that their parameter names (if they provid one) might be used in NPs. Otherwise it would complicate both implementation and usability.

But it is IMPOSSIBLE to not provide them.
Dec 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/31/2011 12:13 PM, Don wrote:
 On 31.12.2011 02:27, so wrote:
 On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:

 I think: there are cases when named parameters are beneficial. There
 are cases where they are detrimental.
 Is it possible to get the first, without the second, and without much
 complexity?

If we keep rules simple as possible i think it is possible. For that we need our own rules i think, remembering all those rules suggested here i can understand why people have issues with them.
 (I'm thinking of something like, a colon before the parameter name
 means the name is part of the API).

This i don't like, we shouldn't change anything on API side. All they need to know is that their parameter names (if they provid one) might be used in NPs. Otherwise it would complicate both implementation and usability.

But it is IMPOSSIBLE to not provide them.

It is possible: void foo(int, float, double, string); But then it is impossible to have an implementation around for CTFE.
Dec 31 2011
parent reply Don <nospam nospam.com> writes:
On 31.12.2011 16:26, Timon Gehr wrote:
 On 12/31/2011 12:13 PM, Don wrote:
 On 31.12.2011 02:27, so wrote:
 On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:

 I think: there are cases when named parameters are beneficial. There
 are cases where they are detrimental.
 Is it possible to get the first, without the second, and without much
 complexity?

If we keep rules simple as possible i think it is possible. For that we need our own rules i think, remembering all those rules suggested here i can understand why people have issues with them.
 (I'm thinking of something like, a colon before the parameter name
 means the name is part of the API).

This i don't like, we shouldn't change anything on API side. All they need to know is that their parameter names (if they provid one) might be used in NPs. Otherwise it would complicate both implementation and usability.

But it is IMPOSSIBLE to not provide them.

It is possible: void foo(int, float, double, string);

Only if you create and hand-edit a .di file. And that won't even work for templates.
 But then it is impossible to have an implementation around for CTFE.

Dec 31 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/01/2012 08:17 AM, Don wrote:
 On 31.12.2011 16:26, Timon Gehr wrote:
 On 12/31/2011 12:13 PM, Don wrote:
 On 31.12.2011 02:27, so wrote:
 On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:

 I think: there are cases when named parameters are beneficial. There
 are cases where they are detrimental.
 Is it possible to get the first, without the second, and without much
 complexity?

If we keep rules simple as possible i think it is possible. For that we need our own rules i think, remembering all those rules suggested here i can understand why people have issues with them.
 (I'm thinking of something like, a colon before the parameter name
 means the name is part of the API).

This i don't like, we shouldn't change anything on API side. All they need to know is that their parameter names (if they provid one) might be used in NPs. Otherwise it would complicate both implementation and usability.

But it is IMPOSSIBLE to not provide them.

It is possible: void foo(int, float, double, string);

Only if you create and hand-edit a .di file. And that won't even work for templates.

void foo(T...)(T _); Then you have to manually reproduce overloading rules inside the template body. But you are right. There is no satisfactory solution.
 But then it is impossible to have an implementation around for CTFE.


Jan 01 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 02:04 AM, Derek wrote:
 On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr gmx.ch> wrote:

 Having parameter names contribute to the interface means that all
 developers need to spend time thinking about the best possible names
 for their function parameters.

And that's a bad thing, right?

If the time was better spent at creating functionality, yes. http://www.digitalmars.com/d/archives/digitalmars/D/Rename_std.string.toStringz_138740.html http://www.digitalmars.com/d/archives/digitalmars/D/Fixing_enum_names_in_Phobos_141507.html http://www.digitalmars.com/d/archives/digitalmars/D/std.getopt_suggestion_145648.html#N145648 http://www.digitalmars.com/d/archives/digitalmars/D/renamepalooza_time_127446.html ... etc.
 Named parameters do have the issue that once released, it is can be
 costly to change the names. It therefore is important that library
 developers take enough time to consider parameter names, much in the
 same manner as they are currently consider existing exposed names.

 To assist those developers, a name deprecation facility could be
 introduced to alert users of pending removal of old names. This would of
 course only be of interest to those developers who choose to use named
 parameters in their code.

 There is a similar issue with positional parameters; once released, the
 library developer would be unwise to alter the order of parameters. But
 somehow, we have managed to educate ourselves so as to (mostly) avoid
 this problem.


 In general, I'd support optional named parameters and would encourage
 their usage in those situations where it makes source code more
 understandable to other readers.

I am indifferent whether or not to add them.
Dec 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:

 On 12/29/2011 02:04 AM, Derek wrote:
 On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr gmx.ch> wrote:

 Having parameter names contribute to the interface means that all
 developers need to spend time thinking about the best possible names
 for their function parameters.

And that's a bad thing, right?

If the time was better spent at creating functionality, yes. http://www.digitalmars.com/d/archives/digitalmars/D/Rename_std.string.toStringz_138740.html http://www.digitalmars.com/d/archives/digitalmars/D/Fixing_enum_names_in_Phobos_141507.html http://www.digitalmars.com/d/archives/digitalmars/D/std.getopt_suggestion_145648.html#N145648 http://www.digitalmars.com/d/archives/digitalmars/D/renamepalooza_time_127446.html

I don't agree. Names are among the most important things in a human mind, if you find the right names, API usability improves. Thinking about the best names is time well spent, especially for library functions used by a lot of all kind of people for a lot of time. Bye, bearophile
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 03:38 AM, bearophile wrote:
 Timon Gehr:

 On 12/29/2011 02:04 AM, Derek wrote:
 On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr<timon.gehr gmx.ch>  wrote:

 Having parameter names contribute to the interface means that all
 developers need to spend time thinking about the best possible names
 for their function parameters.

And that's a bad thing, right?

If the time was better spent at creating functionality, yes. http://www.digitalmars.com/d/archives/digitalmars/D/Rename_std.string.toStringz_138740.html http://www.digitalmars.com/d/archives/digitalmars/D/Fixing_enum_names_in_Phobos_141507.html http://www.digitalmars.com/d/archives/digitalmars/D/std.getopt_suggestion_145648.html#N145648 http://www.digitalmars.com/d/archives/digitalmars/D/renamepalooza_time_127446.html

I don't agree. Names are among the most important things in a human mind, if you find the right names, API usability improves. Thinking about the best names is time well spent, especially for library functions used by a lot of all kind of people for a lot of time. Bye, bearophile

My point is, without named arguments you can improve the names at any time. With named arguments, you are stuck and have to get it right upfront.
Dec 28 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:

 My point is, without named arguments you can improve the names at any 
 time. With named arguments, you are stuck and have to get it right upfront.

I think library code doesn't change argument names often, and when this happens I have suggested a way to deprecate argument names. Somehow Scala and Ada programmers survive to that :-) Bye, bearophile
Dec 28 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 12/29/11 3:46 AM, Timon Gehr wrote:
 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right upfront.

My point is, without positional arguments you can improve the ordering at any time. With positional arguments, you are stuck and have to get it right upfront. David
Dec 28 2011
parent reply Don <nospam nospam.com> writes:
On 29.12.2011 04:48, David Nadlinger wrote:
 On 12/29/11 3:46 AM, Timon Gehr wrote:
 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right
 upfront.

My point is, without positional arguments you can improve the ordering at any time. With positional arguments, you are stuck and have to get it right upfront. David

That's rubbish! Unless you plan to disallow positional arguments...
Dec 29 2011
parent reply Don <nospam nospam.com> writes:
On 29.12.2011 09:39, Derek wrote:
 On Thu, 29 Dec 2011 19:08:36 +1100, Don <nospam nospam.com> wrote:

 On 29.12.2011 04:48, David Nadlinger wrote:
 On 12/29/11 3:46 AM, Timon Gehr wrote:
 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right
 upfront.

My point is, without positional arguments you can improve the ordering at any time. With positional arguments, you are stuck and have to get it right upfront. David

That's rubbish! Unless you plan to disallow positional arguments...

Maybe you missed the point? I see the point in David's response as being that regardless of whether we have positional or named parameters, once exposed, they are pretty well set in concrete. I think that no one is suggesting that position parameters are to be replaced by named ones. The upshot of the idea would be that a API user would be free to choose between whatever *they* felt was appropriate.

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. 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. There are definitely cases where named arguments are beneficial, though I suspect that most of them involve poorly designed functions. (The Windows CreateFont() function is my favourite example). As an always-on feature, I can see as more downsides than upsides. OTOH if it were an opt-in feature (for the library writer), I'd be completely in favour.
Dec 29 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Dec 29 2011
parent Don <nospam nospam.com> writes:
On 31.12.2011 02:37, so wrote:
 On Thu, 29 Dec 2011 23:59:46 +0200, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:

 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.

Yes but luckily i think it is the only downside. You have to edit, if you (or your boss) asked for. Now only question is if it worths. Remembering all those cryptic parameter passing cases i think it does. And good thing is that it is an additive change to the language.

But if you're a library writer, and you change a parameter name, users _will_ complain. In practice, this means you can't change them, even if it was a really bad name. I also find it interesting that at the same time as we're making anonymous functions much easier to write, people want to remove the ability to have anonymous parameters. It isn't an additive change to the language. It reinterprets existing code.
Dec 31 2011
prev sibling parent so <so so.so> writes:
On Thu, 29 Dec 2011 23:59:46 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 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.

Yes but luckily i think it is the only downside. You have to edit, if you (or your boss) asked for. Now only question is if it worths. Remembering all those cryptic parameter passing cases i think it does. And good thing is that it is an additive change to the language.
Dec 30 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I can understand how Jonathan has no problem writing verbose code, but
I'd rather not have to write enums all over the place just to use a
true/false flag that is obvious at the call site compared to calls
like this:

showWidget(true, false);

But I bet one day Walter & Co. will have another phone conversation
and then magically we'll have named arguments the next day, without
asking the community about how it feels about the inclusion (e.g. just
like D1 deprecation, this lambda syntax, and other behind-the-scenes
decisions between Walter and Andrei). All it will take is probably an
angry Redditor or maybe some coworker at Facebook that asked for the
feature.

I'm just against decisions made between the two heads of state that
happen over night. I'd like a little more transparency from our "D
government", if you know what I mean. ;-)

Anyway this new lambda thing is sweet.
Dec 28 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-27 15:27, Alex Rønne Petersen wrote:
 On 27-12-2011 15:19, Alex Rønne Petersen wrote:
 On 27-12-2011 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc




 Andrei

Awesome! Now the only gripe I have left is type inference for lambdas passed as regular function parameters. Is this something we will see anytime soon? - Alex

Just to make it clear what I want to be able to do (simple example with arrays): T[] filter(T)(T[] items, scope bool delegate(T) predicate) { T[] newItems; foreach (item; items) if (predicate(item)) newItems ~= item; return newItems; } auto ints = filter([0, 1, 2, 3, 4, 5], x => x % 2 != 0); Or perhaps even better, when we get fully working UFCS: auto ints = [0, 1, 2, 3, 4, 5].filter(x => x % 2 != 0); DMD should be able to infer the parameter type(s) of the delegate I'm passing, since that's clear from the array being passed. (I would recommend looking at how C#'s type inference rules work; they're quite sophisticated for an imperative language.) - Alex

The type inference in Scala is very powerful as well. -- /Jacob Carlborg
Dec 28 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 8:19 AM, Alex Rønne Petersen wrote:
 Now the only gripe I have left is type inference for lambdas passed as
 regular function parameters. Is this something we will see anytime soon?

It's among the [tdpl] bugs, so I hope fairly soon. Andrei
Dec 27 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Wouldn't it be great if Santa were to give us named arguments this year too? :)
Dec 27 2011
prev sibling next sibling parent reply Joshua Reusch <yoschi arkandos.de> writes:
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei

------------- import std.algorithm; void main() { auto arr = [0, 5, 4, 3, 2, 1]; sort!((a, b) => a < b)(arr); } ------------- $ ./dmd lambda_test dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed. $ This also "works" with other functions from std.algorithm.
Dec 27 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 9:21 AM, Joshua Reusch wrote:
 Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei

------------- import std.algorithm; void main() { auto arr = [0, 5, 4, 3, 2, 1]; sort!((a, b) => a < b)(arr); } ------------- $ ./dmd lambda_test dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed. $ This also "works" with other functions from std.algorithm.

Not even 11h before the first bug report. What's odd about this is that the code works with both the string syntax and the "long lambda" syntax, and the new syntax is simply doing a rewrite to the long lambda syntax. Andrei
Dec 27 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 9:51 AM, Torarin wrote:
 2011/12/27 Joshua Reusch<yoschi arkandos.de>:
 Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei

------------- import std.algorithm; void main() { auto arr = [0, 5, 4, 3, 2, 1]; sort!((a, b) => a< b)(arr); } ------------- $ ./dmd lambda_test dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd))))&& old_size == 0) || ((unsigned long) (old_size)>= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1))& ~((2 * (sizeof(size_t))) - 1)))&& ((old_top)->size& 0x1)&& ((unsigned long)old_end& pagemask) == 0)' failed. $ This also "works" with other functions from std.algorithm.

Did you do a clean before compiling? I forgot, and got the same error. Torarin

I confirm the new syntax works after a rebase and clean rebuild. Andrei
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 10:50 AM, Trass3r wrote:
 On Tuesday, 27 December 2011 at 16:33:30 UTC, Andrei Alexandrescu wrote:
 On 12/27/11 9:51 AM, Torarin wrote:
 2011/12/27 Joshua Reusch<yoschi arkandos.de>:
 $ ./dmd lambda_test
 dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
 (((char *)
 &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
 malloc_chunk,
 fd))))&& old_size == 0) || ((unsigned long) (old_size)>= (unsigned
 long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
 (sizeof(size_t))) - 1))& ~((2 * (sizeof(size_t))) - 1)))&&
 ((old_top)->size& 0x1)&& ((unsigned long)old_end& pagemask) == 0)'
 failed.

Did you do a clean before compiling? I forgot, and got the same error.

I confirm the new syntax works after a rebase and clean rebuild.

I've always wondered how dmd manages to do that. It's well known that dmd gives you a nut kick if you try to compile D code incrementally. But even the dmd source itself has to be rebuilt every time if you don't want strange errors and that's C++. I don't even know if it's a laughing matter or not.

I think it's a makefile matter. Andrei
Dec 27 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:
 On 12/27/11 10:50 AM, Trass3r wrote:
 But even the dmd source itself has to be rebuilt every time if you don't
 want strange errors and that's C++.

 I don't even know if it's a laughing matter or not.

I think it's a makefile matter.

The makefile for dmd doesn't have the dependencies on .h files set up properly. If a .h file is changed, the thing to do is make clean and then build. (Even when I do set up the .h file dependencies right, bit rot creeps in and wastes my time trying to figure out what went wrong. I just make clean and rebuild.)
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 12:03 PM, Walter Bright wrote:
 On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:
 On 12/27/11 10:50 AM, Trass3r wrote:
 But even the dmd source itself has to be rebuilt every time if you don't
 want strange errors and that's C++.

 I don't even know if it's a laughing matter or not.

I think it's a makefile matter.

The makefile for dmd doesn't have the dependencies on .h files set up properly. If a .h file is changed, the thing to do is make clean and then build. (Even when I do set up the .h file dependencies right, bit rot creeps in and wastes my time trying to figure out what went wrong. I just make clean and rebuild.)

Problem is lack of automation (in this case makdepend). As usual, I have an optimistic view on the help that automation can bring to our project. Andrei
Dec 27 2011
next sibling parent Joshua Reusch <yoschi arkandos.de> writes:
Am 27.12.2011 19:09, schrieb Andrei Alexandrescu:
 On 12/27/11 12:03 PM, Walter Bright wrote:
 On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:
 On 12/27/11 10:50 AM, Trass3r wrote:
 But even the dmd source itself has to be rebuilt every time if you
 don't
 want strange errors and that's C++.

 I don't even know if it's a laughing matter or not.

I think it's a makefile matter.

The makefile for dmd doesn't have the dependencies on .h files set up properly. If a .h file is changed, the thing to do is make clean and then build. (Even when I do set up the .h file dependencies right, bit rot creeps in and wastes my time trying to figure out what went wrong. I just make clean and rebuild.)

Problem is lack of automation (in this case makdepend). As usual, I have an optimistic view on the help that automation can bring to our project. Andrei

ok, after a clean/rebuild it works. my fault, sorry ...
Dec 27 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 10:09 AM, Andrei Alexandrescu wrote:
 Problem is lack of automation (in this case makdepend).

I've used makedepend before. (I even wrote one!) It just never caught on.
 As usual, I have an
 optimistic view on the help that automation can bring to our project.

All my build scripts start with make clean. Having make clean work right is something I do make an effort towards.
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 2:10 PM, Walter Bright wrote:
 On 12/27/2011 10:09 AM, Andrei Alexandrescu wrote:
 Problem is lack of automation (in this case makdepend).

I've used makedepend before. (I even wrote one!) It just never caught on.

It's improved a tone lately, particularly since gcc has built-in support for it. It all comes back to using Unix as your development environment.
  > As usual, I have an
  > optimistic view on the help that automation can bring to our project.

 All my build scripts start with make clean.

One good realization to make is how less efficient that makes you. You got used to that overhead so plentily, you consider it now par for the course. Andrei
Dec 27 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
 One good realization to make is how less efficient that makes you. You got used
 to that overhead so plentily, you consider it now par for the course.

What takes time is running the unittests, not compiling dmd.
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 2:38 PM, Walter Bright wrote:
 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
 One good realization to make is how less efficient that makes you. You
 got used
 to that overhead so plentily, you consider it now par for the course.

What takes time is running the unittests, not compiling dmd.

Then _that_ is what you consider par for the course! :o) Andrei
Dec 27 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:
 On 12/27/11 2:38 PM, Walter Bright wrote:
 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
 One good realization to make is how less efficient that makes you. You
 got used
 to that overhead so plentily, you consider it now par for the course.

What takes time is running the unittests, not compiling dmd.

Then _that_ is what you consider par for the course! :o) Andrei

Has anyone looked into what causes the unittests to take so long? I find it hard to believe that they need to take as long as they do.
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 10:53 AM, Peter Alexander wrote:
 On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:
 On 12/27/11 2:38 PM, Walter Bright wrote:
 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
 One good realization to make is how less efficient that makes you. You
 got used
 to that overhead so plentily, you consider it now par for the course.

What takes time is running the unittests, not compiling dmd.

Then _that_ is what you consider par for the course! :o) Andrei

Has anyone looked into what causes the unittests to take so long? I find it hard to believe that they need to take as long as they do.

They have to be run for many different combinations of compiler flags iirc.
Dec 28 2011
parent reply Don <nospam nospam.com> writes:
On 28.12.2011 13:14, Timon Gehr wrote:
 On 12/28/2011 10:53 AM, Peter Alexander wrote:
 On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:
 On 12/27/11 2:38 PM, Walter Bright wrote:
 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
 One good realization to make is how less efficient that makes you. You
 got used
 to that overhead so plentily, you consider it now par for the course.

What takes time is running the unittests, not compiling dmd.

Then _that_ is what you consider par for the course! :o) Andrei

Has anyone looked into what causes the unittests to take so long? I find it hard to believe that they need to take as long as they do.

They have to be run for many different combinations of compiler flags iirc.

(no flags) -O -release -inline -g -O -release -inline But why do the Phobos unit tests take so long? They used to take a matter of seconds, now they take forever. On D1, they still take only about 10 seconds. On D2 they are now longer than the compiler tests with the minimal flag options.
Dec 29 2011
parent Don <nospam nospam.com> writes:
On 31.12.2011 15:55, Marco Leise wrote:
 Am 29.12.2011, 09:16 Uhr, schrieb Don <nospam nospam.com>:

 On 28.12.2011 13:14, Timon Gehr wrote:
 On 12/28/2011 10:53 AM, Peter Alexander wrote:
 On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:
 On 12/27/11 2:38 PM, Walter Bright wrote:
 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
 One good realization to make is how less efficient that makes
 you. You
 got used
 to that overhead so plentily, you consider it now par for the
 course.

What takes time is running the unittests, not compiling dmd.

Then _that_ is what you consider par for the course! :o) Andrei

Has anyone looked into what causes the unittests to take so long? I find it hard to believe that they need to take as long as they do.

They have to be run for many different combinations of compiler flags iirc.

(no flags) -O -release -inline -g -O -release -inline But why do the Phobos unit tests take so long? They used to take a matter of seconds, now they take forever. On D1, they still take only about 10 seconds. On D2 they are now longer than the compiler tests with the minimal flag options.

2.055 hat problems with -O -release -inline -noboundscheck (three of those anyway, including noboundscheck)

Ah, yes. -release used to include -noboundscheck. Thanks. The list should be (no flags) -O -release -inline -noboundscheck -g -O -release -inline -noboundscheck
Jan 01 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
On Tuesday, 27 December 2011 at 16:33:30 UTC, Andrei Alexandrescu 
wrote:
 On 12/27/11 9:51 AM, Torarin wrote:
 2011/12/27 Joshua Reusch<yoschi arkandos.de>:
 $ ./dmd lambda_test
 dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == 
 (((mbinptr) (((char *)
 &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct 
 malloc_chunk,
 fd))))&&  old_size == 0) || ((unsigned long) (old_size)>= 
 (unsigned
 long)((((__builtin_offsetof (struct malloc_chunk, 
 fd_nextsize))+((2 *
 (sizeof(size_t))) - 1))&  ~((2 * (sizeof(size_t))) - 1)))&&
 ((old_top)->size&  0x1)&&  ((unsigned long)old_end&  
 pagemask) == 0)'
 failed.

Did you do a clean before compiling? I forgot, and got the same error.

I confirm the new syntax works after a rebase and clean rebuild.

I've always wondered how dmd manages to do that. It's well known that dmd gives you a nut kick if you try to compile D code incrementally. But even the dmd source itself has to be rebuilt every time if you don't want strange errors and that's C++. I don't even know if it's a laughing matter or not.
Dec 27 2011
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 29.12.2011, 09:16 Uhr, schrieb Don <nospam nospam.com>:

 On 28.12.2011 13:14, Timon Gehr wrote:
 On 12/28/2011 10:53 AM, Peter Alexander wrote:
 On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:
 On 12/27/11 2:38 PM, Walter Bright wrote:
 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
 One good realization to make is how less efficient that makes you.  
 You
 got used
 to that overhead so plentily, you consider it now par for the  
 course.

What takes time is running the unittests, not compiling dmd.

Then _that_ is what you consider par for the course! :o) Andrei

Has anyone looked into what causes the unittests to take so long? I find it hard to believe that they need to take as long as they do.

They have to be run for many different combinations of compiler flags iirc.

(no flags) -O -release -inline -g -O -release -inline But why do the Phobos unit tests take so long? They used to take a matter of seconds, now they take forever. On D1, they still take only about 10 seconds. On D2 they are now longer than the compiler tests with the minimal flag options.

2.055 hat problems with -O -release -inline -noboundscheck (three of those anyway, including noboundscheck)
Dec 31 2011
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2011/12/27 Joshua Reusch <yoschi arkandos.de>:
 Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155=


 Andrei

------------- import std.algorithm; void main() { =A0 =A0 =A0 =A0auto arr =3D [0, 5, 4, 3, 2, 1]; =A0 =A0 =A0 =A0sort!((a, b) =3D> a < b)(arr); } ------------- $ ./dmd lambda_test dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top =3D=3D (((mbinptr) (((=

 &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk,
 fd)))) && old_size =3D=3D 0) || ((unsigned long) (old_size) >=3D (unsigne=

 long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
 (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) &&
 ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) =3D=3D 0)'
 failed.
 $


 This also "works" with other functions from std.algorithm.

Did you do a clean before compiling? I forgot, and got the same error. Torarin
Dec 27 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-27 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei

Now that's very cool. Does it work for non-template arguments as well. -- /Jacob Carlborg
Dec 27 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 21:32, Jacob Carlborg wrote:
 On 2011-12-27 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei

Now that's very cool. Does it work for non-template arguments as well.

Nope. When passing such lambdas as regular arguments, there's no inference. - Alex
Dec 27 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:
 On 27-12-2011 21:32, Jacob Carlborg wrote:
 On 2011-12-27 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc




 Andrei

Now that's very cool. Does it work for non-template arguments as well.

Nope. When passing such lambdas as regular arguments, there's no inference. - Alex

... yet. http://d.puremagic.com/issues/show_bug.cgi?id=6714 Anyway, his question seemed to be about whether or not the '=>' syntax can be used for ordinary delegate literals, which it can: (int x) => x
Dec 27 2011
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 23:18, Timon Gehr wrote:
 On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:
 On 27-12-2011 21:32, Jacob Carlborg wrote:
 On 2011-12-27 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc





 Andrei

Now that's very cool. Does it work for non-template arguments as well.

Nope. When passing such lambdas as regular arguments, there's no inference. - Alex

... yet. http://d.puremagic.com/issues/show_bug.cgi?id=6714 Anyway, his question seemed to be about whether or not the '=>' syntax can be used for ordinary delegate literals, which it can: (int x) => x

That bug needs very high priority. - Alex
Dec 27 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-27 23:18, Timon Gehr wrote:
 On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:
 On 27-12-2011 21:32, Jacob Carlborg wrote:
 On 2011-12-27 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc





 Andrei

Now that's very cool. Does it work for non-template arguments as well.

Nope. When passing such lambdas as regular arguments, there's no inference. - Alex

... yet. http://d.puremagic.com/issues/show_bug.cgi?id=6714 Anyway, his question seemed to be about whether or not the '=>' syntax can be used for ordinary delegate literals, which it can: (int x) => x

Yes, exactly. Thanks. -- /Jacob Carlborg
Dec 28 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-27 22:53, Alex Rønne Petersen wrote:
 On 27-12-2011 21:32, Jacob Carlborg wrote:
 On 2011-12-27 05:25, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc




 Andrei

Now that's very cool. Does it work for non-template arguments as well.

Nope. When passing such lambdas as regular arguments, there's no inference. - Alex

Yeah, but does the new syntax work: void foo (int delegate (int) dg); foo((int a) => 3); -- /Jacob Carlborg
Dec 28 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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()); }
Dec 27 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/27/2011 11:27 PM, 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()); }

Also, => expr should imo be a shorthand for () => expr. It saves some ((())(()))().
Dec 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr: 

 => expr
 
 should imo be a shorthand for
 
 () => expr.
 
 It saves some ((())(()))().

It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea. On the other hand I think extending the applicability of this syntax to free functions/methods (as in Scala and Ada2012) is a nice idea, to shorten tiny functions/methods, that are common enough: class C { private int x; int getX() => x; } ------------------------ Walter:
They expect to see it, or else they mark D as "not having lambdas" and "not
supporting functional programming".<

To me this sounds like a bit silly argument to base language design on. In my opinion the most important reason for the introduction of this anonymous function syntax is that it makes D functional-style code (and generally code that uses lot of callbacks) less noisy, so it makes it more easy to write and read. Bye, bearophile
Dec 28 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-28 13:54, bearophile wrote:
 Timon Gehr:

 =>  expr

 should imo be a shorthand for

 () =>  expr.

 It saves some ((())(()))().

It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea.

It can already be done with the lazy arguments. void foo (lazy int a) { auto b = a(); } int bar (); foo(bar()); -- /Jacob Carlborg
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 05:59 PM, Jacob Carlborg wrote:
 On 2011-12-28 13:54, bearophile wrote:
 Timon Gehr:

 => expr

 should imo be a shorthand for

 () => expr.

 It saves some ((())(()))().

It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea.

It can already be done with the lazy arguments. void foo (lazy int a) { auto b = a(); } int bar (); foo(bar());

It is not the same thing. lazy arguments do not create a closure.
Dec 28 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 18:54, Timon Gehr wrote:
 On 12/28/2011 05:59 PM, Jacob Carlborg wrote:
 On 2011-12-28 13:54, bearophile wrote:
 Timon Gehr:

 => expr

 should imo be a shorthand for

 () => expr.

 It saves some ((())(()))().

It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea.

It can already be done with the lazy arguments. void foo (lazy int a) { auto b = a(); } int bar (); foo(bar());

It is not the same thing. lazy arguments do not create a closure.

Didn't thought of that. -- /Jacob Carlborg
Dec 28 2011
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/12/2011 13:54, bearophile a écrit :
 Timon Gehr:

 =>  expr

 should imo be a shorthand for

 () =>  expr.

 It saves some ((())(()))().

It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea. On the other hand I think extending the applicability of this syntax to free functions/methods (as in Scala and Ada2012) is a nice idea, to shorten tiny functions/methods, that are common enough: class C { private int x; int getX() => x; }

That would be great ! Uniformity is something we should look for.
 ------------------------

 Walter:

 They expect to see it, or else they mark D as "not having lambdas" and "not
supporting functional programming".<

To me this sounds like a bit silly argument to base language design on. In my opinion the most important reason for the introduction of this anonymous function syntax is that it makes D functional-style code (and generally code that uses lot of callbacks) less noisy, so it makes it more easy to write and read. Bye, bearophile

Both argument are fallacy. Javascript is a successful language (even if some design decisions are arguably very bad). It use a lot of callback, and promote event drivent programming so this type of consrtruct is used everywhere. In addition, in Javascript, code source size matters. The syntax to do such a thing is more verbose in javascript. So definitively, this is a nice syntax, but this isn't that ground breaking, and this isn't even required for people to use this type of constructs.
Dec 28 2011
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On 12/28/2011 07:15 PM, deadalnix wrote:

 The syntax to do such a thing is more verbose in javascript. So
 definitively, this is a nice syntax, but this isn't that ground
 breaking, and this isn't even required for people to use this type of
 constructs.

People keep complaining about the verbosity of function syntax in JavaScript. There has been several attempts to fix that. One prominent example is CoffeeScript.
Dec 28 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 18:15, deadalnix wrote:
 Le 28/12/2011 13:54, bearophile a écrit :
 Timon Gehr:

 => expr

 should imo be a shorthand for

 () => expr.

 It saves some ((())(()))().

It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea. On the other hand I think extending the applicability of this syntax to free functions/methods (as in Scala and Ada2012) is a nice idea, to shorten tiny functions/methods, that are common enough: class C { private int x; int getX() => x; }

That would be great ! Uniformity is something we should look for.
 ------------------------

 Walter:

 They expect to see it, or else they mark D as "not having lambdas"
 and "not supporting functional programming".<

To me this sounds like a bit silly argument to base language design on. In my opinion the most important reason for the introduction of this anonymous function syntax is that it makes D functional-style code (and generally code that uses lot of callbacks) less noisy, so it makes it more easy to write and read. Bye, bearophile

Both argument are fallacy. Javascript is a successful language (even if some design decisions are arguably very bad). It use a lot of callback, and promote event drivent programming so this type of consrtruct is used everywhere. In addition, in Javascript, code source size matters. The syntax to do such a thing is more verbose in javascript. So definitively, this is a nice syntax, but this isn't that ground breaking, and this isn't even required for people to use this type of constructs.

I use CoffeeScript (which compiles to JavaScript) and it has a lot nice lambda syntax. foo = (arg) -> arg() foo -> # lambda code here -- /Jacob Carlborg
Dec 28 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 18:15, deadalnix wrote:
 Le 28/12/2011 13:54, bearophile a écrit :
 Timon Gehr:

 => expr

 should imo be a shorthand for

 () => expr.

 It saves some ((())(()))().

It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea. On the other hand I think extending the applicability of this syntax to free functions/methods (as in Scala and Ada2012) is a nice idea, to shorten tiny functions/methods, that are common enough: class C { private int x; int getX() => x; }

That would be great ! Uniformity is something we should look for.
 ------------------------

 Walter:

 They expect to see it, or else they mark D as "not having lambdas"
 and "not supporting functional programming".<

To me this sounds like a bit silly argument to base language design on. In my opinion the most important reason for the introduction of this anonymous function syntax is that it makes D functional-style code (and generally code that uses lot of callbacks) less noisy, so it makes it more easy to write and read. Bye, bearophile

Both argument are fallacy. Javascript is a successful language (even if some design decisions are arguably very bad). It use a lot of callback, and promote event drivent programming so this type of consrtruct is used everywhere. In addition, in Javascript, code source size matters. The syntax to do such a thing is more verbose in javascript. So definitively, this is a nice syntax, but this isn't that ground breaking, and this isn't even required for people to use this type of constructs.

I use CoffeeScript (which compiles to JavaScript) and it has a lot nicer lambda syntax. foo = (arg) -> arg() foo -> # lambda code here -- /Jacob Carlborg
Dec 28 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
deadalnix:

 bearophile:
 In my opinion the most important reason for the introduction of
 this anonymous function syntax is that it makes D functional-style
 code (and generally code that uses lot of callbacks) less noisy,
 so it makes it more easy to write and read.


 Both argument are fallacy. Javascript is a successful language (even if
 some design decisions are arguably very bad). It use a lot of callback,
 and promote event drivent programming so this type of consrtruct is used
 everywhere. In addition, in Javascript, code source size matters.
 
 The syntax to do such a thing is more verbose in javascript. So
 definitively, this is a nice syntax, but this isn't that ground
 breaking, and this isn't even required for people to use this type of
 constructs.

Javascript is successful mostly for being the only language available on a very important platform, not for its many qualities and features. D lacks a killer app still, and it exists in an already mature ecosytem dominated by other languages like C++. So it has to compete on different grounds of quality. I agree the new short lambda syntax is not necessary, but it's good to have. I have written a good amount of functional-style code in D2 (while I have not written a significant amount of functional-style code in Javascript), I have written some code in OCaML and Haskell, and I have seen that the amount of parentheses and brackets in such D code make it not easy to write and read for me, compared to equivalent code in more functional languages. So you need to try harder if you want to change my mind :-) Bye, bearophile
Dec 28 2011
parent reply Max Samukha <maxsamukha gmail.com> writes:
On 12/29/2011 01:49 AM, Adam D. Ruppe wrote:
 On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
 (while I have not written a significant amount of functional-style
 code in Javascript)

It looks fine if you use named functions or a little whitespace around the literals (same as D!).

I had been a stupidly staunch defender of braces/semicolons before I actually tried the languages with significant indentation. Since then, I find C-like syntaxes not so attractive, to say the least. It takes a while to fall out of the bad habit typing all that punctuation but the result is rewarding. Comparing CoffeeScript and the equivalent JavaScript code at http://jashkenas.github.com/coffee-script/, it is obvious that JavaScript is unnecessarily noisy.
Dec 29 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-29 10:07, Max Samukha wrote:
 On 12/29/2011 01:49 AM, Adam D. Ruppe wrote:
 On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
 (while I have not written a significant amount of functional-style
 code in Javascript)

It looks fine if you use named functions or a little whitespace around the literals (same as D!).

I had been a stupidly staunch defender of braces/semicolons before I actually tried the languages with significant indentation. Since then, I find C-like syntaxes not so attractive, to say the least. It takes a while to fall out of the bad habit typing all that punctuation but the result is rewarding. Comparing CoffeeScript and the equivalent JavaScript code at http://jashkenas.github.com/coffee-script/, it is obvious that JavaScript is unnecessarily noisy.

I completely agree. CoffeeScript is a really nice language. Except for the nicer syntax it's also really nice to have proper class based object model (or at least as proper it can be since it's compiled to a prototype model). -- /Jacob Carlborg
Dec 29 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:

 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());
 }

From the Ada 2012 changes: http://www.disca.upv.es/jorge/ae2010/slides/05-3_Language_Tech_Schonberg_Towards_Ada_2012.pdf
 To simplify the writing of pre/postconditions and predicates, allow
parametrized expressions (aka function bodies in package specs):

function Cube (X : integer) is (X ** 3); Bye, bearophile
Dec 27 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
Dec 28 2011
parent reply Don <nospam nospam.com> writes:
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 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. 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.
Dec 29 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-29 10:19, 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 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. 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.

When you're implementing a lot of properties that basically just forwards to the instance variables it can be really useful. -- /Jacob Carlborg
Dec 29 2011
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-12-2011 14:07, Jacob Carlborg wrote:
 On 2011-12-29 10:19, 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 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. 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.

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

+1. - Alex
Dec 29 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-12-2011 14:10, Alex Rønne Petersen wrote:
 On 29-12-2011 14:07, Jacob Carlborg wrote:
 On 2011-12-29 10:19, 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 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. 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.

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

+1. - Alex

It would be hard to specify in/out for such properties though, with the => syntax (this is something I do often). - Alex
Dec 29 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Dec 29 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Dec 29 2011
parent reply Don <nospam nospam.com> writes:
On 30.12.2011 01:13, Timon Gehr wrote:
 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.

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

That just makes it look even more like Perl. The return statement is not the problem.
 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.

That's my point. The BEST CASE is that you save 6 characters, on something which was already easy to read. I don't think it buys you anything in readability. Really, nothing at all.
Dec 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/31/2011 12:51 PM, Don wrote:
 On 2011-12-27 23:27, Timon Gehr wrote:
 In case the function is used for code generation, it can get
 rid of one level of indentation.
 string generate(string x) => mixin(X!q{
  (x) = 2;
 });

That just makes it look even more like Perl. The return statement is not the problem.

The indentation is the problem. If you don't like (x) = 2; then that is an unrelated issue.
 My intention is that it would be used with short expressions. Such
 monster expressions as in your example are rare in real world code.


On the contrary. The longer the expression, the less it buys you in readability/the less typing it saves.
 The BEST CASE is that you save 6 characters, on

This is the worst case, if it is applicable. The best case is saving an unbounded amount of characters.
 something which was already easy to read. I don't think it buys you
 anything in readability. Really, nothing at all.

Those 6 characters are probably the majority of the characters in the function body. It saves you more than 6 characters. It saves you 6 characters _every time_. For 10 short functions, it saves 60 characters. For 100 short functions, it saves 600 characters, etc. We should probably stop that discussion soon, because there is no objective readability measure and therefore it is unlikely that one of us will change his opinion. Anyway, it certainly improves language uniformity. Is there any case to be made against generalizing => ?
Dec 31 2011
parent reply Don <nospam nospam.com> writes:
On 31.12.2011 16:58, Timon Gehr wrote:
 On 12/31/2011 12:51 PM, Don wrote:
 On 2011-12-27 23:27, Timon Gehr wrote:
 In case the function is used for code generation, it can get
 rid of one level of indentation.
 string generate(string x) => mixin(X!q{
  (x) = 2;
 });

That just makes it look even more like Perl. The return statement is not the problem.

The indentation is the problem. If you don't like (x) = 2; then that is an unrelated issue.

It's related. That example is polishing a turd. BTW the bit I don't like isn't the (x) -- that's the best bit! It's the "mixin(", the "q{", and the "})".
 My intention is that it would be used with short expressions. Such
 monster expressions as in your example are rare in real world code.


On the contrary. The longer the expression, the less it buys you in readability/the less typing it saves.
 The BEST CASE is that you save 6 characters, on

This is the worst case, if it is applicable. The best case is saving an unbounded amount of characters.

How ??? Each instance of => saves you 6 characters, right?
 We should probably stop that discussion soon, because there is no
 objective readability measure and therefore it is unlikely that one of
 us will change his opinion.

Before the introduction of =>, I never heard anyone mention about the "problem" you're fixing. It seems to be a solution in search of problem. You can objectively search the newsgroup.
 Anyway, it certainly improves language uniformity. Is there any case to
 be made against generalizing => ?

Yeah. (1) *Everything* comes at a cost. It needs to provide a genuine benefit. More importantly: (2) I do not agree at all that it improves language uniformity. The fact that you have to provide a name when declaring a function means it's not the same situation at all. A function literal is an expression. A function is a declaration. The contexts when you use them are completely different. And the grammer is different. It means almost-identical function definitions have completely different syntax. This reduces uniformity, and reduces readability.
Jan 01 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/01/2012 04:39 PM, Don wrote:
 On 31.12.2011 16:58, Timon Gehr wrote:
 On 12/31/2011 12:51 PM, Don wrote:
 On 2011-12-27 23:27, Timon Gehr wrote:
 In case the function is used for code generation, it can get
 rid of one level of indentation.
 string generate(string x) => mixin(X!q{
  (x) = 2;
 });

That just makes it look even more like Perl. The return statement is not the problem.

The indentation is the problem. If you don't like (x) = 2; then that is an unrelated issue.

It's related. That example is polishing a turd.

I disagree.
 BTW the bit I don't like isn't the  (x) -- that's the best bit! It's the
 "mixin(", the "q{", and the "})".

That does not commonly appear in Perl code ;). Anyway, your argument against => is that you don't like creative use of the language to be supported?
 My intention is that it would be used with short expressions. Such
 monster expressions as in your example are rare in real world code.


On the contrary. The longer the expression, the less it buys you in readability/the less typing it saves.
 The BEST CASE is that you save 6 characters, on

This is the worst case, if it is applicable. The best case is saving an unbounded amount of characters.

How ??? Each instance of => saves you 6 characters, right?

auto x() => q{ // 1st line // 2nd line // 3rd line // ... // nth line };
 We should probably stop that discussion soon, because there is no
 objective readability measure and therefore it is unlikely that one of
 us will change his opinion.

Before the introduction of =>, I never heard anyone mention about the "problem" you're fixing.

There does not need to be a problem to perform further improvements. Before the introduction of => there also was no precedent of being able to replace {return exp;} by => exp in the language.
 It seems to be a solution in search of problem.
 You can objectively search the newsgroup.

Before the introduction of =>, there was no uniformity problem. I am sure this will be brought up again at some point in the future.
 Anyway, it certainly improves language uniformity. Is there any case to
 be made against generalizing => ?

Yeah. (1) *Everything* comes at a cost. It needs to provide a genuine benefit.

It requires some trivial parser changes. And I think it does provide a genuine benefit.
 More importantly:
 (2) I do not agree at all that it improves language uniformity. The fact
 that you have to provide a name when declaring a function means it's not
 the same situation at all.
 A function literal is an expression. A function is a declaration.

A function literal is the conflation of a function declaration and a symbol lookup. It is both a declaration and an expression.
 The contexts when you use them are completely different.

No. Every function literal can be replaced by a function definition and a symbol lookup. And every function definition can be replaced by a function literal.
 And the grammer is different.

That is the point. The grammar should be the same, as it was before the introduction of =>. (int x){return x&1;} (int x) => x&1; int foo(int x){return x&1;} int foo(int x) => x&1;
 It means almost-identical function definitions have completely different
 syntax. This reduces uniformity, and reduces readability.

The same argument could be made against introducing => delegate syntax. I don't think it is a valid point.
Jan 01 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
 (while I have not written a significant amount of 
 functional-style code in Javascript)

It looks fine if you use named functions or a little whitespace around the literals (same as D!).
Dec 28 2011
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Dec 29 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:
 I can understand how Jonathan has no problem writing verbose code, but
 I'd rather not have to write enums all over the place just to use a
 true/false flag that is obvious at the call site compared to calls
 like this:
 
 showWidget(true, false);

I'm not a big fan of the enum's for true/false either. I have no problem whatsoever with the above line of code. I'd much rather have that than named arguments. The primary reason that I really don't like named arguments is the fact that the names of the parameters become part of the API. I also don't think that they add much unless you have functions with way too many parameters, and those sorts of functions shouldn't be happening anyway. And I don't like the additional complication of the possibility of reordering functiion arguments. You should be able to look at a function and know which parameters its arguments go with purely by the order, which named arguments destroy. But all of that has been discussed at length before. I'm completely opposed to the idea, but I seem to be in the minority (at least out of those who spoke up). - Jonathan M Davis
Dec 28 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 The primary reason that I really don't like named arguments is the fact that
 the names of the parameters become part of the API.

Sometimes I don't mind to make the names part of the API. And as you remember we have suggested an idea adapted from Scala. void foo(int x) {} void main() { foo(x: 5); } A deprecated() gives some transition time to change the API: void foo(int xx deprecated(x)) {} void main() { foo(x: 5); // deprecated 'x' warning foo(xx: 5); }
 I also don't think that
 they add much unless you have functions with way too many parameters, and
 those sorts of functions shouldn't be happening anyway.

I'd like to use names even for functions with 3 arguments. And named arguments offer you more flexibility in using functions. As example look at Python built-in sorted (that performs a schwartz sort on a copy of the input sequence), that has two optional arguments, using them with their name is the idiomatic way in Python because you are able to use only one of them at a time:
 a = [1, 5, -3, 9, -2]
 sorted(a)



 sorted(a, key=abs)



 sorted(a, reverse=True)



-------------------------
 I'd hate to have a function like
 
 void func(float x, float y);
 
 where calling it
 
 func(1.0, 2.0);
 
 and
 
 func(y : 1.0, x : 2.0);
 
 don't do the same thing. All of a sudden, I have to pay attention to what
 names the arguments were given. I can't just read the function call like I
 would now. It becomes error-prone in that regard and violates the current
 expectations of argument order. It will make code harder to read for minimal
 benefit IMHO. I do _not_ think that name arguments are an improvement.

Expectations change and adapt to the language and you will read the function calls in a different way, taking a look at the argument order too. In many cases names are not present at the call point, so you don't need to take care of this. If the names are present at the call point you take a look at the order. The name of the arguments keep the code readable. Regarding the "error-prone" nature of named arguments, I think you are wrong, in Ada named arguments are regarded as means to reduce possible bugs, because they avoid you to assign arguments "blindly" as now. In Python I like to know what argument I am assigning an argument to, this avoids some mistakes at the call point.
 If the
 example above were possible, then someone would use it in their code (even if
 I didn't), and I'd have to deal with all of the code readibility issues that
 it causes. Named arguments _would_ hurt the language even if they were purely
 optional.

Right, if language features like this are present they can't be really "optional", you find them in code written by other people. But named argument make code _more_ readable, because they tell you what arguments you are assigning to. Bye, bearophile
Dec 28 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
 I also don't think that they add much unless you have functions with way
 too many parameters, and those sorts of functions shouldn't be
 happening anyway. And I don't like the additional complication of the
 possibility of reordering functiion arguments. You should be able to
 look at a function and know which parameters its arguments go with
 purely by the order, which named arguments destroy.


I'd hate to have a function like void func(float x, float y); where calling it func(1.0, 2.0); and func(y : 1.0, x : 2.0); don't do the same thing. All of a sudden, I have to pay attention to what names the arguments were given. I can't just read the function call like I would now. It becomes error-prone in that regard and violates the current expectations of argument order. It will make code harder to read for minimal benefit IMHO. I do _not_ think that name arguments are an improvement.
 But all of that has been discussed at length before. I'm completely
 opposed to the idea, but I seem to be in the minority (at least out of
 those who spoke up).
 
 - Jonathan M Davis

I don't need named arguments either, but I don't think they would hurt if implemented as a purely optional feature.

Since they affect the API, they _do_ hurt. Since then any changes to parameter names break code. So, it has a definite affect on code maintainibility even if I don't use the feature myself. I also don't want to see them in code. If the example above were possible, then someone would use it in their code (even if I didn't), and I'd have to deal with all of the code readibility issues that it causes. Named arguments _would_ hurt the language even if they were purely optional. - Jonathan M Davis
Dec 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Wed, 28 Dec 2011 22:57:32 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 I'd hate to have a function like

 void func(float x, float y);

 where calling it

 func(1.0, 2.0);

 and

 func(y : 1.0, x : 2.0);

 don't do the same thing. All of a sudden, I have to pay attention to what
 names the arguments were given. I can't just read the function call like  
 I
 would now. It becomes error-prone in that regard and violates the current
 expectations of argument order. It will make code harder to read for  
 minimal
 benefit IMHO. I do _not_ think that name arguments are an improvement.

Are you aware all the points you made support the need for named arguments rather than what you were trying to achieve? Named parameter fixed a bug in your code and you are trying to explain how crap a feature is NP? :) If you are "trying" to read a function call when it uses named parameters, its not the fault of the feature but its implementation in given language. For this reason i kept saying we shouldn't inherit it from other languages but keep it simple. The feature supposed to ease the reading of a function call and enforce some guarantees.
 But all of that has been discussed at length before. I'm completely
 opposed to the idea, but I seem to be in the minority (at least out of
 those who spoke up).

 - Jonathan M Davis

I don't need named arguments either, but I don't think they would hurt if implemented as a purely optional feature.

Since they affect the API, they _do_ hurt. Since then any changes to parameter names break code. So, it has a definite affect on code maintainibility even if I don't use the feature myself. I also don't want to see them in code. If the example above were possible, then someone would use it in their code (even if I didn't), and I'd have to deal with all of the code readibility issues that it causes. Named arguments _would_ hurt the language even if they were purely optional.

It doesn't create readability issues, it is there to solve them. Maintainability issues? How? If you change "anything" in your interface, it is already a breaking change.
Dec 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 12/28/2011 11:34 PM, so wrote:
 If you change "anything" in your interface, it is already a breaking
 change.

That is why it is desirable to not let parameter names contribute to the interface. Jonathan definitely has a point against making all parameters named parameters by default.

/// A.d void fun1(int Arg); void fun2(int x); /// B.d void fun1(int arg); void fun2(int y); I am having hard time understanding the issue really. Now as a user i don't know why the library dev. changed the interface: /// without NP fun1(arg); // recompile no edit, fun2(x); // well You are saying like changing a parameter name in lib code is always so harmless. You guys making your case on a dumb developer that goes for a breaking change just to fix a always harmless typo. Then, what makes you so sure he won't do this?
Dec 28 2011
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 28 December 2011 at 20:58:33 UTC, Jonathan M Davis 
wrote:
 Since they affect the API, they _do_ hurt

In my web.d, I support named and positional parameters for remote calls. I almost always use the positional parameters exactly because they are not affected by name changes in the server app. It's just so much easier to handle changes when the names don't matter. Though it might not be so bad in D since static checks can help. I remember one time this was discussed, it was suggested to allow the name if and only if the position is correct too. void foo(int a, int b); foo(a: 1, b: 0); // ok foo(A: 1, b: 0); // wrong name foo(b: 1, a: 0); // wrong names because position is swapped Though imo if you want that, you could always just use a comment.
Dec 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:

 The moment NP by default is introduced is the moment all parameter names  
 in all libraries are set in stone.

This is completely false. NP affects only those that "want" to use it, no one else. Again, no one. It is just like inline asm.
 Those names were mere implementation details prior to that point in time.
 Having parameter names contribute to the interface means that all  
 developers need to spend time thinking about the best possible names for  
 their function parameters.

 Then, what makes you so sure he won't do this?

What makes you so sure that if he does, he actually remembers to change the functionality too?

You are not making any sense here i am sorry. Read the examples. He doesn't need to remember, compiler does that for him but only for him :)
Dec 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Thu, 29 Dec 2011 01:58:46 +0200, so <so so.so> wrote:

 He doesn't need to remember, compiler does that for him but only for him  
 :)

As it turns out compiler don't give a damn about him either.
Dec 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 12/29/2011 12:58 AM, so wrote:
 On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch>  
 wrote:

 The moment NP by default is introduced is the moment all parameter
 names in all libraries are set in stone.

This is completely false. NP affects only those that "want" to use it, no one else. Again, no one. It is just like inline asm.

No, it is not. If all parameters are named parameters, then the library writers have to be aware of the fact that some users might use named arguments. Again, every library writer is affected.

Show me any library code from any language where library writer is not already "aware" their argument names define their function. They even document it that way. /// a does this, b does that void fun(int a, int b)
Dec 28 2011
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr gmx.ch> wrote:

 Having parameter names contribute to the interface means that all  
 developers need to spend time thinking about the best possible names for  
 their function parameters.

And that's a bad thing, right? Named parameters do have the issue that once released, it is can be costly to change the names. It therefore is important that library developers take enough time to consider parameter names, much in the same manner as they are currently consider existing exposed names. To assist those developers, a name deprecation facility could be introduced to alert users of pending removal of old names. This would of course only be of interest to those developers who choose to use named parameters in their code. There is a similar issue with positional parameters; once released, the library developer would be unwise to alter the order of parameters. But somehow, we have managed to educate ourselves so as to (mostly) avoid this problem. In general, I'd support optional named parameters and would encourage their usage in those situations where it makes source code more understandable to other readers. -- Derek Parnell Melbourne, Australia
Dec 28 2011
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
On Thu, 29 Dec 2011 12:02:28 +1100, so <so so.so> wrote:

 Show me any library code from any language where library writer is not  
 already "aware" their argument names define their function.

Supporting example: int find( T needle, T[] haystack) As a side effect, it might even help prevent the unnecessary use of one-character parameter names, LOL. -- Derek Parnell Melbourne, Australia
Dec 28 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Naming is much less error-prone, then positioning, because change in
position is much less obvious (especially for parameters of the same
type).
When you write a class or a function you also need to come up with a
name, but you don't think of it as being forced to think ahead.
You'll always need to think ahead no matter what you do. A
sufficiently easy named parameter mechanism can easily allow you to
deprecate names if necessary.
Moreover, disallowing positional parameters is absolutely not
necessary, because it would lead to ugly code:

sin(5)
sin(x : 5)

I think the best idea would be to allow both named and positional, but
disallow mixing them. That is, you can either pass all your parameters
by name or by position.

int[2] makeAPoint(int x, int y) { return [x, y]; }

unittest
{
    auto a0 = makeAPoint(5, 7); // valid
    auto a1 = makeAPoint(x : 5, y : 7); // valid
    auto a2 = makeAPoint(5, y : 7); // invalid
    auto a2 = makeAPoint(x : 5, 7); // invalid
}

I really don't see any benefits in allowing mixed calls. in those
cases you might as well encapsulate the parameters in a structure.

On Thu, Dec 29, 2011 at 12:08 PM, Don <nospam nospam.com> wrote:
 On 29.12.2011 04:48, David Nadlinger wrote:
 On 12/29/11 3:46 AM, Timon Gehr wrote:
 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right
 upfront.

My point is, without positional arguments you can improve the ordering at any time. With positional arguments, you are stuck and have to get it right upfront. David

That's rubbish! Unless you plan to disallow positional arguments...

-- Bye, Gor Gyolchanyan.
Dec 29 2011
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
On Thu, 29 Dec 2011 19:07:17 +1100, Don <nospam nospam.com> 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.

Were you forced to use named parameters or was it optional? -- Derek Parnell Melbourne, Australia
Dec 29 2011
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
On Thu, 29 Dec 2011 19:08:36 +1100, Don <nospam nospam.com> wrote:

 On 29.12.2011 04:48, David Nadlinger wrote:
 On 12/29/11 3:46 AM, Timon Gehr wrote:
 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right
 upfront.

My point is, without positional arguments you can improve the ordering at any time. With positional arguments, you are stuck and have to get it right upfront. David

That's rubbish! Unless you plan to disallow positional arguments...

Maybe you missed the point? I see the point in David's response as being that regardless of whether we have positional or named parameters, once exposed, they are pretty well set in concrete. I think that no one is suggesting that position parameters are to be replaced by named ones. The upshot of the idea would be that a API user would be free to choose between whatever *they* felt was appropriate. -- Derek Parnell Melbourne, Australia
Dec 29 2011
prev sibling next sibling parent so <so so.so> writes:
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.
Dec 29 2011
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
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.

'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
Dec 29 2011
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
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
Dec 29 2011
prev sibling parent so <so so.so> writes:
On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:

 I think: there are cases when named parameters are beneficial. There are  
 cases where they are detrimental.
 Is it possible to get the first, without the second, and without much  
 complexity?

If we keep rules simple as possible i think it is possible. For that we need our own rules i think, remembering all those rules suggested here i can understand why people have issues with them.
 (I'm thinking of something like, a colon before the parameter name means  
 the name is part of the API).

This i don't like, we shouldn't change anything on API side. All they need to know is that their parameter names (if they provid one) might be used in NPs. Otherwise it would complicate both implementation and usability.
Dec 30 2011