View mode: basic / threaded / horizontal-split · Log in · Help
December 28, 2011
Re: A nice way to step into 2012
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
December 28, 2011
Re: A nice way to step into 2012
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
December 28, 2011
Re: A nice way to step into 2012
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
December 28, 2011
Re: A nice way to step into 2012
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
December 28, 2011
Re: A nice way to step into 2012
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.
December 28, 2011
Re: A nice way to step into 2012
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.
December 28, 2011
Re: A nice way to step into 2012
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.
December 28, 2011
Re: A nice way to step into 2012
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
December 28, 2011
Re: A nice way to step into 2012
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.
December 28, 2011
Re: A nice way to step into 2012
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.
> Why would that be beneficial?

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
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home