View mode: basic / threaded / horizontal-split · Log in · Help
August 07, 2012
Re: @property
On Mon, Aug 6, 2012 at 11:31 PM, Brad Anderson <eco@gnuk.net> wrote:
> On Mon, Aug 6, 2012 at 11:59 PM, José Armando García Sancio
> <jsancio@gmail.com> wrote:
>>
>> On Sun, Aug 5, 2012 at 2:32 PM, Kapps <opantm2+spam@gmail.com> wrote:
>> > On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
>> >>
>> >> On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
>> >>>
>> >>> I'd be very surprised if all that many people compile with -property.
>> >>
>> >>
>> >> Indeed. Sometimes I try it just to see what happens, and always the
>> >> same
>> >> results: it doesn't solve problems and complains about code.
>> >>
>> >> Some examples of things that break:
>> >>
>> >> import std.algorithm;
>> >> foreach(i; [1,2,3].map!"a+1") {
>> >>
>> >> }
>> >> prophate.d(5): Error: not a property [1,2,3].map!("a+1")
>> >>
>> >>
>> >> Of course, this is relatively new, using ufcs in 2.059, so the breakage
>> >> probably isn't too bad, but I'm not the only one who writes it this way
>> >> -
>> >> I've seen a number of reddit and newsgroup comments do this too,
>> >> especially
>> >> when chaining it.
>> >> [snip]
>> >
>> >
>> > I completely agree, particularl with the UFCS part. UFCS is designed to
>> > get
>> > rid of the horrible mess of (), and now we want to arbitrarily force a
>> > ()
>> > anyways? Seems like it defeats the purpose. To me, when comparing
>> > range.filter!"a > 2".map!"a*a".countUntil(3)
>> > to
>> > range.filter!"a > 2"().map!"a*a"().countUntil(3)
>> > Those extra paranthesis just don't do anything, they don't give extra
>> > meaning, they don't accomplish anything useful but distract from the
>> > actual
>> > expression.
>> >
>>
>> Just a small comment. I have been following this thread a little and
>> was somewhat surprise that the argument against enforcing parenthesis
>> on non-properties is that a call like [1,2,3].map!"a+1" would look
>> ugly as [1,2,3].map!"a+1"(). To me that is a issue of the
>> std.algorithm module and not so much of the language.
>>
>> Personally I am not a huge fan of using strings as a way to pass a
>> function into a high-order function. I suspect that this string stuff
>> became popular because D didn't have lambda declarations and type
>> inference when the module was designed and implemented. I wonder if
>> the module signatures would look different if you designed it to use
>> the current features of D.
>>
>> To be honest, when first saw 'some_array.map!"a+1"()' a few years back
>> when I first learned about D my knee jerk reaction was: "from where in
>> the world is 'a' coming from?". I remember I had to read
>> std/algorithm.d and whatever module implements unary "string"
>> functions to figure out what was going on. Anyways, I digress.
>>
>> Part of me looks forward to the day that I can use D reliably another
>> part of my wants to just wait for Rust to hopefully get it "right".
>>
>> Thanks,
>> -Jose
>
>
> There was a pull to switch std.algorithm over to the new lambda syntax (by
> me).  It caused the dmd unit tests to fail though.  There is also an issue
> with intermodule visibility of nested structs that popped up and prevented
> the every function from being switched over.  I should probably recreate the
> pull request so one of the compiler guys can take a look.
>
> BA

Wow. That would be nice! I would like to see such a change though I
assume that such a change would break a lot of code. No?
August 07, 2012
Re: @property
On Monday, August 06, 2012 23:44:21 José Armando García Sancio wrote:
> Wow. That would be nice! I would like to see such a change though I
> assume that such a change would break a lot of code. No?

No. Both the string syntax and the new lambda syntax are here to stay. Both 
work now, and both will continue to work. The pull request was switching over 
most of the examples, not changing the functionality.

