Future of string lambda functions/string predicate functions

John Colvin john.loughran.colvin at gmail.com
Wed Aug 14 10:03:32 PDT 2013


On Wednesday, 14 August 2013 at 16:38:57 UTC, H. S. Teoh wrote:
> On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu 
> wrote:
>> On 8/14/13 7:34 AM, H. S. Teoh wrote:
> [...]
>> >That's a bit too terse. What about this:
>> >
>> >	less		// a < b
>> >	less!(5)	// a < 5
>> >	lessEq		// a <= b
>> >	lessEq!(5)	// a <= 5
>> >	more		// a > b
>> >	more!(5)	// a > 5
>> >	moreEq		// a >= b
>> >	moreEq!(5)	// a >= 5
>> >	equal		// a == b
>> >	equal!(5)	// a == 5
>> >	notEqual	// a != b
>> >	notEqual!(5)	// a != 5
>> 
>> At this point using "a < b" for a < b, "a < 5" for a < 5 etc.
>> becomes awfully attractive.
> [...]
>
> It just occurred to me, that perhaps what we really need here 
> is an
> even more abbreviated form of lambda literals, like this:
>
> 	sort!(a < b)(range);
>
> where 'a' and 'b' are undefined identifiers in the current 
> scope, and
> the compiler would know to bind them to lambda parameters. 
> Defined
> identifiers would, naturally, bind to whatever they refer to:
>
> 	int x = 5;
> 	find!(a == x)(range);
>
> This would be equivalent to:
>
> 	int x = 5;
> 	find!((a) => a==x)(range);
>
> IOW, an expression that references undefined identifiers in a 
> template
> parameter would be turned into a lambda that parametrize said
> identifiers.
>
>
> T

That's a bit too fragile IMO.

int b; //rename to 'a'
// lots of intermediate code...
int x = 5;
r.blah!(a == x);

Renaming of a seemingly unrelated variable would result in spooky 
action-at-a-distance behaviour.


More information about the Digitalmars-d mailing list