www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The One-Letter Nested Function - a sample article for some kind of

reply Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
I wrote this article because I felt like helping other people coming to 
D, but I'm not sure where the appropriate place to make such a 
contribution is. Maybe a "Learning Articles" or an "Idioms" section.

The One-Letter Nested Function

As a programmer new to D I wanted to share an idiom I've been using. 
This article will share two cases in which I've found the "one-letter 
nested function" to come in very handy.

The following function has a lot of ugly "cast(" code.

void setRandomColorPair( ref ColorPair cp )
{
    import std.random;
    cp.foreground = Color(
          cast(ubyte) uniform(40,200),
          cast(ubyte) uniform(50,100),
          cast(ubyte) uniform(150, 250) );
    cp.background = Color(
          cast(ubyte) uniform(40,200),
          cast(ubyte) uniform(50,100),
          cast(ubyte) uniform(200, 250) );
}

But with the one-letter nested function, the above became:

void setRandomColorPair( ref ColorPair cp )
{
    import std.random;
    ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }

    cp.foreground = Color( u(40,200), u(50,100), u(150, 250) );
    cp.background = Color( u(40,200), u(50,100), u(200, 250) );
}

It was a mild gain, but it really started to add up when I was assigning 
to more than just two variables.

The next example is for C programmers. Suppose you're faced with 
translating this code written in C:

void print_init_flags(int flags)
{
#define PFLAG(a) if( flags & INIT_##a ) printf(#a " ")
	PFLAG(FLAC);
	PFLAG(MOD);
	PFLAG(MP3);
	PFLAG(OGG);
	if(!flags)
		printf("None");
	printf("\n");
}

That #define macro is actually quite efficient, and since D doesn't have 
literal macros it looks like the D replacement could get pretty wordy, 
since we're going to need string mix-ins. But D *does* have nested 
functions. Look:

void printInitFlags( int flags )
{
    string w(string f) { return `if( flags & INIT_`~f~` ) 
write("MIX_INIT_`~f~` ");`; }
    mixin( w("FLAC") );
    mixin( w("MOD") );
    mixin( w("MP3") );
    mixin( w("OGG") );
    if(!flags)
       write ("None");
    writeln();
}

This is, I think, one of the rare cases where the C code is actually 
more concise than the translated D code, but when I tried the one-letter 
nested function idiom, it became a moot point.
Feb 13 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
With 2.058 the single-letter function can become:
auto u = (int a, int b) => cast(ubyte)uniform(a, b);

It's not much of savings in typing.

The only problem is I can't seem to make it static:
static u = (int a, int b) => cast(ubyte)uniform(a, b);

Error: non-constant nested delegate literal expression __lambda1

It would be better if you didn't have to specify the argument types. I
think bear asked for templated lambdas, so this could eventually
become:

auto u = (a, b) => cast(ubyte)uniform(a, b);

Which would make 'u' a template. I'm not sure what the exact syntax
was that was requested though.
Feb 13 2012
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 2/13/12 2:43 PM, Andrej Mitrovic wrote:
 auto u = (a, b) =>  cast(ubyte)uniform(a, b);

 Which would make 'u' a template. I'm not sure what the exact syntax
 was that was requested though.

This could never work without major changes to the language, because 'u' cannot be assigned a type. David
Feb 13 2012
next sibling parent Nick Treleaven <nospam example.net> writes:
On 13/02/2012 14:21, Andrej Mitrovic wrote:
 On 2/13/12, David Nadlinger<see klickverbot.at>  wrote:
 This could never work without major changes to the language, because 'u'
 cannot be assigned a type.

Yeah, the syntax is wrong. I found bear's post and the syntax: alias (x => x ^^ 2) sqrTemplate; So it would be: alias ((a, b) => cast(ubyte)uniform(a, b)) u;

Here 'alias name = expression' syntax helps shed brackets: alias u = (a, b) => cast(ubyte)uniform(a, b); That looks nice IMO.
Feb 13 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/13/12 7:46 AM, David Nadlinger wrote:
 On 2/13/12 2:43 PM, Andrej Mitrovic wrote:
 auto u = (a, b) => cast(ubyte)uniform(a, b);

 Which would make 'u' a template. I'm not sure what the exact syntax
 was that was requested though.

This could never work without major changes to the language, because 'u' cannot be assigned a type. David

alias (a, b) => cast(ubyte)uniform(a, b) u; should work. This makes is a case where the discussed syntax "alias defined = definee;" would be helpful. Andrei
Feb 13 2012
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.283.1329140648.20196.digitalmars-d puremagic.com...
 The only problem is I can't seem to make it static:
 static u = (int a, int b) => cast(ubyte)uniform(a, b);