- Jonathan M Davis
August 07, 2012
Re: @property
On Tuesday, 7 August 2012 at 06:31:46 UTC, Brad Anderson wrote:
> On Mon, Aug 6, 2012 at 11:59 PM, José Armando García Sancio <
> jsancio@gmail.com> wrote:
[snip]
>> Personally I am not a huge fan of using strings as a way to 
>> pass a
>> function into a high-order function. I suspect that this 
>> string stuff
>> became popular because D didn't have lambda declarations and 
>> type
>> inference when the module was designed and implemented. I 
>> wonder if
>> the module signatures would look different if you designed it 
>> to use
>> the current features of D.
>>
>> To be honest, when first saw 'some_array.map!"a+1"()' a few 
>> years back
>> when I first learned about D my knee jerk reaction was: "from 
>> where in
>> the world is 'a' coming from?". I remember I had to read
>> std/algorithm.d and whatever module implements unary "string"
>> functions to figure out what was going on. Anyways, I digress.
>>
>> Part of me looks forward to the day that I can use D reliably 
>> another
>> part of my wants to just wait for Rust to hopefully get it 
>> "right".
>>
>> Thanks,
>> -Jose
>>
>
> There was a pull to switch std.algorithm over to the new lambda 
> syntax (by
> me).  It caused the dmd unit tests to fail though.  There is 
> also an issue
> with intermodule visibility of nested structs that popped up 
> and prevented
> the every function from being switched over.  I should probably 
> recreate
> the pull request so one of the compiler guys can take a look.
>
> BA

https://github.com/D-Programming-Language/phobos/pull/744
August 07, 2012
Re: @property
On 08/07/2012 07:59 AM, José Armando García Sancio wrote:
> On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam@gmail.com>  wrote:
>> On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
>>>
>>> On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
>>>>
>>>> I'd be very surprised if all that many people compile with -property.
>>>
>>>
>>> Indeed. Sometimes I try it just to see what happens, and always the same
>>> results: it doesn't solve problems and complains about code.
>>>
>>> Some examples of things that break:
>>>
>>> import std.algorithm;
>>> foreach(i; [1,2,3].map!"a+1") {
>>>
>>> }
>>> prophate.d(5): Error: not a property [1,2,3].map!("a+1")
>>>
>>>
>>> Of course, this is relatively new, using ufcs in 2.059, so the breakage
>>> probably isn't too bad, but I'm not the only one who writes it this way -
>>> I've seen a number of reddit and newsgroup comments do this too, especially
>>> when chaining it.
>>> [snip]
>>
>>
>> I completely agree, particularl with the UFCS part. UFCS is designed to get
>> rid of the horrible mess of (), and now we want to arbitrarily force a ()
>> anyways? Seems like it defeats the purpose. To me, when comparing
>> range.filter!"a>  2".map!"a*a".countUntil(3)
>> to
>> range.filter!"a>  2"().map!"a*a"().countUntil(3)
>> Those extra paranthesis just don't do anything, they don't give extra
>> meaning, they don't accomplish anything useful but distract from the actual
>> expression.
>>
>
> Just a small comment. I have been following this thread a little and
> was somewhat surprise that the argument against enforcing parenthesis
> on non-properties is that a call like [1,2,3].map!"a+1" would look
> ugly as [1,2,3].map!"a+1"(). To me that is a issue of the
> std.algorithm module and not so much of the language.
>
> Personally I am not a huge fan of using strings as a way to pass a
> function into a high-order function. I suspect that this string stuff
> became popular because D didn't have lambda declarations and type
> inference when the module was designed and implemented.

String lambdas would quite certainly have been left out.
Anyway, string lambdas are unrelated to the discussion of std.algorithm
idioms in this context.

[1,2,3].map!(a=>a+1)

