www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - While we were discussing lambda syntax..

reply Andrej Mitrovic <none none.none> writes:
There was some heated discussion about the disadvantages of using strings as a
predicate, and coming up with some new syntax that DMD would support. Some
people did not like using strings and would rather use _ or _0/_1 instead of
this:

auto arr = [0,1,2,3,4];
auto plusOne = map!("a + b")(arr);

Well, while we were arguing about a new syntax, a clever fellow named Phillipe
Sigaud has already come up with a way to use predicates without resorting to
strings:

auto arr = [0,1,2,3,4];
auto plusOne = map!(_0 + _1)(arr);

Check it out: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/lambda.html

Make sure you read the features section. Is that awesome or what?
Dec 31 2010
next sibling parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Andrej Mitrovic" <none none.none> wrote:
 There was some heated discussion about the disadvantages of using strings 
 as a predicate, and coming up with some new syntax that DMD would support. 
 Some people did not like using strings and would rather use _ or _0/_1 
 instead of this:

 auto arr = [0,1,2,3,4];
 auto plusOne = map!("a + b")(arr);

 Well, while we were arguing about a new syntax, a clever fellow named 
 Phillipe Sigaud has already come up with a way to use predicates without 
 resorting to strings:

 auto arr = [0,1,2,3,4];
 auto plusOne = map!(_0 + _1)(arr);

 Check it out: 
 http://svn.dsource.org/projects/dranges/trunk/dranges/docs/lambda.html

 Make sure you read the features section. Is that awesome or what?

Personally I like string lambdas because they are shotrest possible and easy to see. But still if you experiment with language, would f!{_0 < _1} syntax be acceptable if possible?
Dec 31 2010
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
 Well, while we were arguing about a new syntax, a clever fellow named Phillipe
Sigaud has already come up with a way to use predicates without resorting to
strings:

 auto arr = [0,1,2,3,4];
 auto plusOne = map!(_0 + _1)(arr);

 Check it out: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/lambda.html

 Make sure you read the features section. Is that awesome or what?

Hi Andrej, thanks for the kind words, but don't expect too much from this module. It was just an afternoon fun, as I was trying to 'get' expressions templates. E. Niebler's articles on boost::proto on cpp-next.com are an interesting read for a much-more-expanded module. As I said in the docs, I got stuck at comparison operators. a < b is automatically transformed by the compiler into a.opCmp(b) < 0. a.opCmp(b) becomes another lambda and the '< 0' part triggers another expansion, ad infinitum... That totally destroy any interest this module could have. I mean, mapping and reducing are good, but I want filtering too, and filters demand comparison lambdas. As yet, filter!(_ < 0)(arr) doesn't work. Too bad. Philippe.
Jan 01 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Sat, 1 Jan 2011 09:56:25 +0100
Philippe Sigaud <philippe.sigaud gmail.com> wrote:

 As I said in the docs, I got stuck at comparison operators. a <  b is
 automatically transformed by the compiler into a.opCmp(b) < 0.
 a.opCmp(b) becomes another lambda and the '< 0' part triggers another
 expansion, ad infinitum...

