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.

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

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 é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

I used it and I am not sure if it had draw backs, but looking at the code 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 adapted 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 language to me, if you know what I mean. It shows a nice capability of the language - 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 anything 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 for general use :D like saving on boilerplate code, multi-inheritance etc. It may seem odd, but I prefer a dozen language features over one string mixin 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 the specification can be checked in the IDE.

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

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.

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.

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

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

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

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