auto u = function (int a, int b) => cast(ubyte)uniform(a, b); Should do it.
Feb 13 2012
parent reply David Nadlinger <see klickverbot.at> writes:
On 2/13/12 5:17 PM, Daniel Murphy wrote:
 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.283.1329140648.20196.digitalmars-d puremagic.com...
 The only problem is I can't seem to make it static:
 static u = (int a, int b) =>  cast(ubyte)uniform(a, b);

auto u = function (int a, int b) => cast(ubyte)uniform(a, b); Should do it.

I know it currently isn't, but shouldn't this be inferred as per TDPL anyway? David
Feb 13 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:jhbdnb$21sb$1 digitalmars.com...
 auto u = function (int a, int b) =>  cast(ubyte)uniform(a, b);

 Should do it.

I know it currently isn't, but shouldn't this be inferred as per TDPL anyway? David

Yes, it's just a way to force it.
Feb 13 2012
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Zach the Mystic:

 void setRandomColorPair( ref ColorPair cp )
 {
     import std.random;
     ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }

Where possible it's good to add "static" to nested functions: static ubyte u(in int a, in int b) pure nothrow { return cast(ubyte) uniform(a,b); } ----------------- Andrej Mitrovic:
 It would be better if you didn't have to specify the argument types. I
 think bear asked for templated lambdas, so this could eventually
 become:

Some related requests (one and half of them is by me): http://d.puremagic.com/issues/show_bug.cgi?id=7357 http://d.puremagic.com/issues/show_bug.cgi?id=7308 http://d.puremagic.com/issues/show_bug.cgi?id=7176 Bye, bearophile
Feb 13 2012
next sibling parent reply Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
On 2/13/12 9:14 AM, bearophile wrote:
 Where possible it's good to add "static" to nested functions:

 static ubyte u(in int a, in int b) pure nothrow { return cast(ubyte)
uniform(a,b); }

You're right. The only advantage to the way I wrote it is, possibly, it's easier for new people (like myself) to grasp the idea. But I'm pretty sure uniform is NOT a pure function. In fact, generating random numbers is about as far opposite a "pure" function as you can get, right? :-)
Feb 13 2012
parent reply bearophile <bearophileHUGS lycos.com> writes:
Zach the Mystic:

 But I'm 
 pretty sure uniform is NOT a pure function. In fact, generating random 
 numbers is about as far opposite a "pure" function as you can get, 
 right? :-)

Right, and sorry, I didn't see the function contents. If I don't run the D code you have to assume it's wrong code. Regarding pure random generators, I have asked it too: http://d.puremagic.com/issues/show_bug.cgi?id=5249 Bye, bearophile
Feb 13 2012
parent reply Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
On 2/13/12 11:21 AM, bearophile wrote:
 Zach the Mystic:
 Regarding pure random generators, I have asked it too:
 http://d.puremagic.com/issues/show_bug.cgi?id=5249

Aren't "pure" and "random" diametrically opposed in a fundamental way?
Feb 13 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/13/2012 06:01 PM, Zach the Mystic wrote:
 On 2/13/12 11:21 AM, bearophile wrote:
 Zach the Mystic:
 Regarding pure random generators, I have asked it too:
 http://d.puremagic.com/issues/show_bug.cgi?id=5249

Aren't "pure" and "random" diametrically opposed in a fundamental way?

They are. It is "pure" and "pseudo-random" that are not.
Feb 13 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 February 2012 17:01, Zach the Mystic
<reachzachatgooglesmailservice dot.com> wrote:
 On 2/13/12 11:21 AM, bearophile wrote:
 Zach the Mystic:

 Regarding pure random generators, I have asked it too:
 http://d.puremagic.com/issues/show_bug.cgi?id=5249

Aren't "pure" and "random" diametrically opposed in a fundamental way?

I'd say it was an oxymoron. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Feb 13 2012
prev sibling next sibling parent reply Jos van Uden <user domain.invalid> writes:
On 13-2-2012 15:14, bearophile wrote:
 Zach the Mystic:

 void setRandomColorPair( ref ColorPair cp )
 {
      import std.random;
      ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }

Where possible it's good to add "static" to nested functions:

Why?
Mar 09 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/09/2012 02:29 PM, Jos van Uden wrote:
 On 13-2-2012 15:14, bearophile wrote:
 Zach the Mystic:

 void setRandomColorPair( ref ColorPair cp )
 {
 import std.random;
 ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }

Where possible it's good to add "static" to nested functions:

Why?

Because then you don't have to rely on the compiler to optimize away the unneeded context pointer parameter. It should be able to do that though. I don't know if DMD is.
Mar 09 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 On 13-2-2012 15:14, bearophile wrote:
 Where possible it's good to add "static" to nested functions:

Why?