Is this a good design choice? I mean opCmp looks like a good idea (wrapping= all comparisons in a single one instead of having to implement all separat= edly), but is it really one? It currently annoys me for a custom sort where= what I need is just less-than. opEquals is already apart: I would vote +++= for opLessThan. Then, a programmer can get rid of opCmp alltogether (I don= 't mean it should be deprecated, may have uses). Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Jan 01 2011
prev sibling next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Sat, Jan 1, 2011 at 15:52, spir <denis.spir gmail.com> wrote:
 On Sat, 1 Jan 2011 09:56:25 +0100
 Philippe Sigaud <philippe.sigaud gmail.com> wrote:

 As I said in the docs, I got stuck at comparison operators. a < =C2=A0b =


 automatically transformed by the compiler into a.opCmp(b) < 0.
 a.opCmp(b) becomes another lambda and the '< 0' part triggers another
 expansion, ad infinitum...

Is this a good design choice? I mean opCmp looks like a good idea (wrappi=

atedly), but is it really one? It currently annoys me for a custom sort whe= re what I need is just less-than. opEquals is already apart: I would vote += ++ for opLessThan. Then, a programmer can get rid of opCmp alltogether (I d= on't mean it should be deprecated, may have uses). I don't know if it's good design or not. All I can say is that's the point where C++ can continue and one can have Boost::lambda. Whereas I was stuck. Anyway, that was a small foray into expression templates, which was interesting and such... But I went back to string templates. For small expressions, they are quite palatable. I just developed a n-args version of UnaryFun/BinaryFun, which was one of the most useful little helper I ever did in D.
Jan 01 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/1/11 9:41 AM, Philippe Sigaud wrote:
 On Sat, Jan 1, 2011 at 15:52, spir<denis.spir gmail.com>  wrote:
 On Sat, 1 Jan 2011 09:56:25 +0100
 Philippe Sigaud<philippe.sigaud gmail.com>  wrote:

 As I said in the docs, I got stuck at comparison operators. a<    b is
 automatically transformed by the compiler into a.opCmp(b)<  0.
 a.opCmp(b) becomes another lambda and the '<  0' part triggers another
 expansion, ad infinitum...

Is this a good design choice? I mean opCmp looks like a good idea (wrapping all comparisons in a single one instead of having to implement all separatedly), but is it really one? It currently annoys me for a custom sort where what I need is just less-than. opEquals is already apart: I would vote +++ for opLessThan. Then, a programmer can get rid of opCmp alltogether (I don't mean it should be deprecated, may have uses).

I don't know if it's good design or not. All I can say is that's the point where C++ can continue and one can have Boost::lambda. Whereas I was stuck. Anyway, that was a small foray into expression templates, which was interesting and such... But I went back to string templates. For small expressions, they are quite palatable. I just developed a n-args version of UnaryFun/BinaryFun, which was one of the most useful little helper I ever did in D.

Great! I recall I tried to do that a couple of years ago, but hit a few bugs. Could you make NaryFun into a proposal for Phobos? Andrei
Jan 01 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/1/11 11:37 AM, Philippe Sigaud wrote:
 I just developed a n-args
 version of UnaryFun/BinaryFun, which was one of the most useful little
 helper I ever did in D.

Great! I recall I tried to do that a couple of years ago, but hit a few bugs. Could you make NaryFun into a proposal for Phobos?

Sure. It uses a simple heuristics to automatically determine the 'string arity': it looks for lone letters (not surrounded by other letters). In practice it works quite well and there is a optional arity, if you need one. The current code still uses templates instead of CTFE for this arity determination. I'll change that and propose it. One of my week-end plan was to do a curried version. That is curriedFun!"a+b*c" would create not a 3-arg function template but three unary templated funs inside one another. I find currying most useful for mapping and filtering ranges... Would that be of interest for someone? Philippe

You'd need to prove usefulness, which I suspect shouldn't be all too difficult in this case. Andrei
Jan 01 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/1/11 3:31 PM, Simen kjaeraas wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Great! I recall I tried to do that a couple of years ago, but hit a
 few bugs. Could you make NaryFun into a proposal for Phobos?

A great part of Philippe's work on dranges is worthy of inclusion in Phobos.

That's why he's on Phobos' roster. Philippe, I'm looking forward to acting as an ombudsman for your proposals! You need solid, motivating documentation and clean code. Andrei
Jan 01 2011
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
 I just developed a n-args
 version of UnaryFun/BinaryFun, which was one of the most useful little
 helper I ever did in D.

Great! I recall I tried to do that a couple of years ago, but hit a few bugs. Could you make NaryFun into a proposal for Phobos?

Sure. It uses a simple heuristics to automatically determine the 'string arity': it looks for lone letters (not surrounded by other letters). In practice it works quite well and there is a optional arity, if you need one. The current code still uses templates instead of CTFE for this arity determination. I'll change that and propose it. One of my week-end plan was to do a curried version. That is curriedFun!"a+b*c" would create not a 3-arg function template but three unary templated funs inside one another. I find currying most useful for mapping and filtering ranges... Would that be of interest for someone? Philippe
Jan 01 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Great! I recall I tried to do that a couple of years ago, but hit a few  
 bugs. Could you make NaryFun into a proposal for Phobos?

A great part of Philippe's work on dranges is worthy of inclusion in Phobos. -- Simen
Jan 01 2011
prev sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Sat, Jan 1, 2011 at 22:42, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 That's why he's on Phobos' roster. Philippe, I'm looking forward to acting
 as an ombudsman for your proposals! You need solid, motivating documentation
 and clean code.

Yeah, I know, thanks for the friendly reminder and sorry for disappearing. That was work-related, not D-related. Being promoted and then promoted again can do that for you. End of year was a bitch. I'll try and find the time to put something together for Phobos. But I fear I'll be submerged again for quite some time. In any case, thanks all for all the work I see being poured into D! And a Happy New Year! Philippe
Jan 02 2011