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




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 (wrappi=


ng all comparisons in a single one instead of having to implement all separ=
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 reply 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
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 reply "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
parent reply 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
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