[1,2,3].map!(a=>a+1)()
August 07, 2012
Re: @property
On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr <timon.gehr@gmx.ch> wrote:
> On 08/07/2012 07:59 AM, José Armando García Sancio wrote:
>>
>> On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam@gmail.com>  wrote:
>>>
>>> On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
>>>>
>>>>
>>>> On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
>>>>>
>>>>>
>>>>> I'd be very surprised if all that many people compile with -property.
>>>>
>>>>
>>>>
>>>> Indeed. Sometimes I try it just to see what happens, and always the same
>>>> results: it doesn't solve problems and complains about code.
>>>>
>>>> Some examples of things that break:
>>>>
>>>> import std.algorithm;
>>>> foreach(i; [1,2,3].map!"a+1") {
>>>>
>>>> }
>>>> prophate.d(5): Error: not a property [1,2,3].map!("a+1")
>>>>
>>>>
>>>> Of course, this is relatively new, using ufcs in 2.059, so the breakage
>>>> probably isn't too bad, but I'm not the only one who writes it this way
>>>> -
>>>> I've seen a number of reddit and newsgroup comments do this too,
>>>> especially
>>>> when chaining it.
>>>> [snip]
>>>
>>>
>>>
>>> I completely agree, particularl with the UFCS part. UFCS is designed to
>>> get
>>> rid of the horrible mess of (), and now we want to arbitrarily force a ()
>>> anyways? Seems like it defeats the purpose. To me, when comparing
>>> range.filter!"a>  2".map!"a*a".countUntil(3)
>>> to
>>> range.filter!"a>  2"().map!"a*a"().countUntil(3)
>>> Those extra paranthesis just don't do anything, they don't give extra
>>> meaning, they don't accomplish anything useful but distract from the
>>> actual
>>> expression.
>>>
>>
>> Just a small comment. I have been following this thread a little and
>> was somewhat surprise that the argument against enforcing parenthesis
>> on non-properties is that a call like [1,2,3].map!"a+1" would look
>> ugly as [1,2,3].map!"a+1"(). To me that is a issue of the
>> std.algorithm module and not so much of the language.
>>
>>
>> Personally I am not a huge fan of using strings as a way to pass a
>> function into a high-order function. I suspect that this string stuff
>> became popular because D didn't have lambda declarations and type
>> inference when the module was designed and implemented.
>
>
> String lambdas would quite certainly have been left out.
> Anyway, string lambdas are unrelated to the discussion of std.algorithm
> idioms in this context.
>
> [1,2,3].map!(a=>a+1)
>
> [1,2,3].map!(a=>a+1)()

Yep. The "problem" is not string lambda but that the mapping function
is passed a template argument (which you need for string lambda to
work). I guess that this is nice because you can alias the template or
pass multiple lambdas (a little obscure but okay). If the lambda
function was passed as a runtime parameter and not a template
parameter can just do:

[1, 2, 3].map(a=>a+1)

If this was the case we wouldn't be talking about this non-property vs
property with regard to map. I other words the map signature could
look as follow (pseudo-code):

Range!T map(T, U)(Range!U range, T delegate(U));

Thanks,
-Jose
P.S. You can still alias the map using a closure that binds the
delegate but I digress.
August 07, 2012
Re: @property
On 2012-08-07 20:37, José Armando García Sancio wrote:

> Yep. The "problem" is not string lambda but that the mapping function
> is passed a template argument (which you need for string lambda to
> work). I guess that this is nice because you can alias the template or
> pass multiple lambdas (a little obscure but okay). If the lambda
> function was passed as a runtime parameter and not a template
> parameter can just do:
>
> [1, 2, 3].map(a=>a+1)

I'm not entirely sure but I think using an alias-parameter the delegate 
will be inlined. Delegates are in general not inlined.