For optimization, to be sure there's no closure allocation or a second pointer. But also for code correctness, because static functions can't use automatic variables defined in the enclosing function. This makes the code simpler to understand (the pure attribute has a similar purpose, you are sure your global function is not using global mutable variables). Bye, bearophile
Mar 09 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
On Monday, 13 February 2012 at 14:14:38 UTC, bearophile wrote:
 Zach the Mystic:

 void setRandomColorPair( ref ColorPair cp )
 {
     import std.random;
     ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }

Where possible it's good to add "static" to nested functions: static ubyte u(in int a, in int b) pure nothrow { return cast(ubyte) uniform(a,b); }

I sorta figured D would implicitly attribute "static" to nested functions if the function didn't use any variables outside it's scope. Is that not so? Why are you saying it's a good idea to use "static" exactly?
Mar 09 2012
parent bearophile <bearophileHUGS lycos.com> writes:
F i L:

 I sorta figured D would implicitly attribute "static" to nested 
 functions if the function didn't use any variables outside it's 
 scope. Is that not so?

I don't think DMD does that. Before assuming DMD performs one optimization, go to read some of the asm it produces.
 Why are you saying it's a good idea to use "static" exactly?

Some answers here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=160469 Bye, bearophile
Mar 10 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
On Saturday, 10 March 2012 at 12:35:14 UTC, bearophile wrote:
 F i L:

 I sorta figured D would implicitly attribute "static" to 
 nested functions if the function didn't use any variables 
 outside it's scope. Is that not so?

I don't think DMD does that. Before assuming DMD performs one optimization, go to read some of the asm it produces.

Oh you crazy compiler developers. Thinking everyone can read ASM ;-)
 Why are you saying it's a good idea to use "static" exactly?

Some answers here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=160469

Thanks. Pretty much what I thought. Though, there *could* be area for automatic optimization here, right? I mean, DMD could analyze the nested function and deem it worthy of the same optimizations static nested functions receive, correct?
Mar 10 2012
parent bearophile <bearophileHUGS lycos.com> writes:
F i L:

 Oh you crazy compiler developers. Thinking everyone can read ASM 
 ;-)

I'd love to be able to develop compilers, but I am not that good yet :-) Writing working asm is much simpler than writing efficient asm code (more efficient than compiler generated one, even for SIMD code where compilers are still quite bad). And reading asm is much simpler than writing it. And scanning asm code visually to look for simple things, is simpler than reading and understanding what each asm instruction does. Writing very efficient asm isn't a common skill today, but reading a bit of asm is something you learn in a matter of some days if you have the desire, the time, and the right books. Most asm does is simple arithmetic, updating some CPU flags, and moving variables from here to there, where most CPUs manage the cache levels transparently (manually managed Scratchpad cache memory us uncommon). Modern CPUs have accumulated tons of cruft, but at the base it's easy stuff.
 Though, there *could* be area 
 for automatic optimization here, right?

Currently DMD devs are mostly trying to fix bugs, instead of adding optimizations. And as the pure attribute it's not just a matter of optimization. It's a contract between programmer and compiler. If you add "static" and then you use a variable in the enclosing function, you receive a compilation error. This error can't happen if "static-ness" is just an invisible automatic compiler optimization. It's good for such errors to come out, because when you use static you are stating you don't want to use outer function variables. So this is both a guaranteed optimization and a way to avoid using by mistake a variable defined in the enclosing scope. Using unwillingly variables from the outer scopes is a common source of bugs. Bye, bearophile
Mar 10 2012
prev sibling parent "F i L" <witte2008 gmail.com> writes:
bearophile wrote:
 Writing working asm is much simpler than...

Ya I've actually written ASM GPU shaders in the past. Not the same instruction set as x86 or anything, but I know the basic concept.
 Though, there *could* be area for automatic optimization here, 
 right?

Currently DMD devs are mostly trying to fix bugs, instead of adding optimizations. And as the pure attribute it's not just a matter of optimization. It's a contract between programmer and compiler. If you add "static" and then you use a variable in the enclosing function, you receive a compilation error. This error can't happen if "static-ness" is just an invisible automatic compiler optimization. It's good for such errors to come out, because when you use static you are stating you don't want to use outer function variables. So this is both a guaranteed optimization and a way to avoid using by mistake a variable defined in the enclosing scope. Using unwillingly variables from the outer scopes is a common source of bugs.

Well, my point wasn't that any function could receive "static" or purity implicitly, only nested ones. Seeing as how their use scope is very limited.
Mar 10 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/13/12, David Nadlinger <see klickverbot.at> wrote:
 This could never work without major changes to the language, because 'u'
 cannot be assigned a type.

Yeah, the syntax is wrong. I found bear's post and the syntax: alias (x => x ^^ 2) sqrTemplate; So it would be: alias ((a, b) => cast(ubyte)uniform(a, b)) u;
Feb 13 2012