> sort!("a > b")(array);
I just wanted to say that this is BRILLIANT! Zero call overhead, zero syntax overhead, compile-time lambda functions!
All the algorithms should support this syntax so we can do sexy compile-time lambda one-liners like:
find!("a.some_member > 10")(array);
or
partition!("a.call_something() !is null")(array);
etc.
And probably those should allow a data arg passed as 'b' to the lambda function so you could do something like
find!("a.some_member > b")(array, 10);
Or even use template varargs and number the args automatically to allow:
find!("a.x > b && a.w < c")(array, 10, 20);
It would just sequentially name the arguments b,c,d,e... etc.
Or even make it like C#/Tango's format string patterns since the string can be processed before mixing it in.
find!("a.x > {1} && a.w < {2}")(array, 10, 20);
That would be excellent. Take that boost::lambda!
--bb

"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:fjl4fo$8am$1@digitalmars.com...> > sort!("a > b")(array);
>> I just wanted to say that this is BRILLIANT! Zero call overhead, zero syntax overhead, compile-time lambda functions!
>> All the algorithms should support this syntax so we can do sexy compile-time lambda one-liners like:
>> find!("a.some_member > 10")(array);
>> or
>> partition!("a.call_something() !is null")(array);
>> etc.
>> And probably those should allow a data arg passed as 'b' to the lambda
> function so you could do something like
> find!("a.some_member > b")(array, 10);
>> Or even use template varargs and number the args automatically to allow:
>> find!("a.x > b && a.w < c")(array, 10, 20);
>> It would just sequentially name the arguments b,c,d,e... etc.
>> Or even make it like C#/Tango's format string patterns since the string
> can be processed before mixing it in.
> find!("a.x > {1} && a.w < {2}")(array, 10, 20);
>> That would be excellent. Take that boost::lambda!
>> --bb
Yes very cool! Would be even better if the parens could be removed. Ideally, the compiler would be able to do CTFE with some lambdas.
-Craig

Craig Black wrote:
> "Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:fjl4fo$8am$1@digitalmars.com...>>> sort!("a > b")(array);
>> I just wanted to say that this is BRILLIANT! Zero call overhead, zero syntax overhead, compile-time lambda functions!
>>>> All the algorithms should support this syntax so we can do sexy compile-time lambda one-liners like:
>>>> find!("a.some_member > 10")(array);
>>>> or
>>>> partition!("a.call_something() !is null")(array);
>>>> etc.
>>>> And probably those should allow a data arg passed as 'b' to the lambda function so you could do something like
>> find!("a.some_member > b")(array, 10);
>>>> Or even use template varargs and number the args automatically to allow:
>>>> find!("a.x > b && a.w < c")(array, 10, 20);
>>>> It would just sequentially name the arguments b,c,d,e... etc.
>>>> Or even make it like C#/Tango's format string patterns since the string can be processed before mixing it in.
>> find!("a.x > {1} && a.w < {2}")(array, 10, 20);
>>>> That would be excellent. Take that boost::lambda!
>>>> --bb
> > Yes very cool! Would be even better if the parens could be removed. Ideally, the compiler would be able to do CTFE with some lambdas.
There's that idea of creating "static" parameters from DCon07.
With that you should be able to stick the string in as a regular parameter. But I don't actually find the template syntax too bad. It's a good reminder that the argument must be a compile-time constant.
When/if we get static parameters it's going to be harder to tell from looking at code what's compile-time and what's not. I anticipate wasting lots of time in this manner: "why did I/they write this function like this? thats silly <rewrite rewrite> -- oh damn, I see why now. Argument #3 has to be a compile-time constant."
--bb

"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:fjmol3$1f71$1@digitalmars.com...> Craig Black wrote:
>> "Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:fjl4fo$8am$1@digitalmars.com...>>>> sort!("a > b")(array);
>>> I just wanted to say that this is BRILLIANT! Zero call overhead, zero syntax overhead, compile-time lambda functions!
>>>>>> All the algorithms should support this syntax so we can do sexy compile-time lambda one-liners like:
>>>>>> find!("a.some_member > 10")(array);
>>>>>> or
>>>>>> partition!("a.call_something() !is null")(array);
>>>>>> etc.
>>>>>> And probably those should allow a data arg passed as 'b' to the lambda
>>> function so you could do something like
>>> find!("a.some_member > b")(array, 10);
>>>>>> Or even use template varargs and number the args automatically to allow:
>>>>>> find!("a.x > b && a.w < c")(array, 10, 20);
>>>>>> It would just sequentially name the arguments b,c,d,e... etc.
>>>>>> Or even make it like C#/Tango's format string patterns since the string
>>> can be processed before mixing it in.
>>> find!("a.x > {1} && a.w < {2}")(array, 10, 20);
>>>>>> That would be excellent. Take that boost::lambda!
>>>>>> --bb
>>>> Yes very cool! Would be even better if the parens could be removed. Ideally, the compiler would be able to do CTFE with some lambdas.
>> There's that idea of creating "static" parameters from DCon07.
>> With that you should be able to stick the string in as a regular parameter. But I don't actually find the template syntax too bad. It's a good reminder that the argument must be a compile-time constant.
>> When/if we get static parameters it's going to be harder to tell from looking at code what's compile-time and what's not. I anticipate wasting lots of time in this manner: "why did I/they write this function like this? thats silly <rewrite rewrite> -- oh damn, I see why now. Argument #3 has to be a compile-time constant."
>> --bb
First I've heard about static parameters Very good idea.
You may be right about all that, but I still prefer a syntax without double quotes.

Bill Baxter wrote:
> When/if we get static parameters it's going to be harder to tell from looking at code what's compile-time and what's not. I anticipate wasting lots of time in this manner: "why did I/they write this function like this? thats silly <rewrite rewrite> -- oh damn, I see why now. Argument #3 has to be a compile-time constant."
The way I figure they should be used only when overloading between "known at compile time" and "not known at compile time". For instance, precompiling stuff like formatting strings and regexps. If a parameter is only for compile time use in that it doesn't compile with a non-const argument, it should be a template parameter as currently.
But then, I think using CTFE for something that is used only at compile time is completely wrong, so I might be alone with my opinions. :-)
--
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:fjpcqv$1uio$1@digitalmars.com...> Janice Caron:
>> sort!(q{a > b})(array);
>> Please explain :-)
>> Bye,
> bearophile
q{ ... } is a "token string". Its contents are lexed and have to conform to D's lexicography, but it is then turned into a string literal. It goes well with string mixins and the like.

On 12/12/07, bearophile <bearophileHUGS@lycos.com> wrote:
> Janice Caron:
> > sort!(q{a > b})(array);
>> Please explain :-)
It's just another way of writing strings. You can write "..." or you can write q{...}. It's slightly different - escape strings aren't expanded, and the string contents have to be valid D, but it's still just a string. The cool thing is that your text editor doesn't know that, and so will still syntax-highlight the string contents!