-- 
/Jacob Carlborg
August 07, 2012
Re: @property
On 08/07/2012 08:37 PM, José Armando García Sancio wrote:
> On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>> On 08/07/2012 07:59 AM, José Armando García Sancio wrote:
>>>
>>> On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam@gmail.com>   wrote:
>>>>
>>>> On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
>>>>>
>>>>>
>>>>> On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
>>>>>>
>>>>>>
>>>>>> I'd be very surprised if all that many people compile with -property.
>>>>>
>>>>>
>>>>>
>>>>> Indeed. Sometimes I try it just to see what happens, and always the same
>>>>> results: it doesn't solve problems and complains about code.
>>>>>
>>>>> Some examples of things that break:
>>>>>
>>>>> import std.algorithm;
>>>>> foreach(i; [1,2,3].map!"a+1") {
>>>>>
>>>>> }
>>>>> prophate.d(5): Error: not a property [1,2,3].map!("a+1")
>>>>>
>>>>>
>>>>> Of course, this is relatively new, using ufcs in 2.059, so the breakage
>>>>> probably isn't too bad, but I'm not the only one who writes it this way
>>>>> -
>>>>> I've seen a number of reddit and newsgroup comments do this too,
>>>>> especially
>>>>> when chaining it.
>>>>> [snip]
>>>>
>>>>
>>>>
>>>> I completely agree, particularl with the UFCS part. UFCS is designed to
>>>> get
>>>> rid of the horrible mess of (), and now we want to arbitrarily force a ()
>>>> anyways? Seems like it defeats the purpose. To me, when comparing
>>>> range.filter!"a>   2".map!"a*a".countUntil(3)
>>>> to
>>>> range.filter!"a>   2"().map!"a*a"().countUntil(3)
>>>> Those extra paranthesis just don't do anything, they don't give extra
>>>> meaning, they don't accomplish anything useful but distract from the
>>>> actual
>>>> expression.
>>>>
>>>
>>> Just a small comment. I have been following this thread a little and
>>> was somewhat surprise that the argument against enforcing parenthesis
>>> on non-properties is that a call like [1,2,3].map!"a+1" would look
>>> ugly as [1,2,3].map!"a+1"(). To me that is a issue of the
>>> std.algorithm module and not so much of the language.
>>>
>>>
>>> Personally I am not a huge fan of using strings as a way to pass a
>>> function into a high-order function. I suspect that this string stuff
>>> became popular because D didn't have lambda declarations and type
>>> inference when the module was designed and implemented.
>>
>>
>> String lambdas would quite certainly have been left out.
>> Anyway, string lambdas are unrelated to the discussion of std.algorithm
>> idioms in this context.
>>
>> [1,2,3].map!(a=>a+1)
>>
>> [1,2,3].map!(a=>a+1)()
>
> Yep. The "problem" is not string lambda but that the mapping function
> is passed a template argument (which you need for string lambda to
> work).

It is also a matter of execution speed and GC pressure. None of the D
compilers is able to inline delegate parameters at least as well as
alias template parameters afaik.

Furthermore, only the current form can _guarantee_ that no hidden GC
allocations take place due to parameter passing to map.

> I guess that this is nice because you can alias the template or
> pass multiple lambdas (a little obscure but okay). If the lambda
> function was passed as a runtime parameter and not a template
> parameter can just do:
>
> [1, 2, 3].map(a=>a+1)
>

Well, no you cannot, because the current language would not be able to
deduce a type for 'a'.

> If this was the case we wouldn't be talking about this non-property vs
> property with regard to map.

We would be talking about improving IFTI to support cross-parameter
type deduction. (and maybe we would constantly be complaining about
poor GC performance.) Some programmers who use it now would presumably
avoid std.algorithm because of the poor predictability of performance.
August 07, 2012
Re: @property
On Tue, Aug 7, 2012 at 12:27 PM, Timon Gehr <timon.gehr@gmx.ch> wrote:
> On 08/07/2012 08:37 PM, José Armando García Sancio wrote:
>>
>> On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>>>
>>> On 08/07/2012 07:59 AM, José Armando García Sancio wrote:
>>>
>>>>
>>>> On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam@gmail.com>   wrote:
>>>>>
>>>>>
>>>>> On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'd be very surprised if all that many people compile with -property.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Indeed. Sometimes I try it just to see what happens, and always the
>>>>>> same
>>>>>> results: it doesn't solve problems and complains about code.
>>>>>>
>>>>>> Some examples of things that break:
>>>>>>
>>>>>> import std.algorithm;
>>>>>> foreach(i; [1,2,3].map!"a+1") {
>>>>>>
>>>>>> }
>>>>>> prophate.d(5): Error: not a property [1,2,3].map!("a+1")
>>>>>>
>>>>>>
>>>>>> Of course, this is relatively new, using ufcs in 2.059, so the
>>>>>> breakage
>>>>>> probably isn't too bad, but I'm not the only one who writes it this
>>>>>> way
>>>>>> -
>>>>>> I've seen a number of reddit and newsgroup comments do this too,
>>>>>> especially
>>>>>> when chaining it.
>>>>>> [snip]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I completely agree, particularl with the UFCS part. UFCS is designed to
>>>>> get
>>>>> rid of the horrible mess of (), and now we want to arbitrarily force a
>>>>> ()
>>>>> anyways? Seems like it defeats the purpose. To me, when comparing
>>>>> range.filter!"a>   2".map!"a*a".countUntil(3)
>>>>> to
>>>>> range.filter!"a>   2"().map!"a*a"().countUntil(3)
>>>>> Those extra paranthesis just don't do anything, they don't give extra
>>>>> meaning, they don't accomplish anything useful but distract from the
>>>>> actual
>>>>> expression.
>>>>>
>>>>
>>>> Just a small comment. I have been following this thread a little and
>>>> was somewhat surprise that the argument against enforcing parenthesis
>>>> on non-properties is that a call like [1,2,3].map!"a+1" would look
>>>> ugly as [1,2,3].map!"a+1"(). To me that is a issue of the
>>>> std.algorithm module and not so much of the language.
>>>>
>>>>
>>>> Personally I am not a huge fan of using strings as a way to pass a
>>>> function into a high-order function. I suspect that this string stuff
>>>> became popular because D didn't have lambda declarations and type
>>>> inference when the module was designed and implemented.
>>>
>>>
>>>
>>> String lambdas would quite certainly have been left out.
>>> Anyway, string lambdas are unrelated to the discussion of std.algorithm
>>> idioms in this context.
>>>
>>> [1,2,3].map!(a=>a+1)
>>>
>>> [1,2,3].map!(a=>a+1)()
>>
>>
>> Yep. The "problem" is not string lambda but that the mapping function
>> is passed a template argument (which you need for string lambda to
>> work).
>
>
> It is also a matter of execution speed and GC pressure. None of the D
> compilers is able to inline delegate parameters at least as well as
> alias template parameters afaik.
>
> Furthermore, only the current form can _guarantee_ that no hidden GC
> allocations take place due to parameter passing to map.
>

Interesting. I can't speak for the GC and allocation you mention since
I never tried to implement this myself but I should point out that C++
STL's algorithm "module" (transform, for_each, etc) works this way.
Having said that, if D can't infer the type of lambda parameters
(which I thought the current version of D could) and create a
function/delegate based on the body then this is a no go.

Thanks for you insight.
-Jose
August 07, 2012
Re: @property
On Tue, Aug 7, 2012 at 1:52 PM, José Armando García Sancio
<jsancio@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 12:27 PM, Timon Gehr <timon.gehr@gmx.ch> wrote:
>> On 08/07/2012 08:37 PM, José Armando García Sancio wrote:
>>>
>>> On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>>>>
>>>> On 08/07/2012 07:59 AM, José Armando García Sancio wrote:
>>>>
>>>>>
>>>>> On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam@gmail.com>   wrote:
>>>>>>
>>>>>>
>>>>>> On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
> Interesting. I can't speak for the GC and allocation you mention since
> I never tried to implement this myself but I should point out that C++
> STL's algorithm "module" (transform, for_each, etc) works this way.
> Having said that, if D can't infer the type of lambda parameters
> (which I thought the current version of D could) and create a
> function/delegate based on the body then this is a no go.
>
> Thanks for you insight.
> -Jose

Just incase it is not clear. I have zero interest in changing or
promoting that we change the signature of the std.algorithm module.
This is more of a selfish module design exercise on my part.

Thanks,
-Jose
August 07, 2012
Re: @property
On 08/07/2012 10:52 PM, José Armando García Sancio wrote:
> On Tue, Aug 7, 2012 at 12:27 PM, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>> On 08/07/2012 08:37 PM, José Armando García Sancio wrote:
>>>
>>> On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr<timon.gehr@gmx.ch>   wrote:
>>>>
>>>> On 08/07/2012 07:59 AM, José Armando García Sancio wrote:
>>>>
>>>>>
>>>>> On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam@gmail.com>    wrote:
>>>>>>
>>>>>>
>>>>>> On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'd be very surprised if all that many people compile with -property.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Indeed. Sometimes I try it just to see what happens, and always the
>>>>>>> same
>>>>>>> results: it doesn't solve problems and complains about code.
>>>>>>>
>>>>>>> Some examples of things that break:
>>>>>>>
>>>>>>> import std.algorithm;
>>>>>>> foreach(i; [1,2,3].map!"a+1") {
>>>>>>>
>>>>>>> }
>>>>>>> prophate.d(5): Error: not a property [1,2,3].map!("a+1")
>>>>>>>
>>>>>>>
>>>>>>> Of course, this is relatively new, using ufcs in 2.059, so the
>>>>>>> breakage
>>>>>>> probably isn't too bad, but I'm not the only one who writes it this
>>>>>>> way
>>>>>>> -
>>>>>>> I've seen a number of reddit and newsgroup comments do this too,
>>>>>>> especially
>>>>>>> when chaining it.
>>>>>>> [snip]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I completely agree, particularl with the UFCS part. UFCS is designed to
>>>>>> get
>>>>>> rid of the horrible mess of (), and now we want to arbitrarily force a
>>>>>> ()
>>>>>> anyways? Seems like it defeats the purpose. To me, when comparing
>>>>>> range.filter!"a>    2".map!"a*a".countUntil(3)
>>>>>> to
>>>>>> range.filter!"a>    2"().map!"a*a"().countUntil(3)
>>>>>> Those extra paranthesis just don't do anything, they don't give extra
>>>>>> meaning, they don't accomplish anything useful but distract from the
>>>>>> actual
>>>>>> expression.
>>>>>>
>>>>>
>>>>> Just a small comment. I have been following this thread a little and
>>>>> was somewhat surprise that the argument against enforcing parenthesis
>>>>> on non-properties is that a call like [1,2,3].map!"a+1" would look
>>>>> ugly as [1,2,3].map!"a+1"(). To me that is a issue of the
>>>>> std.algorithm module and not so much of the language.
>>>>>
>>>>>
>>>>> Personally I am not a huge fan of using strings as a way to pass a
>>>>> function into a high-order function. I suspect that this string stuff
>>>>> became popular because D didn't have lambda declarations and type
>>>>> inference when the module was designed and implemented.
>>>>
>>>>
>>>>
>>>> String lambdas would quite certainly have been left out.
>>>> Anyway, string lambdas are unrelated to the discussion of std.algorithm
>>>> idioms in this context.
>>>>
>>>> [1,2,3].map!(a=>a+1)
>>>>
>>>> [1,2,3].map!(a=>a+1)()
>>>
>>>
>>> Yep. The "problem" is not string lambda but that the mapping function
>>> is passed a template argument (which you need for string lambda to
>>> work).
>>
>>
>> It is also a matter of execution speed and GC pressure. None of the D
>> compilers is able to inline delegate parameters at least as well as
>> alias template parameters afaik.
>>
>> Furthermore, only the current form can _guarantee_ that no hidden GC
>> allocations take place due to parameter passing to map.
>>
>
> Interesting. I can't speak for the GC and allocation you mention since
> I never tried to implement this myself but I should point out that C++
> STL's algorithm "module" (transform, for_each, etc) works this way.
> Having said that, if D can't infer the type of lambda parameters
> (which I thought the current version of D could) and create a
> function/delegate based on the body then this is a no go.
>
> Thanks for you insight.
> -Jose

The reason it works in C++ for transform, for_each etc. is because
those functions are eager.

Allocation-free transform with runtime delegate in D:

import std.algorithm, std.range;
void transform(IR,OR,I,O)(IR input, OR output, scope O delegate(I) dg)
    if(is(typeof(input.map!dg.copy(output))))
{
    input.map!dg.copy(output);
}

void main(){
    int[3] result;
    int	b = 1;
    [1,2,3].transform(result[], (int a)=>a+b);
    assert(result[] == [2,3,4]);
}

Note that parameter type deduction is lost for the delegate. I'd like
type deduction to work if the signature of 'transform' is changed to:

void transform(IR,OR,I=ElementType!IR,O)(IR input, OR output, scope O 
delegate(I) dg);

[1,2,3].transform(result[], a=>a+b);

Lazy map with runtime delegate would have to remember the delegate,
therefore it could not be a scope delegate.
Next ›   Last »
1 2 3 4 5
Top | Discussion index | About this forum | D home